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

Re: RFD: Draft for a volatile.d.o policy

Thomas Bushnell BSG [u] wrote on 09/10/2004 19:12:

Sven Mueller <sm@leogic.com> writes:

Doing a backport of some upstream change is usually a pretty difficult
task (except for smaller security fixes). It's pretty easy to claim
"no new command line feature added", but it is pretty difficult to
claim "no new bugs added" or "all necessary security fixes added".

It's in fact so difficult, that this is exactly why we don't just
allow arbitrary changes to stable things, and relabeling them
"volatile" and "optional" doesn't actually change the matter.

Right. We don't want arbitrary changes - as you call it - allowed into the main stable release. What is proposed here however is a way to allow users to opt-in on changes like that.

We might need a method for allowing really important upgrades in to
stable, which preserve stability, and we have that now for regular
stable proposed updates, for security, and we could add it for virus
scanners and the like.  But in all those cases, we need the same
concern for stability.

Well, that would be nice to have. However, these updates would most likely still be far too infrequent. And there are quite a few people around, which are ready to accept a (very) low possibility of added instability for having optimal performance with this kind of software. What most people in this thread seem to see in volatile.d.o is an opt-in to get certain packages ported to stable in a cutting-edge like fashion. Not really bleeding-edge, but newest upstream release which is stable enough for production. I certainly wouldn't like to see - say - SpamAssassin 4.0 in volatile on the very same day it was released upstream. But I would like to see it in there as soon as it has proven to be stable enough for püroduction and it has also proven to not interfere with the stability of the rest of the system.

Saying "it's really hard" is not a good excuse!  People are doing it
for those other packages all the time.

You are comparing apples and oranges here. Backporting a security fix for some software usually only affects a few lines of code. Backporting an updated scanning engine for a virus/spam/network scanner is something completely different. We might want to set some sort of limit as to which kind/size of change has to be backported and which kind/size of change can warrant an update to the current stable upstream release.

These are packages that become less useful over time, not because
upstream releases new versions with new features, but because the old
features aren't enough to fulfill the original tasks anymore.

Right, and I'm happy to see that done, provided that only the new
features are allowed which actually keep the particular utility in

I'm sorry, but for the idea of volatile.d.o most people in this thread expressed (i.e. IIRC only you seem to object to that idea), this limitation is not intended. However, I see the value of that kind of limitation, but I would like to see the kind of policy you seem to have in mind to be used for updates to the regular stable release.

I know this policy is not really to the taste of Thomas Bushnell,
especially because new features _might_ be introduced.

Heh, but compromise is always possible, and I'm interested in hearing
what other people say about this proposed policy before I comment
further on its details.

You're welcome.


Reply to: