Re: RFD: Draft for a volatile.d.o policy
Thomas Bushnell BSG [u] wrote on 09/10/2004 19:12: Sven Mueller <[EMAIL PROTECTED]> 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 place. 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. cu, sven
Re: RFD: Draft for a volatile.d.o policy
Sven Mueller <[EMAIL PROTECTED]> wrote: > == > > Draft for a volatile.debian.org packaging and update policy. > [...] > Policy for v.d.o > [...] > - A new version uploaded to v.d.o should restrict itself to new code >which is needed to keep fulfilling the original task of the package >when it first entered v.d.o. Why not: "of the package when the last stable distribution was released"? Besides that, it sounds quite well. Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Re: RFD: Draft for a volatile.d.o policy
Frank Küster [u] wrote on 10/10/2004 19:17: >> Sven Mueller <[EMAIL PROTECTED]> wrote: > == Draft for a volatile.debian.org packaging and update policy. > >> [...] > Policy for v.d.o > >> [...] > - A new version uploaded to v.d.o should restrict itself to new code which is needed to keep fulfilling the original task of the package when it first entered v.d.o. > >> >> Why not: "of the package when the last stable distribution was >> released"? Quite simple: Say a new open source network security scanner enters the world, and it works well when compiled against Debian stable, we might want to add it to v.d.o even though it wasn't available when the last stable distribution was released. Or a new version of clamav is released, which sadly breaks compatibility, so we rename it to clamav2 and it can still be released through v.d.o, similarly to exim4 entering debian alongside exim a while ago. >> Besides that, it sounds quite well. Thanks. BTW: I am prepared to help volatile.d.o to spring to life as much as possible. This includes helping to keep orphaned packages up-to-date in v.d.o if the need arises for some reason. This also might include working on a sort of security team for v.d.o (I think both jobs should actually be combined in v.d.o). IANDD though, but if needed, I will apply to become one. cu, sven PS: Sorry for also sending this reply in private, didn't mean to do that.
Re: RFD: Draft for a volatile.d.o policy
Sven Mueller writes: > Say a new open source network security scanner enters the world, and it > works well when compiled against Debian stable, we might want to add it > to v.d.o even though it wasn't available when the last stable > distribution was released. Or a new version of clamav is released, which > sadly breaks compatibility, so we rename it to clamav2 and it can still > be released through v.d.o, similarly to exim4 entering debian alongside > exim a while ago. Those things belong in the non-existent backports.debian.org, not in volatile.debian.org. > This also might include working on a sort of security team for v.d.o (I > think both jobs should actually be combined in v.d.o). v.d.o. should be supported by the Debian security team. I don't think it is worth doing if it can't be. One way to help make sure Debian security can support it is to keep it as small and simple as possible. -- John Hasler
Re: RFD: Draft for a volatile.d.o policy
John, On Mon, Oct 11, 2004 at 06:48:00PM -0500, John Hasler wrote: > Sven Mueller writes: > > Say a new open source network security scanner enters the world, and it > > works well when compiled against Debian stable, we might want to add it > > to v.d.o even though it wasn't available when the last stable > > distribution was released. Or a new version of clamav is released, which > > sadly breaks compatibility, so we rename it to clamav2 and it can still > > be released through v.d.o, similarly to exim4 entering debian alongside > > exim a while ago. > > Those things belong in the non-existent backports.debian.org, not in > volatile.debian.org. I disagree. define 'breaks compatibilty'. As long as it _is_ still the same package, (For an example of the converse, I direct you to apt-proxy) then the change in name is just an artifact of the upstream versioning and the packaging system. Basing policy on an implementation detail that should be used for technical reasons, simply for lack of doing the work to arrive at a proper description, would be a mistake. (not that I'm accusing you of doing that, clearly). Regards, Paddy -- Perl 6 will give you the big knob. -- Larry Wall
Re: RFD: Draft for a volatile.d.o policy
Sven Mueller writes: > Say a new open source network security scanner enters the world... ^^^ I wrote: > Those things belong in the non-existent backports.debian.org, not in > volatile.debian.org. paddy writes: > define 'breaks compatibilty'. > As long as it _is_ still the same package... If a package changes enough to require a new name it is a new package. > Basing policy on an implementation detail that should be used for > technical reasons, simply for lack of doing the work to arrive at a > proper description, would be a mistake. I don't understand what you mean by this. Descriptions have nothing to do with it. -- John Hasler
Re: RFD: Draft for a volatile.d.o policy
On Tue, Oct 12, 2004 at 07:57:06AM -0500, John Hasler wrote: > Sven Mueller writes: > > Say a new open source network security scanner enters the world... > ^^^ Yes, I neglected this half of the scenario, but see below. > I wrote: > > Those things belong in the non-existent backports.debian.org, not in > > volatile.debian.org. > > paddy writes: > > define 'breaks compatibilty'. > > > As long as it _is_ still the same package... > > If a package changes enough to require a new name it is a new package. Does the converse apply? If not then you have a problem. > > Basing policy on an implementation detail that should be used for > > technical reasons, simply for lack of doing the work to arrive at a > > proper description, would be a mistake. > > I don't understand what you mean by this. Descriptions have nothing to do > with it. Yes I wasn't happy with the word decription either but I had hoped it would suffice. My point is this: I would oppose a policy that said 'packages under new names must not enter volatile' because I strongly suspect that 'packages under new names' is a poor proxy for whatever it is you want. In particular it might create a pressure in a marginal situation on the otherwise technical decision of naming a package. I hope you will agree that this would be undesirable, even if you contend that it does not invalidate the use of 'packages under new names' in this way. I've suffered the breakage that comes with such naming, and I gave you a good example. I wouldn't wish to see more pressure on this device. I would like to know what you want. Because we appear to disagree on the more fundamental issue of whether new packages *should* ever enter volatile. I'm hoping we can get to a 'proper description', at which point I would hope that the whole 'packages under new names' would fall by the wayside, although I hope I am open-minded enough to be persuaded otherwise. Let me articulate my opposition to closing down the possibility of new packages in volatile. We don't need just another backports. Nor do we need just another stable. Packages entering volatile should do so for a good reason. I would support your position modified to 'should not _automatically_ enter' for new major versions of packages already in volatile. There should be a good reason. Volatile must be free to package software that is not in stable, this is its reason to exist. Being too rigid about this could result in packages in stable have dependencies across stable, volatile and backports, or not being able to fulfill the purpose of being usefull. If you want a clone of stable, you might as well say 'nothing can enter after stable is released', which is mighty close to what you are saying, only noone is saying that because it _so_ obviously ridiculous. I hope that volatile will play very nicely with stable. For me that is the whole point. But I don't expect it to have a two to three year release cycle. That is also the point. But most of all it should exist for a purpose, and I would not see that purpose hobbled by knee-jerk reactions, although I _am_ keen to try to understand what your point is. Regards, Paddy -- Perl 6 will give you the big knob. -- Larry Wall
Re: RFD: Draft for a volatile.d.o policy
John Hasler mentions, > ... the non-existent backports.debian.org ... An existent backports.debian.org would seem a worthy aspiration. Were plans thereto afoot, I would encourage. (It has been surmised once or twice in this thread that few people here actually use stable. This may be so, but just to add my own datum, I would admit that I use stable for everything except Debian development. Signed by stable GnuPG, this very mail issues from stable Mutt. Even stable Mozilla still has a home on my PC.) -- Thaddeus H. Black 508 Nellie's Cave Road Blacksburg, Virginia 24060, USA +1 540 961 0920, [EMAIL PROTECTED] pgp5OYKYKZvuJ.pgp Description: PGP signature
Re: RFD: Draft for a volatile.d.o policy
Thaddeus H. Black writes: > An existent backports.debian.org would seem a worthy aspiration. Were > plans thereto afoot, I would encourage. I agree, but I try to avoid writing anything that could be construed as "somebody ought to do X" on debian lists. > It has been surmised once or twice in this thread that few people here > actually use stable. I run Stable on one machine and Unstable on the other. -- John Hasler
Re: RFD: Draft for a volatile.d.o policy
John Hasler wrote: > > This also might include working on a sort of security team for v.d.o (I > > think both jobs should actually be combined in v.d.o). > > v.d.o. should be supported by the Debian security team. I don't think it > is worth doing if it can't be. One way to help make sure Debian security > can support it is to keep it as small and simple as possible. Backports.org isn't supported by the security team either and it's doing a very good job at responding to security problems and providing timely updates. Regards, Joey -- Those who don't understand Unix are condemned to reinvent it, poorly. Please always Cc to me when replying to me on the lists.
Re: RFD: Draft for a volatile.d.o policy
I wrote: > v.d.o. should be supported by the Debian security team. I don't think it > is worth doing if it can't be. One way to help make sure Debian security > can support it is to keep it as small and simple as possible. Martin Schulze writes: > Backports.org isn't supported by the security team either and it's doing > a very good job at responding to security problems and providing timely > updates. But it isn't backports.debian.org and many people won't use it for that reason. -- John Hasler
Re: RFD: Draft for a volatile.d.o policy
On Mon, Oct 11, 2004 at 06:48:00PM -0500, John Hasler wrote: > Sven Mueller writes: > > Say a new open source network security scanner enters the world, and it > > works well when compiled against Debian stable, we might want to add it > > to v.d.o even though it wasn't available when the last stable > > distribution was released. Or a new version of clamav is released, which > > sadly breaks compatibility, so we rename it to clamav2 and it can still > > be released through v.d.o, similarly to exim4 entering debian alongside > > exim a while ago. > > Those things belong in the non-existent backports.debian.org, not in > volatile.debian.org. The former yes, the later might go to v.d.o. -- Jesus Climent info:www.pumuki.org Unix SysAdm|Linux User #66350|Debian Developer|2.4.27|Helsinki Finland GPG: 1024D/86946D69 BB64 2339 1CAA 7064 E429 7E18 66FC 1D7F 8694 6D69 If a man cannot choose, he ceases to be a man. --Minister (A clockwork orange)
Re: RFD: Draft for a volatile.d.o policy (was: Re: Updating scanners and filters in Debian stable (3.1) )
The draft looks good, Sven. Please also include target # 5 as follows. > Draft for a volatile.debian.org packaging and update policy. > > Target: > > volatile.debian.org (or short: v.d.o) is intended to be a repository for > packages which degrade over time with respect to their usefulness. These > include, but might not be limited to: > 1) Virus scanners (clamav etc.) > 2) Intrusion detection systems and security scanners (snort, nessus, >etc.) > 3) Anti-Spam software (spamassassin etc.) > 4) Tools which are so closely related to a software in 1-3 that they >might need to be updated when a new version of the related software >is introduced to v.d.o 5) Architecture-independent data which depend on the contents of the stable release itself. Refer to [http://lists.debian.org/debian-devel/2004/09/msg00951.html] for rationale. -- Thaddeus H. Black 508 Nellie's Cave Road Blacksburg, Virginia 24060, USA +1 540 961 0920, [EMAIL PROTECTED] pgpHsRKnXwblJ.pgp Description: PGP signature
Re: RFD: Draft for a volatile.d.o policy (was: Re: Updating scanners and filters in Debian stable (3.1) )
Sven Mueller <[EMAIL PROTECTED]> 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. 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. Saying "it's really hard" is not a good excuse! People are doing it for those other packages all the time. > 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 place. > 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.
