X server 1.9 release thoughts

[Keith Packard]

On Sun, 11 Apr 2010 18:14:33 +0200, Michel Dänzer <michel at daenzer.net> wrote:

> There were a number of cases where breakage wasn't fixed for days
> because nobody else was allowed to push the fixes.

This is good feedback, thanks. Can you point out specific cases and we
can figure out what went wrong? There are a couple possible sources of
failure that I can think of:

 1) The release manager disappears for a few days. Ideally, they'd be
    available 24x7, but in reality, that's not going to happen. Business
    trips, and even an occasional vacation can halt stuff heading into
    master.

 2) The patches to fix a bug aren't ready. Either the proposed fix for
    a regression doesn't make everyone happy, or the patch just isn't
    getting any review.

In the first case, I think it's probably a good idea to simply have a
back-up person who can push stuff to master while the release manager is
afk. Would Peter (our 1.8 stable maintainer) be willing to do this? My
thinking here is that often the most critical patches are those which
also need to be added to the stable tree.

In the second case, it might be that the best plan is to simply revert
whatever code was added which causes the bug until the whole sequence is
fixed. If caught early, this shouldn't be hugely disruptive. We could
even adopt a policy that lets more people revert patches -- something as
simple as allowing a subsystem maintainer, or even the original patch
author, to get code back out of the server might reduce the window of
brokenness.

I'd also like to continue to encourage subsystem maintainers to publish
a tree with their current patches. When they're ready, just ask me to
pull them in instead of pulling patches off the mailing list. You can
publish a tree anywhere you like, including people.freedesktop.org. For
anything more than a handful of patches, this seems more reliable to
me. Of course, this is just for patches which are ready to be merged;
patches under discussion should hit the mailing list.

Peter has been doing this for input and I think it's worked fairly well.

> One thing that's sorely needed again is a blocker/tracker bug at least
> for the x.y.0 release. It's been my impression that 1.8.0 was released
> with a few bugs that should have been fixed or at least seriously
> considered before, but apparently nobody really had an overview of the
> situation. In the run-up to 1.7.0 and earlier releases, I would
> regularly go through the list of blocker bugs and try and fix some of
> them. (The motivation for that would have been lower now due to the new
> process costing excessive time and effort to get in simple fixes, but it
> would have been better)

Yes. I felt a bit at sea in the last week or so running up to the
release; there really wasn't any sense of what needed to be done. I've
always liked the tracking bug plan in the past.

Bug 27592.

The big commitment that I'd like to see us make is to avoid regressions
From the previous release, so any tracking bug should have a big warning
label on bugs which are regressions. Bugs which aren't regressions would
be significantly lower in priority and would have to be pretty bad to
block a release.

> This seems inconsistent with the usage of this tag in the Linux kernel
> development process. If we're going to continue shoehorning our project
> into that process, we should avoid such inconsistencies, or it'll be
> even worse than merely imposing a process from a different project
> without serious consideration of the goals and properties of that
> process and whether those are desirable for our project.

Sorry, I didn't mean to make it inconsistent; can you explain what you
think the Acked-by line means?

-- 
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/20100411/a2ec9181/attachment-0001.pgp>