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

Re: about volatile.d.o/n

On Fri, Oct 08, 2004 at 04:45:57PM -0700, Thomas Bushnell BSG wrote:
> Duncan Findlay <duncf@debian.org> writes:
> > When spamassassin is upgraded, it's more than just the rules. Often
> > the method of parsing the message is changed -- leading to better
> > results, or support for different tests is added, etc. It would be
> > very difficult to only backport the appropriate changes, and the
> > result would be less stable than the version from which backporting
> > was taking place. On the other hand, each new version makes minor
> > changes to functionality. (Ignore 3.0.0 right now, it's got different
> > issues all together.) To require backported changes would simply be a
> > waste of effort and would defeat the purpose to a certain extent.
> Nonsense.  It would be harder work, and maybe there is nobody around
> to do the hard work.  But it is hardly impossible.

Well, it's possible, but it wouldn't be stable. A version that
consists only of backports is not going to have as many users, and as
a result will have little testing before releasing to
volatile.d.o. Unless you're saying you can find perfect programmers, a
version consisting only of backports will be less stable than a new
upstream version.

I can understand the logic to a certain extent when there is a small
set of changes, but it really doesn't work on a larger scale.
> This is what stability is about.  What you are calling for is
> abandoning Debian's stability judgment to upstream's, in a situation
> where upstream isn't making any stability promises at all.

Not really. I'm just saying that there's necessarily a tradeoff and
you can't have the best of both worlds.

> So backport the appropriate changes only, and find programmers who can
> do a good enough job not to screw it up and destabilize it.

Given a large enough subset of upstream changes, any programmer will
"screw it up", especially in the absence of many users testing.

Duncan Findlay

Attachment: signature.asc
Description: Digital signature

Reply to: