* Anthony Towns <aj@azure.humbug.org.au> [010325 02:30]: > If you're not going to bother filing the RC bugs, there's no reason > not to leave it as a "should". If you are going to file the RC bugs, > then someone's got to figure out which packages it applies to at some > point anyway.
This makes sense if one assumes that the only way packages will be brought into alignment with policy is by filing bugs; it ignores debian maintainers who read the changes to policy and change their packages without having bugs filed against their packages. (If no one does this, let me know, and I'll shutup. :) It also assumes that the only person to bother filing bugs is the proposer. Don't forget that Joe Standard User gets involved in the process too (once a proposed change has been accepted). More eyes etc. > There's 6720 packages in sid/i386 at the moment, btw, not 8458. Thanks for the correction. At ten seconds per package, this is still nearly nineteen hours though. > > Why don't you like the current system? > Because people don't seem to understand the point of the must/should > dichotomy. Fair enough. However, what is the purpose of 'must' if the amount of work required to put one in place is probably beyond anyone's available time? > Encouraging people to list the packages which'll have RC bugs filed > against them due to a proposal they're making doesn't seem particularly > drastic. If the proposal is being made in response to the behavior of several packages that have irked the proposer, I think I would have to agree that those packages should be listed -- perhaps as support for the proposed policy change. :) I agree with the idea that an example list of packages affected is a Good Thing; but I am still unconvinced that every policy change involing a 'must' must involve a possibly lengthy exhaustive search through all available packages. Cheers :) -- Earthlink: The #1 provider of unsolicited bulk email to the Internet.
