Re: Suggested additions
On Sat, Jun 11, 2005 at 02:18:02PM +0200, Andreas Barth wrote:
> Hallo,
>
> last week saw a bunch of proposals for packages to add to volatile. Let
> me just re-hash some generic facts, I'll also send answers to each
> proposal.
>
> Our stated policies include that:
> - volatile is not just another place for backports; instead, we want to
> allow administrators to use volatile just the same way as
> security.d.o.
> - any package can _only_ go in in cooperation with the maintainer
> - and above all, the update needs to (primarily) fix important and above
> bugs.
Andreas,
It strikes me that being a superset of security.d.o - in the sense that
any patch that makes it into the security.d.o line, one would hope to
find also covered in the volatile line - for the packages that
volatile carries, while seemingly rather obvious, is an perhaps an
unspoken assumption here.
The main use case would seem to be for a user switching from stable to
volatile for some package.
I started to think about this in the context of the recent DSA-736 for
spamassassin, which IIRC was for a bug tagged important, security.
(I realise that AFAIK spamassassin is not in volatile, but sometimes
it helps to have a concrete example)
At the time, I recalled _incorrectly_, the above passage as saying
"serious and above", which bought the whole, admittedly hypothetical,
question to mind. I don't know if there is such a thing as a security
bug below 'important' and whether such would make it to a DSA.
Given that "if it's good enough for security, it's good enough for
volatile", some questions seem to arise:
Should a volatile release wait when there is a pending security release?
Despite wishing to say: "no, let things be on their merits", I can
see possible reasons for answering 'yes' to this:
releasing before security might create some gratuitous incompatibility
(although this could be judged on a case by case basis, and could
perhaps be remedied by a subsequent release)
releasing before security might lead to a perhaps undesirable impression
with some that volatile would then be a better way to get security fixes.
But maybe this is not a good enough reason to artificially delay a release.
on the flip side:
releasing when the code is ready seems to be consistent with "There will
be no support by the official security-team, but the volatile team will
do support for volatile."
In practice it may be that this question will never arise: that volatile
will always lag behind security, for good reasons. The only (again
hypothetical, sorry!) example that comes to mind is the following:
Suppose that and upstream release is only a security fix (as clamav-0.86.1
very nearly is) and that the package in question has no versions in
security or volatile yet, ie: just after a new stable (a difference to
the clamav situation). The maintainer might well choose to ship
the same source to security and volatile. Being the same source it
would probably go out the door at much the same time.
On a not-entirely-unrelated note, I'm a bit fuzzy about the policy on
version numbers, and a bit ignorant on how exactly it works, sorry!
Would it be a good idea to version number so that switching a package
across from security to volatile doesn't accidentally revert a security
fix? or does this just work already (because you really have to choose
to have a given package, and version numbers can't save you then) ?
Is there a way to tell from the version number what the corresponding
DSA it's patched up to, or is that not a good idea ?
I hope you can forgive me for this rambling hypothetical email!
Regards,
Paddy
--
Perl 6 will give you the big knob. -- Larry Wall
Reply to: