On Fri, Oct 08, 2004 at 09:25:33AM -0700, Thomas Bushnell BSG wrote: > Loïc Minier <[EMAIL PROTECTED]> writes: > > > Thomas Bushnell BSG <[EMAIL PROTECTED]> - 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
