|| ||Keith Packard <keithp-aN4HjG94KOLQT0dZR+AlfA-AT-public.gmane.org> |
|| ||xorg-devel-go0+a7rfsptAfugRpC6u6w-AT-public.gmane.org |
|| ||X server 1.9 release thoughts |
|| ||Tue, 06 Apr 2010 09:30:47 -0700|
|| ||Article, Thread
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
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
Merge window closes: 2010-6-1
Non-critical bug deadline: 2010-8-1
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-go0+a7rfspubup2nOX2J7Q@public.gmane.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
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-go0+a7rfsptAfugRpC6u6w@public.gmane.org and Cc:'d to the release
(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
xorg-devel-go0+a7rfsptAfugRpC6u6w@public.gmane.org: X.Org development
to post comments)