Hello, the release team didn't respond officially yet to our freeze exception request. However Luk told us on #debian-release that you are basically ok with all those features (despite the impact of some of them). Luk didn't want to push this version directly, he'd rather wait an upcoming 1.14.19 with some of the latest bug fixes.
When discussing what's ok for 1.14.19, Luk told: <luk__> ok for 1.14.19 are RC bug fixes, RG bug fixes, translation updates, documentation updates and pre-acknowledged important bug fixes probably <braindmg> luk__: so no refactoring nor trivial bug fixes? <luk__> indeed, it's freeze time... I believe this is too strict and doesn't match reality. We have no open RC bug currently, so given this criteria, there's no reason to wait for 1.14.19. We do have a RG bug (#454694) but fixing this bug is probably more risky wrt release than most trivial bugfixes. Here's what I would like to suggest as acceptable for lenny (and thus 1.14.19): - simple and trivial bugfixes - regressions compared to older dpkg/dpkg-dev versions - of course documentation/translation updates - any change in the code that concerns the new source package formats given that this code is not yet in production use (but it must be in its finished form in lenny so that we can use it in lenny+1) Furthermore, I want to implement one structural change and it concerns the latest changes in dpkg-source (see http://lists.debian.org/debian-dpkg/2008/04/msg00045.html for the details). I'll opt for solution 2 as it's the less disruptive solution. I'll implement this soon. If I don't do this know, we'll be blocked with a bad design decision of mine. This concerns dpkg-source directly and not only the new source package formats, however it can be seen as a fallout of the whole dpkg-source refactoring. If the release team wants a review of each "bugfix" that we plan to push for lenny, then please appoint a dedicated release team member to this task so that we can work more closely with him. Feel free to review what's currently already committed for dpkg 1.14.19 and voice any concern: http://git.debian.org/?p=dpkg/dpkg.git;a=shortlog Last word, I know some of you are upset with the destabilizing changes that 1.14.18 brought, but we were aware of that and offered you a possibility to refuse the most destabilizing change (CFLAGS and all). Quite similarly, we are well aware that we are in freeze now and we believe you can trust us to decide what's safe for lenny and what's not. Furthermore, we _are_ responsive in case of problems and it's not like dpkg is going to be a blocker for lenny's schedule. Of course, we're not opposed at all to a review of the changes by a release team member but we'd like to avoid the high cost of having to send individual patches to -release for review. Hence the suggestion to appoint a dedicated RM/RA to work with us. Cheers, -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
