Re: [PATCH] net: add new QCA alx ethernet driver

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


On Thu, Aug 9, 2012 at 8:28 AM, Steven Rostedt <rostedt@xxxxxxxxxxx> wrote:
> On Thu, 2012-08-09 at 08:22 -0700, Joe Perches wrote:
>
>> Yes, I sent signed-off patches to their original RFC submission
>> (back last year?).

And that is why your SOB was kept.

>> To me, this single large patch is like a
>> snapshot of a git tree and not all contributors to that git
>> tree should be noted as signers of the entire thing.

I am not sure we really ever addressed this technical difference and
from what I have seen we always run into this question on new driver
submissions.

Entity x goes on and posts driver joojoo-1, and we some folks in the
community may merge such patch onto their tree and edit the driver and
send some of their own changes and improvements to the developers /
mailing list. Typically if the patches sent had a SOB tag the right
thing to due given the legal implications of the Developer's
Certificate of Origin is to add those SOBs to the new driver
submission if company x goes on and posts joojoo-2.. but...

> Ouch, that looks like we are losing all history.

Agreed! It'd be best instead to have such changes as part of a linear
history somewhere so maybe what would be right prior to inclusion
upstream is for such patches to be merged on an external github tree
or wherever to be able to keep record of the submissions done during
development. Then upon submission to the Linux kernel again as
joojoo-2 instead of joojoo-1 company x would simply provide their own
SOB, and the record of the previous SOBs would be kept on the forked
git tree.

Whether or not it is required to have the SOB tog of previous patch
submitters is not clear but to me its not necessary if you have a
record somewhere that they were submitted and merged in some other
tree. The mailing list alone may serve as a good place holder for this
information as well so a separate tree may not be required.

So -- are we OK to *not* include SOBs of evolutions sent to developers
of joojoo-1 when company x submits joojoo-2 so long as those patches
were sent publicly or a record is kept somewhere ?

> One large patch should not be submitted. If it was developed in steps,
> then it is best to show those steps when they are incorporated into the
> Linux repository.

Sure, but at times some changes are asked after a submission of
joojoo-1, and at times this may be ongoing until maybe even joojoo-10,
before we are happy to merge it upstream.

  Luis
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[Other Archives]     [Linux Kernel Newbies]     [Linux Driver Development]     [Linux Kbuild]     [Fedora Kernel]     [Linux Kernel Testers]     [Linux SH]     [Linux Omap]     [Linux Tape]     [Linux Input]     [Linux Kernel Janitors]     [Linux Kernel Packagers]     [Linux Doc]     [Linux Man Pages]     [Linux API]     [Linux Memory Management]     [Linux Modules]     [Linux Standards]     [Kernel Announce]     [Netdev]     [Git]     [Linux PCI]     Linux CAN Development     [Linux I2C]     [Linux RDMA]     [Linux NUMA]     [Netfilter]     [Netfilter Devel]     [SELinux]     [Bugtraq]     [FIO]     [Linux Perf Users]     [Linux Serial]     [Linux PPP]     [Linux ISDN]     [Linux Next]     [Kernel Stable Commits]     [Linux Tip Commits]     [Kernel MM Commits]     [Linux Security Module]     [AutoFS]     [Filesystem Development]     [Ext3 Filesystem]     [Linux bcache]     [Ext4 Filesystem]     [Linux BTRFS]     [Linux CEPH Filesystem]     [Linux XFS]     [XFS]     [Linux NFS]     [Linux CIFS]     [Ecryptfs]     [Linux NILFS]     [Linux Cachefs]     [Reiser FS]     [Initramfs]     [Linux FB Devel]     [Linux OpenGL]     [DRI Devel]     [Fastboot]     [Linux RT Users]     [Linux RT Stable]     [eCos]     [Corosync]     [Linux Clusters]     [LVS Devel]     [Hot Plug]     [Linux Virtualization]     [KVM]     [KVM PPC]     [KVM ia64]     [Linux Containers]     [Linux Hexagon]     [Linux Cgroups]     [Util Linux]     [Wireless]     [Linux Bluetooth]     [Bluez Devel]     [Ethernet Bridging]     [Embedded Linux]     [Barebox]     [Linux MMC]     [Linux IIO]     [Sparse]     [Smatch]     [Linux Arch]     [x86 Platform Driver]     [Linux ACPI]     [Linux IBM ACPI]     [LM Sensors]     [CPU Freq]     [Linux Power Management]     [Linmodems]     [Linux DCCP]     [Linux SCTP]     [ALSA Devel]     [Linux USB]     [Linux PA RISC]     [Linux Samsung SOC]     [MIPS Linux]     [IBM S/390 Linux]     [ARM Linux]     [ARM Kernel]     [ARM MSM]     [Tegra Devel]     [Sparc Linux]     [Linux Security]     [Linux Sound]     [Linux Media]     [Video 4 Linux]     [Linux IRDA Users]     [Linux for the blind]     [Linux RAID]     [Linux ATA RAID]     [Device Mapper]     [Linux SCSI]     [SCSI Target Devel]     [Linux SCSI Target Infrastructure]     [Linux IDE]     [Linux SMP]     [Linux AXP]     [Linux Alpha]     [Linux M68K]     [Linux ia64]     [Linux 8086]     [Linux x86_64]     [Linux Config]     [Linux Apps]     [Linux MSDOS]     [Linux X.25]     [Linux Crypto]     [DM Crypt]     [Linux Trace Users]     [Linux Btrace]     [Linux Watchdog]     [Utrace Devel]     [Linux C Programming]     [Linux Assembly]     [Dash]     [DWARVES]     [Hail Devel]     [Linux Kernel Debugger]     [Linux gcc]     [Gcc Help]     [X.Org]     [Wine]

Add to Google Powered by Linux

[Older Kernel Discussion]     [Yosemite National Park Forum]     [Large Format Photos]     [Gimp]     [Yosemite Photos]     [Stuff]