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

[Keith Packard]

On Mon, 21 Jun 2010 16:04:51 +0300, Tiago Vignatti <tiago.vignatti at nokia.com> wrote:

> Yes, we have significant work happening right now: clean-up. It's a feature as
> desirable as any other.

I'm not saying there isn't significant and useful work going on, but
that we aren't seeing long-term development and testing happening
asynchronously from the master branch. As such, master continues to gate
exposure of much of the new development work to a wider audience.

> 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.

Am I still dropping patches on the floor somehow? I've got a bunch of
cleanup patches from you and a few from Mikhail sitting here that are
awaiting some kind of resolution as to whether they should be merged
post-RC1 or not. Aside from that, there are a few bug fixes that I'm
merging today at which point I'll do RC2 and post the list of pending
patches that haven't been merged yet.

> 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
> months maybe?

Daniel's point here is that a shorter release cycle will increase the
number of releases that we as a community need to maintain as upstream
and in distributions. Having to do security updates for one release is
hard enough, having to do them simultaneously for many releases would be
even harder.

> 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
> really needed.

Yes, and pulling from those has been a lot easier than merging patches
in by hand, which has been great. The distinction here is that these
trees don't get independently tested. This is not to diminish the value
of publishing the trees in any way, just that we don't have a huge
number of people with time to kill testing random X server trees,
unlike, say Linux.

> 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.

For input stuff, I'm trying to let Peter manage them and send pull
requests. When I mess up, he politely informs me to not merge patches
that are in his tree as that simply increases his workload.

There are other registered maintainers for various subsystems, but that
file is hard to find as it lives in the xorg-docs repository instead of
the X server and has a lot of stale information.

I think we should pull the X server bits out of that and stick them in
the xserver doc subdirectory and then try to get that up-to-date. When
someone obviously 'takes over' a particular subsystem, we should expect
a patch to the MAINTAINERS file along with the code change. Our usual
review process can be amended to have reviewers consider the lack of
such a change as a reason to reject large patches.

-- 
keith.packard at intel.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.x.org/archives/xorg-devel/attachments/20100621/d087e4ac/attachment-0001.pgp>