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

Re: Bits from the dpkg maintainer

On Tue, 2005-06-14 at 11:50 +0200, Wouter Verhelst wrote:

> On Tue, Jun 14, 2005 at 10:39:30AM +0100, Scott James Remnant wrote:
> > > Yes, that's what we mean. The reason is that for various things (e.g.,
> > > buildd, ftp-mastery, ...), we need to be able to manipulate source
> > > packages with the tools in stable. Note, I said "manipulate", not
> > > "build".
> > > 
> > Why can't you just install the unstable ones?
> Because we don't run unstable on our project machines for a reason?
You don't have to run everything unstable, you know; just the bits you

An 18-month delay between features being implemented and used
fundamentally results in an 18-month delay between them being
implemented and _TESTED_.

In other words, adding features to dpkg/dpkg-dev in unstable and then
waiting for them to go into stable before using them means that the bugs
aren't found until the feature is already in stable and thus unfixable
until the next stable release.

A recent example of this would be #313400, which has only just been
noticed despite the implementation being 6-months old.  Yet this has
major consequences.

Another example would be the fact that the bzip2-compressed deb support
was broken, and it was only because Ubuntu decided to use it that we
discovered this.  We would have shipped non-working support in stable,
and had to wait another 18+ months before it was useful.

Have you ever, ever felt like this?
Had strange things happen?  Are you going round the twist?

Attachment: signature.asc
Description: This is a digitally signed message part

Reply to: