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

Re: about volatile.d.o/n



Scripsit paddy <paddy@panici.net>
> On Mon, Oct 11, 2004 at 07:22:15PM +0100, Henning Makholm wrote:
> > Scripsit paddy <paddy@panici.net>

> > > To be fair, the issue is that if were just rules, there wouldn't
> > > be a need.

> > Why not? 

> Well, the argument goes:

> 	that can be done out-of-band,

But isn't volatile.d.o supposed to *be* the out-of-band mechanism
(whatever out-of-band means here)?

>       but some updates involve changes
> 	or additions to the engine.  There is a class of such software.

I don't see how that means that there "wouldn't be a need" for rule
updates.

> SA3 has been on the cards for some time now.  Is there a policy around 
> name changes at these times?  could you have pinned (<<3.0) ?

Not according to my understanding of apt pinning. 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. That's what "stable" means.

> At the end of the day, I'm not certain exactly what you wanted protecting
> from,

See the long thread about spamassassin3. The highlight is that the new
version has a non-backwards-compatible API which makes certain other
software stop working.

I did not personally have any local scripts that depended on the old
API, but I might have had.

> but it's hard to be certain that volatile would give it to you.
> After all the point is to get (at least some) changes.

The point is to get improved *classification* without changing the
*interfaces*.

> > Clearly, but the *format* in which the virus scanner reports its
> > findings should stay stable.

> You'll get no argument from me on the priciple of that.
> But what is stable?  What if a format needs extending to take account
> of some new circumstance?

Then a decision has to be made respecting the users' interest in
having whatever local scripts they are using keep working.

> For instance, suppose there are Packages A and B in volatile.
> (A) has an interface (1) that is only used by (B) in the whole of debian.

"In the whole of Debian" is not the only concern here; I would say it
is not even relevant. Admins of un*x systems are *supposed* to write
a truckload of local scripts to adapt their system to their wishes.
That's the way it works. And our commitment in calling stable "stable"
is that those local scripts will keep working across security updates,
unless breaking them is necessary to close a hole. Similarly, if
volatile is to be any value added over pinning unstable or testing,
it must respect the same commitment.

> but the case for eventually upgrading to (1+) is
> compelling: it is only a question of when and how.

If upgrading will break existing interfaces, then "when" means "after
the current testing freezes and is released as stable".

> You've said mozilla belongs in backports, which I'll take to mean:
> mozilla does not belong in volatile.

I'm saying that *new upstream versions* of mozilla with hundreds of
little interface changes, new preferences file formats, et cetera,
does not belong in volatile.

> So you're not advocating mozilla in volatile. It may be that someone
> will come along that will advocate it in a compelling fashion, but
> I'm not holding my breath.  Until then, if no one is building it,
> then what is there to knock down ?

I do not understand that question either.

> Concrete example: I care about virus detection in the first two weeks, 
> and even more so in the first few hours.  To me not detecting a virus,
> purely because someone is correcting spellings would be downtime.
> (of course, if it's because _I'm_ too busy or too lazy, that's a
> different matter ! ;)

I'm not sure what consequences this example has for what should and
what should not be accepted in volatile. If the volunteer who would be
preparing a rule update would rather use his time correcting
spellings, we cannot force him. But that is probably not what you're
getting at?

-- 
Henning Makholm                          "I tried whacking myself repeatedly
                                     with the cluebat. Unfortunately, it was
                                 not as effective as whacking someone else."



Reply to: