Hi,
I admin a small system with mailscanner, spamassassin, clamav, etc.
I would dearly like to move the system as a whole to a debian sarge base,
and will likely do so, regardless of the outcome of this debate/process.
The outcome _will_ impact how I admin it in future.
On Thu, Oct 07, 2004 at 02:07:18AM -0400, Stephen Gran wrote:
> This one time, at band camp, Thomas Bushnell BSG said:
> > Can you write a policy which says that the only changes which will be
> > made are specific changes known to catch viruses, but *not* the
> > addition of new features, new interfaces to other parts of the system,
> > and the like?
<snip>
> I am terrible at doing things like drafting policy statements, but I
> will take a stab at it.
I've never drafted a policy statement, but hey ...
Here is my counter proposal:
PREAMBLE
========
Software is best when it is:
Free
Just works
stable
supported
secure
up-to-date
etc.
For different software, different people, different uses, etc.
some values may be more important than others.
And, sometimes you have to choose.
There is a category of software whose utility is very sensisitive to
and derives from, in a very great part from it's timeliness, how up-to-date.
People have variously called this software ephemeral, volatile, perishable
to denote this quality. mailscanner, spamassassin, clamav, etc. are in this
category.
We consider here the 'volatile' software that is security software.
PURPOSE
=======
To support this category of software on stable. (on, not in).
WHAT IS WRONG WITH WAY THINGS ARE
=================================
When I _need_ (not want, _need_) the latest upgrade, I need it now! Not in
two days time when someones futzed about with it (and like as not broken it).
Otherwise I can just build it myself - I do now anyway!
I'd rather not pin up to sid. Packages in sid seem to be built against sid.
I'd end up with unstable libc upgrades and all sorts (not that I've ever had
a problem with a libc upgrade from sid). Testing is just too late.
[please correct me if I'm wrong about this, and I'll just go away and die
quietly of embarassment somewhere]
The main distribution should be more than just 'stable' it should be 'best'.
Debian can do better. Here's how.
PLAN FOR MAINTENANCE OF A VOLATILE ARCHIVE
==========================================
There is a 'list of packages' for the archive. Packages going onto the list
must satisfy the criteria:
utility is very sensisitive to and derives from,
in a very great part, it's timeliness - how up-to-date it is.
AND
is security software
packages should be 'built as backports' in the sense:
built with and against stable, as far as possible.
ideally, built from the same source as experimental/sid/etc.
with the minimum of fuss, and quickly.
dragging whatever dependencies they require/prefer
into the volatile archive with them.
Clearly for packages with their roots in unstable there need to be ways
for admins and maintainers to exchange and track information
to indicate clearly to the less experienced the status
and potential risks associated with available options.
The Debian Project has a full array of systems to do this.
But I shall offer two suggestions:
Perhaps volatile should have its own parallel stable/testing/unstable?
Might I propose that an unstable section be named after sid's sister,
'Hannah'?
Bug reports are useful. On short timescales positive reports, in a
machine readable format (think apt-list-bugs, etc), could be just
as much so or more so.
Could the BTS handle somehting like this ?
I haven't covered the issue of API/ABI changes. I'm kinda hoping that proper
dependency tracking can handle this.
Similarly I realise that there is a hazard to the purpose of running on
stable attached to dragging arbitrary dependencies into the archive,
But this seems like the best limitation strategy to me. Perhaps there
will need to be more flexiblity around this (trading off more time spent
packaging to get less drag-in effect).
HOW IS THIS BETTER ?
====================
* its fast
thats the point. fast. fast makes timely.
* better throughput
otherwise there _will_ be multiple admins doing this themselves
around the world.
* better distribution of labour
With the best will in the world, the best man for the job cannot
always be available. If the primary admin is not available to
make deployment decisions, and deal with builds, the next in line
cannot be expected to always achieve the same level of performance.
With an internet wide team of experts, we can do better than that,
even the primary admin can perform better.
* proper support
IMHO, if mailscanner, spamassassin, clamav, etc. cannot be supported in
something like this way, and the status quo continues, where programs in
'stable' languish in a woefully unsupported state, then I fail to see
the value in shipping them in sarge.
For this category of software, QA needs to happen more in the loop
after the package is built, and less so before.
* superior firepower
For so many things, Debian is the best.
This is a significant niche.
Debian can be the best at this.
For me, this is a important issue for debian.
In the words of Jack Nicholson (in "Mars Attacks", I think):
"Together we are stronger"
---- END PROPOSAL ---
I can't do s/volatile/as-yet-to-be-named/g,but please read it that way if
you wish.
I've put in "have a security application", because
This is what I care about.
This is what we are talking about.
I believe a narrow focus could be good for getting such an effort
off the ground. Otherwise this is just (approximately) a charter
for bringing backports.d.o into debian proper.
I hope my proposal is clear. I believe this proposal is very much at odds
with the model based on security.d.o that is being advanced, and I hope
the reason is clear: timeliness, its the whole point. As always, if you
have questions, corrections, see dificulties, have a better idea, just
plain disagree, or whatever, I'd like to know.
Incidentally, I can't help feeling a little dragged down by the tone
of some of the words we're using. 'Fresh', 'timely', 'up-to-date' as
well as a host of more abstract words like 'useful' and 'appropriate',
describe the kind of software we're talking about. I realise that
'destabilise' is the term that is use to describe a very legitimate
concern, but I wish to point out that
The quality of upstream support for software in this
category is often _exceedingly_ high.
So much so, that I feel there must be a corresponding legitimate concern
that any backporting-of-the-security.d.o-type not only risks unnecessary
delays, but risks the quality of the outcome.
And, yes, I'll still be here mucking in with the day to day when it gets
going, whatever the outcome. If we have a system I can use, I can do more
that is (I hope) of use to others.
Regards,
Paddy
