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

Re: Updating scanners and filters in Debian stable (3.1)

On Fri, Oct 08, 2004 at 09:25:33AM -0700, Thomas Bushnell BSG wrote:
> Loïc Minier <lool+debian@via.ecp.fr> writes:
> > Thomas Bushnell BSG <tb@becket.net> - Fri, Oct 08, 2004:
> > 
> > > >                     My proposal is to create a policy for a
> > > > repository with maintenance, security updates which introduces new
> > > > packages and provides new functionality on outdated or useless
> > > > packages from stable, and is built against stable.
> > 
> > > Suppose a nifty new emacs feature is developed; why should that new
> > > functionality be excluded from this repository you are speaking of,
> > > merely because it isn't a security update?
> > 
> >  Because the nifty new emacs feature doesn't render the emacs from
> >  stable useless.  But I think your talking in loops.
> But the original text sounded like "if I call part of this a security
> update, then I can make arbitrary other changes."

Indeed, spamassassin is on the v.d.n. list, but is it a security 
program at all ?

(Funnily enough I overlooked that until now, intended it included in my
suggestion 'is security software', but I don't think it is.)

Whereas MailScanner would seem to me an obvious candidate.

> In other words, only the changes necessary to keep the program useful
> for its purpose should get in (whether security updates or not)--that
> I can agree with.  But doing other "new functionality", which is not
> actually necessary, this I cannot agree with.

We think I agree here, almost.  This seems the natural endpoint,
and starting the journey well without finishing well would be bad.

But, I can see the case, as I describe before, where achieving the function
of a package places great pressure on the time to package, so much so that
if an interim, first cut package can achieve this most effectively 
(ie: quickest) by shipping upstream 'important fixes/features' mixed with
'other "new functionality", which is not actually necessary' then that can
be a win too.  But I could agree: only with the proper follow-up.

> And this means that the maintainer/whoever must do the potentially
> hard work of backporting particular changes and not others from
> upstream releases; merely including a new upstream release is not good
> enough.

Getting results is more important than any dogma about how it should be
done, and I suspect that repeated warnings against overlooking the
importance of hard work are very good at getting results.



Perl 6 will give you the big knob. -- Larry Wall

Reply to: