[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 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? I pretty much want to have the spamfilter rules on my mail
box updated from time to time. 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.

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

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.

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

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

> 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?

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

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

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

> Presumably, security fixes are more important.

Security fixes should be handled by security.d.o.

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. Introducing volatile just to make it a
competing security team would be silly.

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

Henning Makholm                                 "Slip den panserraket og læg
                                          dig på jorden med ansigtet nedad!"

Reply to: