Re: Need help: Generating patch using git

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

On Thu, Feb 2, 2012 at 3:35 AM, Greg KH <greg@xxxxxxxxx> wrote:
On Thu, Feb 02, 2012 at 02:47:49AM +0530, Srivatsa Bhat wrote:
> Hi,
> On Wed, Feb 1, 2012 at 10:51 AM, amit mehta <gmate.amit@xxxxxxxxx> wrote:
>     > Also the kernel tree you are using seems to be Linus's mainline, is
>     > that what you wanted or did you want to be making the patch against a
>     > linux-next kernel?
>     My current goal is to send some patches to kernel janitor group though I'm
>     not
>     sure if this group is still active or not.
>     you mean to say that this is not the tree which i should be synced to? If
>     not
>     then can you please send me the link to the relevant git repository ?
> Please note that linux-next is just a tree used for integration-testing. I
> strongly suggest
> that you don't base your patches on linux-next. Basing it on current mainline
> is generally a good idea. But if you are doing some significant development,
> you should target the individual trees that the subsystem maintainers maintain.
> To put it in simple terms, base your patch on current mainline and send it to
> the appropriate people (use in the scripts directory to find
> whom to send it to). Then if the maintainer specifically asks you to rebase
> your
> patch on some particular tree that he maintains, then do it. Then you know what
> to do with patches related to that subsystem from next time onwards :-)

As a subsystem maintainer, I strongly disagree with this.

Do your work against linux-next, as that contains the different
subsystems already.  You don't want to do something only to find out you
need to totally redo it, or just throw it away as someone else has
already done it (which is quite common for janitorial and other "simple"

Ok, that makes sense.
So please, either work against linux-next, or the subsystem-specific
tree, linux-next is usually easier, the odds of cross-subsystem merges
causing problems with your change, for the subsystem maintainer, are
very low, much lower than the fact that major changes might have already

I see your point, and I agree with you now.
Thanks a lot Greg, for showing the right path!

Srivatsa S. Bhat
Kernelnewbies mailing list

[Newbies FAQ]     [Linux Kernel Mentors]     [Linux Kernel Development]     [IETF Annouce]     [Git]     [Networking]     [Security]     [Bugtraq]     [Photo]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Networking]     [Linux RAID]     [Linux SCSI]     [Linux ACPI]

Add to Google Powered by Linux