Some development statistics for 2.6.27 [LWN.net]

Some development statistics for 2.6.27

Posted Oct 10, 2008 5:13 UTC (Fri) by iabervon (subscriber, #722)
In reply to: Some development statistics for 2.6.27 by aegl
Parent article: Some development statistics for 2.6.27

There's no reason that most of the changes for 2.6.x should be in 2.6.x-rc1; rather, most of the changes should be submitted before 2.6.x-rc1 is released, but Linus is likely to want to sit on some of them, ask for some of them to be merged by their authors and reposted, etc. to make -rc1 less chaotic. I haven't come up with a way to get overall statistics, but:

$ git shortlog --no-merges --since=jul.28 v2.6.26..v2.6.27

is a start (looking at the changes where the commit that ended up in the official history was made after the end of the merge window).

to post comments

Some development statistics for 2.6.27

Posted Oct 10, 2008 15:55 UTC (Fri) by aegl (subscriber, #37581) [Link] (1 responses)

"There's no reason that most of the changes for 2.6.x should be in 2.6.x-rc1"

The current kernel development model is that all new code for the next release be merged during the two week merge window. It should have been submitted before the merge window so that it see some test time in linux-next or -mm, and so that merge and integration issues are sorted out before being sent to Linus. Post-rc1 is supposed to be for bug-fixes and regression. I don't think that those should require 45% of the code changes that were needed for the original features (if they do, it would seem to indicate that the features were not really ready to be merged).

At this year's kernel summit Linus admitted to being a big softie when it comes to accepting merges after -rc1 ... it seems that developers are taking advantage of this more and more each release.

Some development statistics for 2.6.27

Posted Oct 10, 2008 21:26 UTC (Fri) by iabervon (subscriber, #722) [Link]

The process as of 2.6.27-rc1 was that code would be written and tested before the merge window, submitted during the merge window, and merged whenever Linus felt like it; there wasn't a process in place to submit changes intended for 2.6.27 before 2.6.26 came out. Plus, he was a big softie, some developers weren't clear on the process. Also, not just any bug fix is acceptable after the merge window; there ended up being push back on a ton of code post-merge-window for 2.6.27 that was fixing features introduced in 2.6.25 and 2.6.26.

IIRC, there was talk at the summit about going to a model where everything for 2.6.28 must be submitted before 2.6.27 came out, by way of -next. But Linus didn't want to have to deal with pull requests for 2.6.28 while he's trying to get 2.6.27 released.