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

[valdis.kletnieks at vt.edu]

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 484 bytes
Desc: not available
Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20170412/46ea96a6/attachment.bin