Re: about volatile.d.o/n
On Mon, Oct 11, 2004 at 07:22:15PM +0100, Henning Makholm wrote:
> Scripsit paddy <firstname.lastname@example.org>
> > On Mon, Oct 11, 2004 at 05:06:21PM +0100, Henning Makholm wrote:
> > > A backport of a new Mozilla release is something vastly
> > > different from new rules for a spam filter,
> > 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 some updates involve changes
or additions to the engine. There is a class of such software.
> I pretty much want to have the spamfilter rules on my mail
> box updated from time to time.
I understand that. Each of us has differing needs.
> Currently that has lead me to put
> a low-pinned unstable in sources.list and get spamassassin from there.
> But it was not meant to suddenly pull in spamassassin3. If volatile
> had existed, I could have avoided that.
Ouch. I agree that there are dificulties with pinning up to unstable.
Did spamassassin3 go into unstable as 'spamassasin'? (I've not been
paying attention) I bet a few people were caught out by this!
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) ?
At the end of the day, I'm not certain exactly what you wanted protecting
from, 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.
> > MailScanner can be configured to send mail to an admin account warning
> > of various events. I filter these with procmail. Recently these
> > warnings changed. I would not want a volatile maintainer to be
> > hamstrung in such a case if no package in debian uses the interface:
> I disagree here. One of the main reasons to run stable (apart from
> getting security updates) is that one can be sure that one's homegrown
> scripts will not suddenly stop working because some of the
> Debian-provided software changes the behavior. That means that updates
> should avoid *any* unnecessary interface changes, right down to
> preserving spelling errors in the messages used by the intially
> released version.
Yes. I can certainly see your point here, and would be more than happy
with a volatile where this was the case. I simply see both sides of
the coin. Even when the edges get very blurred. And I think they can.
> Volatile should preserve that stability guarantee and stick to
> changing the internal processing to be up-to-date with the changed
> > Clearly the names of virus identifications sometimes change.
> > This is expected. I would say that the interface is _defined_ as volatile.
> 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? I can go on in this vein...
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.
Vital new functionality is added to (A) impacting only (1).
Upstream (B) is updated to use the new (1).
Functionality will suffer seriously if the new (1) is not implemented.
The maintainer(s) may want to take steps to zero the impact on
existing users, but the case for eventually upgrading to (1+) is
compelling: it is only a question of when and how.
In extremis, backporting can become a destabilising activity.
> > Playing the devil's advocate:
> > Someone's going to say "so don't do that then" aren't they.
> They probably are, at least until we can agree what is and what is not
> the purpose of the facility. I'm arguing what *should* be the purpose.
fair enough, I couldn't resist :)
> > Are you saying you have a use for a volatile mozilla, or simply
> > that you see potential problems? If it's the latter, then I
> > agree, you have identified a potential problem area.
> I'm not sure that I understand that question.
Yeah, sorry, looking back it wasn't terribly polite.
<sigh> I must learn some manners.
You've said mozilla belongs in backports, which I'll take to mean:
mozilla 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 ?
Should anyone do so you've pointed out a potential problem area.
I'd like to think that the potential problem for users of mozilla is
not the same for users of clamav because the users are different.
But it may be that you mean this example with wider application,
hence the inquiry and my interest.
> > Also: for a web-browser, yes. For applications in more voltile domains I'm
> > willing to be a little more flexible. But that's just me.
> Do you have an concrete example we can use to discuss where the line
> should be drawn?
If we are to succeed in drawing lines, then I believe it will be through
concrete examples. But I imagine the bottom line will be drawn by Debian,
the volatile team, and the maintainers, rather than me, a humble user.
I am willing to be far more flexible than I suspect that bottom-line will
come out at, so the exercise may be a little academic.
Put simply: I'm willing to trade breakage for uptime, to some degree.
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 ! ;)
But I grant you it's a very fuzzy area.
Where *should* the line be drawn?
I have every confidence in Andi and the maintainers, and renewed
belief in debian.
If you have my confidence, you won't worry about my wild suggestions!
> > > An update of mozilla-browser would be appropriate for volatile if it
> > > did not change the upstream codebase, but, say, updated the default
> > > SSL root certificate set in response to announcements from a
> > > well-known CA.
> > It would seem a shame to have to do a whole mozilla-browser package
> > just for that.
> First example that came to mind. A smart maintainer who anticipates
> doing such an update would probably separate out the root certificates
> in a small package that could be shared with other PKI-using packages.
> For all I know, this may already be how it works currently; I did not
> spend much time tracing the dependencies of the various mozilla
Sounds like a candidate for ...
> > I think what you're saying is you don't want the browser to change
> > very much.
> Yes. If it makes the keyboard shortcuts I'm used to work differently,
> then it's too much.
Yes, that would certainly annoy the hell out of me ! :)
> > I don't know how important fixing 'the default style sheet to
> > include new tags from XHTML 2.1' is, but it sounds pretty
> > unimportant to me.
> Yes. The point was that if somebody cared enough to do a volatile
> update for it I wouldn't find it totally out of line. But I would not
> expect anybody to care that much.
I missed that. I'm not sure that a facility for important uses
should be used for trivial ones, for fear of pollluting the S/N ratio,
but I suppose that depends on the values of $important and $trivial.
> > Presumably, security fixes are more important.
> Security fixes should be handled by security.d.o.
wrt stable I certainly agree. I rather like what Andi was saying about
volatile taking some repsonsibility for security (or was that just
orphans), for the reason that candidate packages will be looked at more
carefully if there are responsibilities attached, but I can that
it leads to a potential moral hazard (the end-run round security).
Its something I know too little about, but again I'm happy in the
belief that the right solution will be arrived at.
> There may or may not be somebody who claims that they *are* not
> handled by s.d.o (I haven't seen that, but I haven't looked for it
> either). Even if true, that does not change the fact that s.d.o is
> where it *should* be handled.
I recall someone advancing the argument that making an end-run using
volatile might viable. There was plenty of oposition then, and this
seems like much the same thing rattling on. But we're doing some
good stuff too ...
> Introducing volatile just to make it a
> competing security team would be silly.
We're singing from the same hymnsheet.
> > I don't see any need to place obstacles in the way just in case.
> > And I'm concerned that those obstacles might ultimately get in the way
> > of packages _in_ volatile (when we have some).
> I'm not proposing any mozilla-specific obstacles, at least as not as
> far as I'm aware.
That's okay, it's just me then. You know how it is. You never know when
_they_ might be listening ;)
Perl 6 will give you the big knob. -- Larry Wall