glibc Bugzilla and open-ended issues

["Joseph S. Myers" <joseph at codesourcery dot com>]

We have a couple of bugs (bug 13959 "Request to deprecate 
namespace-polluting cruft in headers with _GNU_SOURCE" and bug 14233 "Many 
of tst-*.c lack any description of the assertions they test") that are 
about open-ended projects or policy questions and don't have any clear way 
a future glibc source tree could be checked to see if the issue is still 
present.

I'd like to propose that glibc Bugzilla is only for concrete issues with a 
substantially objective way of assessing whether the issue is still 
present - issues with the glibc sources, or in the case of the "admin" 
component with associated infrastructure.  Thus, I think open-ended and 
policy issues should be closed as INVALID with submitters advised to start 
a discussion on libc-alpha seeking consensus in a particular area (with a 
view to documenting that consensus on the wiki) if they have a policy 
concern, or to start and maintain a wiki page if they wish to propose an 
open-ended project without clear objective completion criteria (such as a 
project to clean up all cases of some particular issue, where it is 
subjective whether something is actually a case of that issue or not - as 
opposed to a project to remove all uses of a particular symbol, which can 
be checked for with grep and where Bugzilla is a suitable way to track the 
project).

(On a related note, bugs in Bugzilla should generally be minimal - if in 
doubt about whether similar issues in two separate functions, or two 
issues in one function, could only reasonably be fixed together, file them 
as separate bugs so the status of each bug can be tracked separately if it 
turns out to make sense to fix the issues in separate patches; figuring 
out the state of a "partly fixed" bug is a pain.)

-- 
Joseph S. Myers
joseph@codesourcery.com