Post-RC1 merging criteria (was Re: [PULL] cleanups)
tiago.vignatti at nokia.com
Mon Jun 21 06:04:51 PDT 2010
On Sun, Jun 20, 2010 at 02:02:34AM +0200, ext Keith Packard wrote:
> Running a shorter release schedule would be fine with me, but as we
> don't have any significant work happening in other trees
Yes, we have significant work happening right now: clean-up. It's a feature as
desirable as any other.
> On Sat, 19 Jun 2010 15:22:50 -0700, Jamey Sharp <jamey at minilop.net> wrote:
> > Perhaps we need an xserver-next tree
AFAIK -next tree intents to solve integration issues. On kernel land they have
a lot of submaintainers and each time one sends a pull request, such pull
collides with another one because the code changes conflict. So the idea is
to very often (daily?) collect patches from submaintainers' trees and create
builds. All this happens in automatically fashion and they target integration
I'm afraid integration and collision of patches are not our main problem now.
The problem is that people are creating patches but they got lost somewhere
and/or take so many time to go upstream.
In my opinion, reducing the release schedule now would improve the throughput
of patches going in. Probably three months for the whole release would be
better with the majority of time being gates opened for merge window - two
> If not, I wonder if we
> couldn't have either a separate tree or just a separate branch where
> people were pushing these kinds of changes by themselves, at least
> they'd be all ready to merge once 1.9 ships.
that's pretty much what was happening recently: I've been carrying a tree with
PCI clean ups, Mikhail with huge janitor clean-ups, Jamey re-working screen
structures and etc. I don't think one special tree collecting all patches is
But I think we should decide, i.e. nominate, who maintains a module, piece of
code or feature. So for instance if one send a patch for xkb then he/she would
expect that, say, either daniels or whot would apply in a few days. Can be
both caring similar trees, but only one would be the main responsible. The RM
would have to get a confidence with his submaintainers and expect that they
deliver their trees doing often PULL requests when the merge window is opened.
More information about the xorg-devel