This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: glibc Bugzilla and open-ended issues


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]