How to contribute (was Re: Kernelnewbies Digest, Vol 77, Issue 7

[Arthur Brainville (Ybalrid)]

On Wed, Apr 12, 2017 at 04:47:45PM -0400, valdis.kletnieks at vt.edu wrote:
> On Wed, 12 Apr 2017 20:25:11 +0200, "Arthur Brainville (Ybalrid)" said:
> 
> > So, the best "branch" of developement to test if it doesn't break our
> > system is the linux-next branch, or the mainline kernel (currently
> > tagged by Linus as 4.11-RC6) ?
> 
> Depends how brave you are.  Linus is currently at -rc6, and linux-next
> *should* be what will become 4.12. (Should be, as in "4.11 is at -rc5, so
> people *should* already have sent maintainers patches for the next release").
> 
> > I'm currently trying to understand how kernel developement is actually
> > organized, here's what I've understood
> 
> You're a bit off...
> 
> > So, how "linux-next" works ? Is that a "testing ground" for new kernel
> > patches? When/how does the changes the maintainers accepted are merged into
> > the mainline kernel? ^^"
> 
> And explaining how you're off answers this question as well... :)
> 
> Here's how it works..
> 
> Developers create patches. See Documentation/process/submitting-patches.rst
> for the details on that.
> 
> They then e-mail those to maintainers.  See MAINTAINERS for the canonical
> list.
> 
> Maintainers then review the patches, and if there's an issue, e-mail back
> to the submitter with an explanation of the issue.  If the patch is OK,
> the maintainer puts it into his git tree (usually with 'git am').
> 
> There may be several levels of sub-maintainer.  For instance, somebody may
> maintain a driver for one specific USB sound card.  They feed those patches
> to the USB sound maintainer, who then feeds it to the USB subsystem maintainer.
> That gets done by the higher-up maintainer doing a 'git pull' of the appropriate
> tree.
> 
> In addition, most of the trees *also* get pulled every day and built into
> 'linux-next', to find merge conflicts and provide a test kernel.
> 
> So at this point, we have top-level maintainers with trees full of patches.
> 
> At some point, Linus tags the final V4.11.  This opens the "merge window".
> For 2 weeks, Linus does 'git pull' from all the maintainers and merges it
> to his tree, and then tags V4.12-rc1, which closes the merge window.  During
> the merge window, most maintainers will not accept new patches, because there's
> a chance that a patch could come in and be immediately merged upstream without
> having appeared in several linux-next dailys - so no testing.   Once the
> window is closed, maintainers start collecting patches for the v4.13 cycle,
> and only sending Linus bugfixes and minor stuff between 4.12-rc1 and final 4.12
> 
> Lather, rinse, repeat.  release, merge cycle, -rc1, collect patches for next
> release, -rc8 (or so) and another release....
> 
> > Oh, and, I almost forgot : If I try to use a linux-next kenrel, and
> > things breaks, who do I tell? ^^"
> 
> Depends how granular you can identify the issue.  If you do a 'git bisect'
> of a problem, you can narrow it down to a specific patch, you mail the patch
> author, the maintainer, any subsystem-specific list, and the linux-kernel list.
> If you just know "USB is hosed", you send it to the USB list and linux-kernel,
> and if you have *no* idea, toss it to linux-kernel.



> _______________________________________________
> Kernelnewbies mailing list
> Kernelnewbies at kernelnewbies.org
> https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies


Thanks for the explaination!

Indeed I was quite a bit off, now I know the process better ;-)

Regards,
Arthur Brainville