Re: about volatile.d.o/n
* Thomas Bushnell BSG (tb@becket.net) [041008 18:25]:
> Andreas Barth <aba@not.so.argh.org> writes:
> > - volatile is not "just another place" for backports, but should only
> > contain changes to stable programs that are necessary to keep them
> > functional;
> I think your proposal looks good, but I would like to see this
> particular item fleshed out more fully. In particular, what kinds of
> changes are being considered here?
>
> In other words, would it count as "necessary" to say "new upstream
> major release provides a new feature which keeps the virus scanner
> useful, and also changes a bajillion unrelated things"?
>
> In my book, the new virus definitions would be necessary, but not the
> bajillion unrelated things, and I would like to see a rule that you
> could not just put in the new upstream major release merely to get the
> new virus definitions.
Agreed. So, this means: Backport the necessary changes. Sometimes, it's
just not enough to only update the virus scanner definitions, because
new functionality is needed to scan the files (just consider that a very
new archive format gets so popular that it needs to be supported, just
like zip now).
And, if there are changes that should be available on stable, but not be
the default (like e.g. the current spamassassin3), than they might get
in as new package, not disturbing the users of the old one, but giving
more choices. (Of course, even then, the package needs to be a bit more
mature than the curent spamassassin3, but that's a different thing. ;)
> That is, some kind of "minimal change to
> preserve utility" rule, which might require the volatile-managers or
> whoever to be Real Programmers and not just compilers.
Of course it requires them to be Real Programmers. The job is _not_
mechanically compiling something on stable.
Cheers,
Andi
--
http://home.arcor.de/andreas-barth/
PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Reply to: