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