Need help: Generating patch using git

Srivatsa Bhat bhat.srivatsa at gmail.com
Wed Feb 1 17:12:18 EST 2012


On Thu, Feb 2, 2012 at 3:35 AM, Greg KH <greg at kroah.com> 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 at gmail.com>
> 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 get_maintainer.pl 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"
> tasks).
>
>
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
> happened.
>

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

Regards,
Srivatsa S. Bhat
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20120202/8b986e61/attachment.html 


More information about the Kernelnewbies mailing list