On Fri, Oct 08, 2004 at 04:45:57PM -0700, Thomas Bushnell BSG wrote: > Duncan Findlay <[EMAIL PROTECTED]> 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