On Fri, Oct 01, 2010 at 02:17:41PM -0700, Bryce Harrington wrote: > On Fri, Oct 01, 2010 at 07:43:39AM -0700, Rick Spencer wrote: > > 1. I would like us to talk about our Freezes and how we treat them. I > > think certain projects are *always* breaking freezes. I would like to > > discuss if we should stop allowing this, or should we change the process > > to accommodate the needs of these teams, or, perhaps all is fine the way > > it is. The recent Font FFE might be an instructive case to consider > > specifically, but there are probably others as well. > > One thing I would suggest looking at is if the projects in question are > on mis-aligned release schedules. > > Fedora typically releases after Ubuntu, and seems to have a shorter > freeze period than us.
My impression is that we're fairly good at handling freezes for external projects. The ones where our freeze discipline is poor ironically tend to be those that are principally internal and focused on Ubuntu, and that goes across the whole team, not just the examples people often like to use. To some extent this is an organisational trust thing: in the case of a freeze exception for an external project there's always a factor of how well their development practices match up, how much integration work will be involved, whether there are going to be pressures from other distributions, etc.; but for an internal project it's very tempting to say that, oh well, these folks are working within Ubuntu and they must know what they're doing, and besides we already decided we wanted this. Numerically, most of our freeze exceptions actually work out fine, and as a project we tend to focus on the ones that don't. However, I'd like to suggest, perhaps as a strawman, that it has become almost de rigueur to run Ubuntu development projects with such small amounts of slack that the odds of requiring a freeze exception are much higher than they ought to be (and I'm guilty of this myself, so I'm not merely pointing fingers here). The sheer number of freeze exceptions that the release team has to review nowadays is an issue in itself, even if all those freeze exceptions are absolutely sound. How much of this is a part of our development culture that we need to change? Have we got to the point where people quite naturally compare themselves against their peers and say "he seems to get more done than I do, so I'd better push a few more things in as freeze exceptions so that I can catch up"? The work items tracker is good for assessing future capacity, but if many of us are trying to get their numbers as good as possible on that, are we neglecting stabilisation as a result? How can we reward principled and thoughtful decisions to leave things to the next cycle when they'll be readier for widespread deployment, as a product of good judgement rather than underdelivery - and how would we do that without losing momentum? I'm not sure I have many answers at the moment, but the discussion would be worthwhile. -- Colin Watson [cjwat...@ubuntu.com] -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
