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

[H. Peter Anvin]

On 07/12/2013 11:31 AM, Luck, Tony wrote:
> 
> 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.
> 

Linus certainly has been adamant that we don't merge topics for him
unless there is an unavoidable dependency.  That being said, we do group
development threads by general topic and don't push a separate branch
for each individual thread of development (in some ways doing darcs'
"patch calculus" manually).

One major advantage is that it forces us to write a general description
for each topic.  This is pretty simple with a smallish number of
patches, but for a single x86 pull request it would be meaningless.

I understand Linus' normal workflow is to pull in the x86 pull requests
(minus any he might reject) and then do testing on the whole thing, though.

	-hpa