LWN: Comments on "A day in the life of linux-next"

rotating merge

nix — 2008-06-27T22:09:23+00:00

That doesn't work when major changes to two subsystems are coupled (say, a 
block layer change that necessitates changes to the scsi midlayer). I 
anticipate vast pointless bickering over what precisely constitutes a 
subsystem if this were done (plus a lot of unnecessary serialization of 
work).

rotating merge

tlw — 2008-06-27T19:05:53+00:00

Instead of opening the merge window and making it a free-for-all in a short 2-week period,
what if the merge window rotated among the different subsystems?

E.g. for the next N weeks only accept changes to subsystem A
for the next M weeks, only subsystem B
etc...

Wouldn't that help migrate the pain?

Of course different subsystems would clamor over what the ordering and durations should be...

And once we go full-circle and end up back at the first subsystem we bump a version number
somewhere and call that a release!

A day in the life of linux-next

iabervon — 2008-06-26T19:05:55+00:00

Developers need to worry about 2.6.26 bugs, presumably, because Linus won't merge your 2.6.27
changes if you didn't fix problems with your 2.6.26 changes in a timely fashion. And your
later work will probably be particularly messed up if Linus gets fed up and reverts some of
the things you did for 2.6.26 because they had problems you weren't taking care of.

I don't think there's really much risk of developers ignoring bugs (that get Linus or Andrew's
attention, anyway) in favor of working on their next thing, since their reputations are on the
line. The more rational fear is that developers won't test 2.6.26, and so bugs won't get
turned up. But I don't think that actually matters too much: I expect that people will develop
against the currently-stabilizing Linus version, and therefore hit other people's bugs, and
people don't hit their own bugs anyway (at least, those that survive to get merged).

One thing that I think would have traditionally been a problem but shouldn't be an issue with
git is the difficulty of preparing a bugfix patch for 2.6.26 when you've been working on a
post-2.6.27 feature. But that's a command or two of setup these days.

A day in the life of linux-next

sht — 2008-06-26T18:48:17+00:00

A thing that would be interesting Jonathan, is a graph over the number of changesets that have
gone into linux-next over time, just like you and Greg have been doing graphs over the number
changesets that have gone into linus-2.6.