[Ksummit-2013-discuss] [ATTEND] maintainer hierarchy vs. the release process

[Luck, Tony]

> I'm not familiar with how the TIP tree works, so I'll have to look
> into it.  My initial reaction is that sounds like an increase
> in the number of pull requests to Linus, and not much different
> than simply flattening or eliminating the maintainer hierarchy.
> That might be a fine idea, but it would seem to overtly tax Linus's
> (lack of) scalability and it might even exacerbate the issues Jiri
> and Steven described?

Need an answer from Linus on what his preference is here. A couple
of years back I did an octopus merge of some *really* unrelated
topic branches and sent just one [GIT PULL] e-mail ... and received
a polite note that I interpreted as "Don't do that again":

http://lkml.indiana.edu/hypermail/linux/kernel/1107.3/02766.html

So now I send a pull for each topic ... and haven't heard a grumble
about too many pull requests.

Obviously this would fall apart if Linus got 10,000 pull messages
each containing just one commit!

So it would be good to coax Linus into offering some more guidelines
during the discussion at the summit.

-Tony

I might as well throw my "pick me" request here too.  I maintain
ia64 (which even fewer people probably care about that last year)
pstore (which seems to be popular with all kinds of people except
for the kexec/kdump folks) and RAS (reliability, availability, serviceability)
things that make the kernel stay up longer, or give better diagnostics
when we do crash.  Most of this for systems big enough that it takes
two or more people (possibly with fork lifts) to move them.