[Pkg-xfce-devel] Xfce plans for the lenny cycle

[Steve Langasek]

On Wed, Apr 18, 2007 at 03:38:59PM +0100, Simon Huggins wrote:
> On Tue, Apr 17, 2007 at 06:11:29AM +0200, Steve Langasek wrote:
> > On Fri, Apr 13, 2007 at 10:40:34AM +0100, Simon Huggins wrote:
> > > Also, padding is extremely frustrating.  The 4 month wait from December
> > > to April effectively froze uploads from October/November[0] until April
> > > which seemed a little too long.  If developers believe that you're
> > > releasing in say October then we'll be more careful about uploads a
> > > long time before the freeze but if we believe you're saying you're going
> > > to release in October but really will slip by 4 months then we (and
> > > presumably other developers) won't bother and your job becomes harder.
> > And IMHO an appropriate response from the release team to such acts on the
> > part of maintainers would be to kick the affected packages clean out of the
> > release with no option of being readmitted.

> > Timeline gaming and other selfish behaviors on the part of individual
> > maintainers are a huge reason why Debian has a history of missing its
> > release targets by such a wide margin[0].  If you care about timely
> > releases and minimizing the out-of-dateness of software at the time of
> > release, the responsible thing to do is to be /less/ selfish in
> > response to schedules proposed by the release team, not to try to
> > elbow your way past all other maintainers for the privilege of being
> > the last uploader of untested packages to be included in the release.

> I do care about timely releases and I hope you didn't think we were
> selfish or trying to elbow our way past other maintainers during the
> etch freeze.

Indeed not; but there are certainly developers who in effect do exactly
this, and delaying the start of the freeze would also mean delaying the
*end* of the freeze because of the newly-introduced RC bugs that would have
to be fixed.

We froze when we did because we had effectively reached the break-even point
where newly-introduced RC bugs entering testing were approximately equal to
the RC bug*fixes* entering testing.  Delaying the freeze would not have had
an appreciable benefit for etch as a whole.

> There are always things that miss a release but had the freeze been
> pushed back to February say (two months before the release as per the
> original Oct -> Dec intention) then the January release of 4.4.0 may
> well have been deemed stable enough to ship.  Who knows.

Yeah, but we'd be shipping in June instead of in April (per the above), and
it would be someone else complaining that their new upstream version was cut
off right before the freeze. :)

> > And, oh yeah, "we really mean that we want to release on date <X>" has
> > no more power to compel maintainers to get their packages into a
> > releasable shape than any other stick.

> No, of course not.  But if the project as a whole genuinely believes you
> then I believe that the timeline gaming and selfish behaviours of
> maintainers would be lessened.  I guess trying to alter the mindset of
> over 1000 people is hard but I think it's worth trying.

I'm puzzled that you would draw the conclusion that the release team hasn't
*been* trying.  Do you have some magic potion for making the project as a
whole believe in and support release targets, that doesn't involve the
bootstrapping problem of first getting a release out "on time"?

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
vorlon at debian.org                                   http://www.debian.org/