> I am just explaining how it works in practice. If the patch is still
> being improved, the feeling is that the author wants more time to adjust
> things, and with other things on our plate, we are glad to leave their
> patch until last.
Well, it's good that you have an explanation, but I'm not sure it
helps much. :-) Surely the patches that are most likely to change
substantially are the big ones, and leaving those until last results
in them not making the time-based cutoff. Someone who submitted a
20-line patch isn't likely to revise it substantially; someone who is
being paid $20k to write a patch is likely to spend a lot of time
working on it.
I think the fundamental problem here is the number and bandwidth of
the committers, which seems to be pretty limited. Most of the
committers are either inactive, or essentially maintainers for a
particular subsystem. With the exception of patches authored by the
committers themselves, I think the vast majority of patches for this
'fest were committed by Tom and Peter - and I think really mostly Tom.
And many of those were significantly modified in the process of being
committed, which suggests that efforts to take the load of committers
by having non-committers do reviews has not been entirely successful.
(It would be interesting to here how much value people think it has
added, and get suggestions on how to do things better next time.)
I'm not sure what to do about it, though. More committers could be
added, but I presume if there were obvious candidates it would have
been done already. It's complicated by the fact that you need people
who both (1) know what they're doing and (2) have time to review and
commit *other people's patches*. In reality, a pretty significant
fraction of the current committers are either mostly inactive, or
essentially maintainers for one small area of the code.
...Robert