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.
Regards,
Paddy
--
Perl 6 will give you the big knob. -- Larry Wall
Reply to: