X server 1.9 release thoughts

[Peter Hutterer]

On Sun, Apr 11, 2010 at 06:49:56PM -0700, Keith Packard wrote:
> On Sun, 11 Apr 2010 18:14:33 +0200, Michel Dänzer <michel at daenzer.net> wrote:
> 
> > There were a number of cases where breakage wasn't fixed for days
> > because nobody else was allowed to push the fixes.
> 
> This is good feedback, thanks. Can you point out specific cases and we
> can figure out what went wrong? 

there was at least one case where master was broken for a week or more
although the patches were sitting reviewed on the list (and I even sent a
pull request). and IIRC in that case a 1.7 release was relying on those
fixes too.

> There are a couple possible sources of failure that I can think of:
> 
>  1) The release manager disappears for a few days. Ideally, they'd be
>     available 24x7, but in reality, that's not going to happen. Business
>     trips, and even an occasional vacation can halt stuff heading into
>     master.
> 
>  2) The patches to fix a bug aren't ready. Either the proposed fix for
>     a regression doesn't make everyone happy, or the patch just isn't
>     getting any review.
> 
> In the first case, I think it's probably a good idea to simply have a
> back-up person who can push stuff to master while the release manager is
> afk. Would Peter (our 1.8 stable maintainer) be willing to do this? My
> thinking here is that often the most critical patches are those which
> also need to be added to the stable tree.

I really wouldn't mind if someone else can pick this up, mainly to get an
extra pair of eyes to it. Also, ETIME and whatnot.

> In the second case, it might be that the best plan is to simply revert
> whatever code was added which causes the bug until the whole sequence is
> fixed. If caught early, this shouldn't be hugely disruptive. We could
> even adopt a policy that lets more people revert patches -- something as
> simple as allowing a subsystem maintainer, or even the original patch
> author, to get code back out of the server might reduce the window of
> brokenness.

fully agree.

> I'd also like to continue to encourage subsystem maintainers to publish
> a tree with their current patches. When they're ready, just ask me to
> pull them in instead of pulling patches off the mailing list. You can
> publish a tree anywhere you like, including people.freedesktop.org. For
> anything more than a handful of patches, this seems more reliable to
> me. Of course, this is just for patches which are ready to be merged;
> patches under discussion should hit the mailing list.
> 
> Peter has been doing this for input and I think it's worked fairly well.

yes, with a few exceptions where I pinged you to speed things up a bit, I'm
quite happy with how things went. The few problems we ran into over the
cycle have been pretty much addressed now.
- both picking up a given patch, mostly "meh", git handles this nicely.
- delays in pulls, this is largely fine now though sometimes it's annoying
  since the 1.7/1.8 policy requires that fixes be in master first. so what
  often happens is that I cherry-pick too soon from master, rather than
  letting it sit there first for a few days to maturee.
- partial pulls (at least once you just cherry-picked some patches from my
  tree instead of refusing the whole lot). I think you stopped doing that,
  that was my biggest gripe.

Juggling the branches is sometimes tedious but generally I can recommend to
send pull requests over patches. for me, it means I'm in charge of the
patches until I push them to my repo and I don't have to check if you missed
one or not, etc.

not all is perfect, but for me this cycle was working better than the
1.6-1.7 cycle and master was generally in a testable state.

Cheers,
  Peter

> > One thing that's sorely needed again is a blocker/tracker bug at least
> > for the x.y.0 release. It's been my impression that 1.8.0 was released
> > with a few bugs that should have been fixed or at least seriously
> > considered before, but apparently nobody really had an overview of the
> > situation. In the run-up to 1.7.0 and earlier releases, I would
> > regularly go through the list of blocker bugs and try and fix some of
> > them. (The motivation for that would have been lower now due to the new
> > process costing excessive time and effort to get in simple fixes, but it
> > would have been better)
> 
> Yes. I felt a bit at sea in the last week or so running up to the
> release; there really wasn't any sense of what needed to be done. I've
> always liked the tracking bug plan in the past.
> 
> Bug 27592.
> 
> The big commitment that I'd like to see us make is to avoid regressions
> From the previous release, so any tracking bug should have a big warning
> label on bugs which are regressions. Bugs which aren't regressions would
> be significantly lower in priority and would have to be pretty bad to
> block a release.