New release process for 1.8 (READ THIS)

[Michel Dänzer]

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.

I share your concerns, though branches in the main repo might be a
little better than hiding stuff in personal repositories.


> > 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.

This took me by surprise as well - when/where/how was this decided? I
didn't have the impression that there was 'broad consensus' for this,
and I certainly can't say I like the idea.


-- 
Earthling Michel Dänzer           |                http://www.vmware.com
Libre software enthusiast         |          Debian, X and DRI developer