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:

quoted

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").

quoted

I'm currently trying to understand how kernel developement is actually
organized, here's what I've understood

You're a bit off...

quoted

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....

quoted

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