New release process for 1.8 (READ THIS)

[Eric Anholt]

On Thu, 2009-10-01 at 11:59 +1000, Dave Airlie wrote:
> On Wed, 2009-09-30 at 18:35 -0700, Daniel Stone wrote:
> > Hi all,
> > Following on from Peter's email about the 1.8/7.6 release process[0], we
> > had a BoF about the same[1] at XDC.  Everyone broadly agreed on the
> > substance of Peter's mail, and here are our rough conclusions.
> > 
> > Release process: We're going to aim for a six-month release process, as
> > Peter outlined, with 3 months feature freeze, 2 months bugfix, and the
> > final month release freeze.  We're going to start this for 1.8, and
> > hopefully we'll be able to land predictable releases.
> > 
> > 7.6: Either Peter or keithp will be the RM: they can arm-wrestle for it.
> > I assume the six-month cycle will start on the day 1.7/7.5 is released
> > (hopefully Monday).
> > 
> > Development model: xserver master will be closed to general commits; it
> > will be owned by the RM, or one of their delegates.  Again, DO NOT
> > COMMIT DIRECTLY TO XSERVER MASTER.  Everyone should have their own
> > xserver trees, and/or one per subsystem (I'll have xserver-xkb and an
> > input tree, I guess Peter will have an input tree, there should be an
> > EXA tree, etc, etc).  When you want to push something to master, either
> > send patches to the list, or send a pull request for your tree.  ajax
> > has quite unwisely volunteered to run a trivial-patch tree, accumulating
> > random misc.  When you send a pull request or patches, it's expected
> > that they've been tested and are working to preserve bisectability, and
> > don't destroy ABI every other commit, so feel free to buffer them up a
> > bit.  Judicious use of rebase -i is not wholly discouraged.  I know this
> > sounds concerning, but if your merge request just gets forgotten or
> > dropped on the floor, bug us until we make it happen.
> 
> My main issue with this is, while we'd like to be the kernel, we have in
> no way got the developer/testers bandwidth they have. Generally when
> developing a feature for the kernel, you can find someone else to
> interact with while you write the code and bounce it around to get the
> bugs out, etc.
> 
> With X generally requests for testing things no on master and not
> directly affecting another developer at that point go unnoticed, the
> only way stuff really gets tested in X is indirectly, by people cloning
> master and running it, its unfortunate but I don't think its due to our
> process but lack of bandwidth.
> 
> So I feel locking down master is going to get messy fast, I agree
> all major developments should be done on branches, but we have many
> incremental improvements in areas like EXA where we have no fulltime
> developers working on it and the only real way for it to get tested
> across drivers is to shove it into master. Also having things in master
> means you get indirect cross testing, so if I want to add something new
> I end up having to test all the new stuff other people have merged.
> 
> The other thing is we need to stop being afraid of git revert I think
> judicious use of revert could resolve a lot of our problems (read:
> _X_EXPORT). We also get to keep history of why we hated something.
> 
> > Future: Around 1.10, we'd like to merge the drivers back into the core
> > so we can start getting a coherent API (well, any API would be a start).
> > We're also working on a much better testing model, with functional
> > testing as well as XTS, so we can exercise modesetting, input
> > functionality, real-world rendering, etc.
> 
> \o/, I got the shit shot out of me for suggesting that last year,
> wonders whats changed.

I was one of the ones saying "nooo this is a terrible idea" last time.
My main concern at the time was that the master branches of drivers were
pretty scary places, and I couldn't imagine us trying to get a stable
release cut where people would actually want to pick up the server.

I'm less afraid of this now.  With both intel and radeon racing to the
glorious KMS future, less of the nasty "we can't release with these
hard-to-fix driver bugs" should be around when we're trying to push a
server out.  We're already managing to produce working releases of the
driver stuff through the linux kernel process (that looks a lot like
what we're proposing to do for server), easily comparable to what we'd
been doing in the old X model, I'd say.

And, for Intel's release process, if we we have issues with the release
scheduling, functionality, etc. of master, we can always do our release
off of a stable branch of the server tree.

I like the idea of the new process, and if we can get it to work well
and pull the drivers in, I think it'll be a big help for getting people
to feel safe in testing master and actually do so before releases.  I
know I haven't been updating the server very often in the last year or
so, as I've cherished the few working checkouts I've found.

-- 
Eric Anholt
eric at anholt.net                         eric.anholt at intel.com


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
Url : http://lists.x.org/archives/xorg-devel/attachments/20091002/742b45fd/attachment.pgp