X server 1.10 development cycle

[Keith Packard]

Looks like the 1.9 server release has gone off fairly well, and I think
the few changes we made in the process helped quite a bit, in
particular, having a release tracking bug made it easy to find things
that people wanted fixed, and several of them actually did get fixed,
including some ancient ones (like bug 3040).

Are there other things we can do to help improve the 1.10 release?

Merging Drivers:

I'm also still interested to hear how we can de-modularize the system to
some extent where it would be useful. Merging the protocol headers into
a single package would be a good step, but it would require someone to
step up and offer to take charge of doing release management for the
whole thing.

I think Peter Hutterer is almost convinced that bringing the input
drivers into the server would help let us fix the API/ABI issues in that
interface faster.

Video drivers seem a bit harder, they're much larger, of course, and
we'd really need a dedicated 'subsystem maintainer' to make that work
inside the server. For drivers using KMS, I think moving them into the
core server would let us refactor them to eliminate the duplicate mode
setting code.

Anyone want to volunteer to have "their" driver get merged into the
server for 1.10?

Release Schedule:

While most of the 1.9 cycle seemed to work fine from my perspective, it
seemed like it dragged a bit at the end. There were only 10 patches in
the last week before release. However, all of the core patches in that
last week were well reviewed, and fixed obvious regressions or crashes.

I asked about changing the length of the release cycle last time and it
seemed to me that the general consensus was that we should leave it at 6
months, at least for now. I'm OK with that; we don't have so many
changes coming into the server than a 3 month cycle seems required. If
we start integrating video drivers into the server, we may want to
reconsider to make sure we can get support for new hardware out in a
timely fashion.

So, if we're leaving things the same for this release, I think that
makes the schedule look something like:

Merge window closes:            2010-12-1
Non-critical bug deadline:      2011-02-1
1.10 Release:                   2011-02-18

External Repositories:

Yes. Please. If you're doing work on the X server and want to share that
among multiple developers, please publish a git repository containing
your changes. There's absolutely no reason to gate work on a single
repository branch.

Patch Merging Process:

Here's a copy of the text posted with the 1.9 schedule.

 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 (except in the
    case of huge white-space or other automated changes). 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.

Thanks again for everyone's work on the X server, and keep on coding.

-- 
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/20100910/bd95d1ff/attachment-0001.pgp>