X server 1.9 release thoughts

[Keith Packard]

First off, thanks to everyone involved in the 1.8 release; it was a
pleasure to work with you. I'm hoping everyone else is as happy as I am
about our new release process, it seemed to me that we saw a lot more
active review and discussion about proposed patches this time around.

For version 1.9, I'm planning on doing things in much the same way, if
people have suggestions on how we can improve things, please post them
so we can get things settled before we get too far into the release.

Ok, so now for the details about the 1.9 release itself.

First off, I'd like to get a start on making things easier to build
for people interested in testing the server or new drivers. I'm still
interested in getting drivers pulled back into the server itself at some
point, but it seems like an important and trivial first step will be to
merge all of the protocol headers into one package. I'll get started on
that and post a pointer to a merged repository for review.

Beyond that, one requirement that I see for merging output drivers would
be to shorten the X server release from the current 6 months down to 3
months or so. Otherwise I feel that the window of time between hardware
release and driver release could become too long. I'm up for this
cadence, but it would mean that we'd need to see major patches posted
and reviewed in the previous release cycle so that they could be applied
shortly after a release. I don't want to shorten the RC schedule by
much. If ABI/API churn is an issue, we could try freezing those for the
'odd' releases, but I'd rather avoid that as it can artificially
constrain development.

For 1.9, I'd like to shorten the schedule a bit, if that works for other
people. It seems like releasing around mid-late August would better
align with the Beta schedules for Fedora, Ubuntu and MeeGo. If that
seems reasonable to most people, I'd like to propose the following
schedule:

Merge window closes:        2010-6-1
Non-critical bug deadline:  2010-8-1
Release:                    2010-8-20

I don't think there are any major changes planned for this release, so
this shorter merge window seems like it should be sufficient. Nor do I
necessarily think that this would also mean that the X.org release date
should be moved in; having the X server ready *before* the X.org release
seems like a good idea to me. I'll be doing periodic release candidates
starting with the close of the merge window.

This schedule would mean that anyone with changes they've been working
on should get them posted now. Independent of the 1.9 release schedule,
I'd like to encourage people to post patches as soon as possible anyway;
there's no reason to wait until the feature merge window is open to get
code reviewed, the merge window is supposed to be about getting changes
lined up for the server release.

Finally, some notes about what our current process is, just to remind
everyone of what I think the rules are:

 1) Post all proposed patches to xorg-devel at lists.x.org. All patches
    must have Signed-off-By: lines attached. I think every patch
    should be posted and not just a link to a git repository. I do
    patch review off-line, having things in my inbox makes that really
    easy.

 2) Review as many patches as you can stand. Even if you don't know the
    area that the code touches, please feel free to post comments about
    style, grammar and the patch description. A 'Reviewed-by:' line
    doesn't have to say 'I know this code will work', only that you
    think that the patch is ready for merging.

 3) Test patches that change stuff you care about. If there's a piece of
    code that touches something that you know about or use regularly,
    please give it a try and see what it does. If things appear to work
    as advertised, please reply with a 'Tested-by:' line.

 4) Ack patches that you think are necessary. An 'Acked-by:' line should
    signify that the patch purports to do something that you think is
    necessary or useful, but that you haven't reviewed in depth or
    tested it. I'd like to encourage people who see an Acked-by line to
    consider reviewing and testing the associated patch; all things
    being equal, patches that lots of people want should probably be
    higher priority than other patches.

 4) Patches that are both ready for merging and which conform to the
    release schedule policy should get updated with all Reviewed-by:,
    Acked-by:, Tested-by: and Signed-off-by: lines inserted and then
    sent back to xorg-devel at lists.x.org and Cc:'d to the release manager
    (that's me for 1.9). You can either send them as patches to the
    list, or as pull requests. Patches should contain the word 'PATCH'
    in the subject while pull requests should contain the word 'PULL'.

Here's some Do's and Don't's:

 1) Do post patches as soon as you think they're ready for review. They
    do not have to be 'finished'. The earlier you post big changes, the
    sooner we can get agreement on how such things should be done. Send
    them as patches, not pull requests so that we can see the code
    without needing to pull from your git repository.

 2) Do not Cc: the release manager with patches that have not been
    posted to the list before, or patches which haven't seen
    sufficient review.

 3) Review, test and acknowledge patches early and often. The more
    people we get looking at the code, the better things go.

 4) Review all aspects of a patch, from the coding style to the grammar
    in the comments. Be constructive and remember that many (most?) of
    the people in our development community are not native English
    users.

-- 
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/20100406/b9007035/attachment-0001.pgp>