Martin Zobel-Helas <[EMAIL PROTECTED]> wrote: > i would like to see some "policy", what, when and under which > circumstances gets included to volatile.d.n.
The most sensible policy would be a case by case consideration. Some packages can sanely have the desired features backported [1], and some can't [2]. It's possible that we /could/ write policy that would actually be able to differentiate between the two cases, but it's fairly likely that it would just end up devolving into flamewars about corner cases or misclassification. I'd suggest a team of reasonable people who we trust to make the decisions and liase with package maintainers as appropriate. It's much less effort and it involves much less unhappiness. [1] whois would probably be a good example - if the set of whois servers is suddenly altered, the right thing to do is to change the list rather than update to the latest version [2] If sensible spamassassin functionality is based on a new parsing engine, then backporting that functionality to the old parsing engine may be impossible and is certainly going to involve a sufficiently large amount of new and untested code that any claims about enhanced stability aren't going to be massively convincing -- Matthew Garrett | [EMAIL PROTECTED]