packages affected list for must changes to policy (was: Re: Bug#91257: [PROPOSED] changes to X font policy)
* Anthony Towns <aj@azure.humbug.org.au> [010325 01:11]:
> BTW, I'm inclined to think it'd be a good idea for people who want to add
> a "must" requirement (or to change a should to a must) to include a list of
> packages that would need to be removed from the distribution due to the
> change. Anyone agree/disagree?
While I appreciate your desire to increase understanding of consequences
of policy changes, asking every policy change author to examine the
details of `apt-cache pkgnames | wc -l` packages (on my machine, 8458
packages!) is .. well, assume someone can check each package in an
average of one second, that would still take nearly two and a half hours
of otherwise productive time. If examining each package took a more
reasonable ten seconds, that is a whole day's work spent to find which
packages will need to change to stay in the distribution.
Why don't you like the current system? I have thought the proposal /
vote process will keep arbitrary changes out of policy, and a package
maintainer is free to change bugs against his or her package to be
against policy with a note stating why compliance is difficult for his
or her package. If it turns out to be too difficult for a package to
comply with policy, fine, re-amend policy if the package is important
enough to keep despite non-compliance.
Furthermore, with releases as far apart as they are, maintainers have an
average of six to eight months to fix problems with their packages.[1] I
would hope something could be worked out in that time frame.
I don't see anything drastically wrong with the current process. Why do
you disagree with it?
Cheers
[1]: Yes, statistically speaking, half the time between releases.
Individual cases, with individual changes, could range between 16 months
to less than a day, but I doubt many policy changes are going to be made
in the days before a release.
--
Earthlink: The #1 provider of unsolicited bulk email to the Internet.
Reply to: