New release process for 1.8 (READ THIS)

[Peter Hutterer]

On Thu, Oct 01, 2009 at 11:59:05AM +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

feature _merge_, I suspect.

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

Question: tree on people.fdo or branch on the main repo?
branches on the main repo have the advantage of the commit list which
provides some chance for patch review.

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

The question is: why are people only testing master?

Three reasons come to my mind:
- it is documented how to get master (well, and no-one is actually using
  private trees)
- no-one has incentive to test a personal tree instead of master.
- master is better (??)

Once you fix the first two, you will get testers. The last point is moot, it
means you should be pulling in master more often. And then the tester
bandwidth is less of a problem since everyone is testing master anyway.

For example, if I have an input fixes tree that's pulling in master
regularly, once I convince some testers to use my tree there shouldn't be an
incentive for them to switch back. Anything in master they'll get anyway and
on top they get the input fixes for pre-testing.

For feature branches it becomes more problematic. You need to provide some
incentive to test that feature. I can speak from first-hand experience that
asking testers to switch to a private tree, compile inputproto, x11proto,
libXext, libXi and libX11 from custom branches is acceptable :)
But providing the incentive may be difficult for some features.

Note that this is a process change, as we change the development process,
testers will hopefully adapt. Is it going to work from the first week
onwards? Probably not. But it may just get better over time.
(we will need a review of the process after or close to 1.8.0 to check
what has worked and what hasn't anyway)

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

Master isn't completely locked down though, if you have a patch it'll still
get committed soonish after you send it to xorg-devel and you get the same
testing exposure as before. The only difference is that at least one more
person laid eyes on that patch before committing.

AFAIUI the merge windows are open, so you can ask for a merge to master or
send a pull request at any time.

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

that I fully agree with.

One more item:
If you've tested or reviewed something, send a Tested-by or Acked-by. It
helps us to get an overview of what has been tested (and who's testing
what).
Maintainers: Don't lose these when merging a patch.

Cheers,
  Peter