Hi,
* paddy ([EMAIL PROTECTED]) [041008 16:05]:
> On Fri, Oct 08, 2004 at 03:15:29PM +0200, Andreas Barth wrote:
> > * paddy ([EMAIL PROTECTED]) [041008 15:10]:
> > > What are the pros and cons for
> > > volatile-{stable,release,or-whatever-you-call-it}
> > > as an all-at-once release model, rather than a rolling-when-its-ready
> > > model more like security.d.o ?
> >
> > well, not exactly an "all at once", but having not just a random minor
> > update to pop up every day is IMHO a great feature for system
> > administrators - they're not forced into additional update rounds.
>
> If volatile-stable included as a criterion time-served three months
> (pick a number, archive wide or perhaps per source package),
> I believe it could prove a wise choice of mechanism: familiar,
> cheap to implement, and a good proxy for some desirable qualities.
Yes, that is exactly what I mean. Not too many updates to mechanismns,
except if really required. And of course, the daily update of e.g.
clamavs files, should be done by a cronjob from clamavs site, and not by
installing a new deb every day.
> I don't understand 'forced into additional update rounds'.
A lot of admins (including me) use tools that tell them "Hey, you forgot
to update your packages" if they are not current. And, if the last
update fixed a security bug, this is actually needed.
> In what use-cases is a three-month clamav good, a two-year-old clamav
> not, and newer not interesting? What does it do?
Well, as I said above: If there is a good reason for an update, it
should be in. But - don't fix it if it is not broken, and who wants to
use the very newst development version could just use some backports,
e.g. from backports.org. volatile is IMHO more a "it is more current
than stable, but otherwise, we change as less as possible".
Cheers,
Andi
--
http://home.arcor.de/andreas-barth/
PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
