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

Re: Freeze exception for dpkg 1.14.18

Marc 'HE' Brockschmidt <he@ftwca.de> - Sat, 26 Apr 2008 15:07:49 +0200

>Raphael Hertzog <hertzog@debian.org> writes:
>> 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.
>That's bullshit. You can't guarantee that you don't introduce bugs
>along with whatever else you feel to be important. Not touching the
>package can. Therefore, I will only accept release critical fixes and
>l10n updates for dpkg, together with changes to code that is not used
>in lenny (that is "Format: 3.0 .+").
>The fact that you dared to ask on the #-release channel if we would
>allow refactoring shows pretty much how much you understood the concept
>of a freeze.
>This discussion is over from the release team's point of view. If you
>are unhappy with the result, feel free to escalate it to the tech-ctte
>or DPL.
>Hugs and kisses,

Hi All,

you don't know me, but I follow mailing lists activities and try to
become a DD when I'll have shown my work to you (OpenGL related,

Let me respond kindly to your discussions, giving an external point of

IMHO this kind of hard mail exchanges could be avoided if all people
agreed on terms.

I support -release vision that a freeze is a freeze. Raphaël is missing
the point here: freeze deserves to be enforced as much as possible.
It's criminal ;) to allow breaches in such a critical pass of the
project :).

But I also support Raphaël point of view, that dpkg should be treated
with more care, and he would have achieved great success asking for for
that he wants, if :

- a long term plan was set up by dpkg's team,
- anticipating lenny's release that plan was leveraged with other teams,
- priorities were defined so that both teams have strong assurance to
have things delivered in time, for the profit of both, for the profit
of the distribution,

That's for an organisational filter.
Now, for technical matters, RH and dpkg's team has been left alone
facing some interesting problems that would have deserve more
attention from a bunch of talentuous DD around, I explain my point :

- the CFLAGS/LDFLAGS problem should never have been the dpkg's team
responsibility to deal with, that's too serious, and everyone should
have helped :)

- the change of source format should never have been decided to occurs
at that time : too close to the release' date, that's seems crazy to
me ;)

Hopefully everyone will put around the table and improve communication
and responsibility for the success of the next release.

Debian is the one of the most challenging projects out there :). The
projet and its talented members deserve a good synchronization and
accurate priority scheduling.

Best regards,

: :' :  We are debian.org. Lower your prices, surrender your code.
`. `'   We will add your hardware and software distinctiveness to
  `-    our own. Resistance is futile.


Reply to: