X server 1.10 development cycle
keithp at keithp.com
Fri Sep 10 11:41:15 PDT 2010
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?
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
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
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
Anyone want to volunteer to have "their" driver get merged into the
server for 1.10?
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
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
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
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
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
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
Size: 189 bytes
Desc: not available
More information about the xorg-devel