Scripsit paddy <[EMAIL PROTECTED]>
> On Tue, Oct 12, 2004 at 03:05:05PM +0100, Henning Makholm wrote:
> > But isn't volatile.d.o supposed to *be* the out-of-band mechanism
> > (whatever out-of-band means here)?
> No. clamav virus signatures, for example, can be maintained by a program,
> freshclam, that downloads database updates from upstream.
I know that, but as far as I under stande, the whole point of volatile
is to replace exactly that with a situation where each maintainer does
not have do program his own freshfoo system (and worry about finding a
location to download from that is known in advance to stay availbale
throughout the entire lifetime of the next stable release).
> > I don't see how that means that there "wouldn't be a need" for rule
> > updates.
> See above. The consensus seems to be that it would be undesirable to
> even try to push this data through the regular package-management channel.
Whose consensus is this? The debian-devel feed that reaches me shows
quite enthusiastic support for pushing rule updates through an aptable
repository.
> > And in any case the point is that I want to run a *stable* box. I
> > am not keeping consciously track with upstream changes to
> > "background" software like spam filters, so I didn't *know* that a
> > 3.0 version was about to happen. A user of stable should be *able*
> > to remain ignorant about such chages.
> Ah, but you weren't just a user of stable were you?
> You'd drunk from the forbidden waters of unstable! :)
Because volatile does not currently exist.
> > The point is to get improved *classification* without changing the
> > *interfaces*.
> For me the point is to achieve function.
Function may disappear totally if the update makes things break.
> > If upgrading will break existing interfaces, then "when" means "after
> > the current testing freezes and is released as stable".
> Yes, for stable. Do we want 'just another stable' ?
No, we want a way to push non-breaking data updates to stable users in
a controlled way. They'll still be stable users, so they still want
freedom from gratuitous breaking.
> If you s/mozilla/spamassassin/ I might want to argue the point.
Well, I don't want to se an update to spamassassin in volatile if it
breaks APIs that my scripts use. Raising spam detection rates from 97%
to 98% is useless if the update makes my mail system go catatonic and
deliver all incoming mail, spam or not, to /dev/null. I run stable on
my mail server because I *don't* want random breakage, and if not
having any random breakage means that I'll have do delete a bit more
of my spam by hand, then so be it.
If I wanted random breakage, I'd run testing on the server. But I don't.
> Why are we talking about mozilla?
I don't know. You seem to have some kind of point about it, but I
still cannot fathom what it is.
--
Henning Makholm "Occam was a medieval old fart. The simplest
explanation that fits the facts is always, God did it."
