[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Freeze exception for dpkg 1.14.18



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/


Reply to: