This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: glibc Bugzilla and open-ended issues
- From: "Carlos O'Donell" <carlos at systemhalted dot org>
- To: "Joseph S. Myers" <joseph at codesourcery dot com>
- Cc: libc-alpha at sourceware dot org, bugdal at aerifal dot cx
- Date: Thu, 14 Jun 2012 20:28:32 -0400
- Subject: Re: glibc Bugzilla and open-ended issues
- References: <Pine.LNX.4.64.1206141845110.591@digraph.polyomino.org.uk>
On Thu, Jun 14, 2012 at 2:54 PM, Joseph S. Myers
<joseph@codesourcery.com> wrote:
> 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).
Agreed. Close them as INVALID and redirect to the mailing list.
> (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.)
Agreed.
Cheers,
Carlos.