[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: about volatile.d.o/n

Scripsit paddy <paddy@panici.net>
> 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

> > 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."

Reply to: