On Wed, Apr 12, 2017 at 04:47:45PM -0400, valdis.kletnieks@xxxxxx 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@xxxxxxxxxxxxxxxxx > 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 _______________________________________________ Kernelnewbies mailing list Kernelnewbies@xxxxxxxxxxxxxxxxx https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies