Post-RC1 merging criteria (was Re: [PULL] cleanups)

[Jamey Sharp]

On Sat, Jun 19, 2010 at 11:04 AM, Matt Turner <mattst88 at gmail.com> wrote:
> On Fri, Jun 18, 2010 at 5:32 PM, Keith Packard <keithp at keithp.com> wrote:
>> What do others think about merging reviewed minor cleanups that don't
>> affect API or ABI at this point? Is it OK? Should we pend these until
>> the 1.10 merge window opens?
>
> I'd say it's fine. But in keeping with our new tradition of following
> the kernel development model, I ask What Would Linus Do?

That's easy. Linus would have a pile of minions, er, subsystem
maintainers, and an even larger pile of people interested in testing
random git trees posted all over the place. I'd love to know what the
X community can do to encourage the same to happen here, but it seems
like every discussion that might help has gone down in flames.

I don't feel strongly about whether my cleanup patches should or
should not be merged. I'd like them to be, so I don't have to carry
them locally as I continue making bigger changes, but I'm pretty good
at using git and it won't hurt me to hold on to them for three months.

Tiago's questions are more important, in my opinion: Should we branch
1.9 and leave master open for development, and should we choose a
shorter freeze period for 1.10? I guess we're trying to get people to
test the RCs, and that's a little more likely if that code is on
master rather than on a release branch. Three months does feel like a
long time to stall development on master, though, given how
attention-starved this code already is. I'd prefer a three-month total
release cycle, assuming a willing release manager.

Perhaps we need an xserver-next tree, like linux-next[1]: a tree for
integration-testing different developers' work that is not tied to the
server's release cycle. Unlike Linux, xserver doesn't have a strong
notion of "subsystem maintainers", so I envision letting anyone offer
a topic branch for integration testing. Somebody would have to
volunteer to manage the tree though, and that won't be me. :-)

Jamey

[1] http://linux.f-seidel.de/linux-next/ or
http://linux.f-seidel.de/linux-next/pmwiki/pmwiki.php?n=Linux-next.Linux-next