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.
>
> 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.
>
> So backport the appropriate changes only, and find programmers who can
> do a good enough job not to screw it up and destabilize it.
>
> Thomas
Thomas,
The more the discussion goes on, the more value I see for this emphasis.
I started with clamav in mind as my archetypal example program.
But defining the class of programs, finding a form of words, is more
dificult than it at first appears. Take 'useless' for example. Elsewhere
in the thread <person> makes the point that hardware drivers could come
into the 'useless' category, and I know exactly what he means: I've been
there. But, I wouldn't want to have make X11 or kernels in volatile work:
sounds like a world of pain.
I got to thinking. In many ways the volatile conversation, is like the
one which goes 'can we have a five year EOL so that oracle will support us'.
Both deal with having a release cycle which is different from the status
quo, and other general discussion on that subject is often heard.
The appearance of volatile.d.n suggests to me that Debian is continuing to
grow in a healthy way. Perhaps deepfreeze.d.n (or whatever) is waiting in
the wings, or other things.
I could imagine maintaining clamav against a 5 year old codebase
(I do something not so different to that now). clamav is in C, and
reasonably self-contained. The version skew doesn't really get to you.
The perl based stuff is a bigger problem.
I guess I'm saying two things:
Ultimately the general rule _always_ has be
'backport the appropriate changes only'.
Perhaps maintainers of candidates for volatile will want to take a
cautionary second to imagine what it might be like to be working
against that five-year-old codebase.
And the reason I'm saying these things is that I think that volatile
and main archive, 'deepfreeze-or-whatever' or whatever comes along
will be at their best if they all work together, rather than being
seperate little islands.
Regards,
Paddy
--
Perl 6 will give you the big knob. -- Larry Wall
Reply to: