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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
