Freeze exceptions for gcc-* (was: Re: Freeze exception for dpkg 1.14.18)
Raphael Hertzog writes:
> On Sat, 26 Apr 2008, Luk Claes wrote:
> > > Here's what I would like to suggest as acceptable for lenny (and thus
> > > 1.14.19):
> >
> > Freeze guidelines are not really up to discussion and I don't like that
> > maintainers of key packages send the signal that they don't care about
> > them...
>
> I'm sorry, I do care about the goal of the freeze: "release a top quality
> distribution in the planned timeframe".
>
> But I really dislike "dogmatic" answer like your "I want zero changes
> because that's the way it is". If you don't want to consider the
> proposition based on its merit concerning the risks for the release in
> terms of delay and quality, I'll seriously consider bringing this issue up
> to the tech-ctte (and no, it's not because I want to annoy anyone, it's
> just because decisions must be made on technical merits and nothing else,
> and because I really care about the few changes that I mentioned).
>
>
> You should also consider that while dpkg is a key piece of our
> infrastructure, it's also maintained by very active people in the project
> itself and that we know what we are doing. In some ways, it seems unfair
> to have similar freeze criteria for external software just packaged by
> Debian and software developed by Debian where we have absolute control
> over it (and where we know what we're doing with it).
>
> > You say that dpkg won't delay the release while questioning the freeze
> > guidelines in itself is probably enough for other package maintainers to
> > make sure the release will be delayed...
>
> As I said, there's grounds for treating "native" software differently from
> all other software that is just "packaged" within Debian... exactly like
> there's a reason why we don't freeze the installer or the kernel now. But
> they both play a significant role in the whole picture.
>
> Please think about it.
Same thing about GCC; before making 4.3 the default on some
architectures I asked single members of the release team if regression
fixes and bug fixes were allowed after the freeze, which was not
denied at this time. I don't plan to upload a new GCC version from
the trunk but follow the branches until the next subminor releases
[1], [2]. On the branches only regression fixes are allowed. Plus
there will even be a new feature introduced (ObjC for armel). I do
see these updates as part of getting more quality into the
distribution.
Matthias
[1] http://gcc.gnu.org/ml/gcc/2008-04/msg00449.html
[2] http://gcc.gnu.org/ml/gcc/2008-04/msg00243.html
Reply to: