X server 1.9 release thoughts

[Luc Verhaegen]

On Tue, Apr 06, 2010 at 09:30:47AM -0700, Keith Packard wrote:
> 
> 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.
> 

Hi Keith.

>From Daniel Stone's original announcement of the new release process [1] 
it seemed as if the release manager would be choosen from release to 
release, but apparently it is now set in stone. So, congratulations on 
achieving would-be linus status for X.org, i know how long and hard you 
have been striving towards this [2].

>From Daniel his mail, it seems that undoing modularization for only
graphics drivers was aimed for 1.10 instead of 1.9. Is there any reason 
for rushing this?

This means that merging graphics drivers back into the server needs to 
be discussed in full, instead of just being decided ad-hoc by those who 
were at XDC. Please list and explain the advantages that this will bring 
over modular drivers, a tinderbox, and patch review.

Why are you pushing towards a 3 month release cycle? I can only assume 
that this is because the intel portland team has been doing quarterly 
release cycles on their intel driver.

Lumping the proto headers together seems like the first step on a 
complete undo of modularization on the non-driver side as well. Are we 
now backpedalling completely on the big first really big statement X.org 
made?

How does this look technically? Are we not going to get into a libdrm 
like situation, where an update of one volatile part forces a version 
bump of the amalgamut, which in turn forces updates of all the 
dependants, even when they just depend on some otherwise stable parts? 
Are we then not just plainly scurrying towards having the protoheaders, 
the libraries, the library headers and the server all back in one 
repository?

Thanks.

Luc Verhaegen.

[1] http://www.mail-archive.com/xorg-devel@lists.x.org/msg02128.html
[2] http://xfree86.org/pipermail/forum/2003-March/000128.html