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 <[email protected]> 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. _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
