This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Bugzilla and build bugs
On Tue, 21 Feb 2012, Roland McGrath wrote:
> A significant motivation for this policy was to avoid useless clutter in
> the bug database, adding to the load of anyone attempting to process real
> bug reports. As long as we still have no actual process for bugzilla
> triage and no team of volunteers performing it, this remains a concern.
We have:
* <http://sourceware.org/glibc/wiki/bugzilla/procedures>, describing
various things about use of Bugzilla, which has been updated based on the
issues I have found in the course of going through bugs, the ways I have
proposed to address them, and the comments people have had on the changes.
* <http://sourceware.org/glibc/wiki/Bug_Triage>, again updated based on my
experience and the discussion and proposals.
* Carlos added himself to the default CC for the build component, which I
take it as volunteering to ensure that new bugs in this component do have
sufficient information to reproduce them reliably or understand what the
actual issue is.
I do not claim these pages are perfect (the whole wiki has a disclaimer on
it about being unofficial); in particular, the first page still has some
bits about milestones and procedures in relation to releases that appear
to have been added in 2009 from something I proposed at that time, which
haven't really been tried in practice.
I do claim that it makes sense to update these pages quickly based on
rough consensus - with a strong bias to documenting things actually being
done by people actually going through bugs - and then if consensus changes
later in discussion, the pages can be revised or refined to reflect that.
A bit more care is merited for actual changes to Bugzilla configuration or
to lots of bugs - but even there I think it's desirable to act quickly as
long as it's with a willingness to fix things up afterwards if there is a
conclusion that some of one's actions were in an undesired direction.
(People on glibc-bugs or default-CCs for major components should expect
lots of Bugzilla mail in any case.)
This is not a matter of a public ABI or API that's hard to change, nor is
it a matter of a subtle area of the code where many eyes are critical. I
think post-commit review is generally appropriate for most things related
to these procedures at this point.
For each such procedural point, and each patch, I've judged individually
how obvious it is, and how much time seems appropriate to allow for
discussion before drawing a conclusion. (In the case of build bugs,
Carlos drew the conclusion by creating the new component. At that point
I'd read consensus and documented conclusions on handling assignments and
SUSPENDED; not on build bugs or on how to handle bugs about libm functions
having a few ulp error as those seemed more potentially controversial
issues. But we had three people supporting accepting build bugs in
Bugzilla and noone speaking out against, so it was hardly an unreasonable
conclusion for Carlos to draw a couple of days after the proposal.)
> Bugzilla is not really appropriate for any kind of bug that is introduced
> between releases and reported before the next release. The only people who
I disagree. It's a bug; we have a bug tracker to track bugs. Sometimes
it will be simple to fix, in which case indeed just fixing it and checking
in a fix as obvious where appropriate makes sense. Sometimes more
complicated, in which case tracking it makes sense. Hopefully we can work
out appropriate ways of identifying such unresolved bugs that should be
considered to block the next release.
> should be affected by those are the developers, and they should discuss on
We should want people routinely testing current development sources in a
range of environments (including integration testing with whole system
builds). Developers can't cover all environments or uses themselves;
wider testing helps detect problems sooner and make better releases.
You've just admitted not always being up to date on developer list email;
arguably developers should be able to check the bug tracker as a quick
indication of whether an issue with the current sources is known without
needing to read through the list email as well.
> The most common complaints about building are from clueless users. We
Just because the user is clueless (or in the case of one user with build
issues, abusive) doesn't mean they don't have a valid point.
> should do whatever we can to get anyone who is not well-versed in glibc
> issues to start out with posting to the libc-help mailing list for help.
If they don't know how to put all the required information in an issue,
sure. But plenty of build issues do have enough information; closing them
because they are build issues is just a fob-off. And we should not be
fobbing off users like that. And users should be able to expect that our
bug tracker is an appropriate place to report bugs.
We have the WAITING state for bugs that don't include enough information
to reproduce them.
> A build component does make sense for build bugs that survive into
> releases. Still, user error is more common than real bugs. Building
Bugs surviving into releases is pretty much all the build reports we get
in practice, I think.
It's been true for years that building with -march=i386 (or a compiler
defaulting to that) doesn't work, for example. I do intend to make
configure detect that issue (and so resolve two open build bugs).
> glibc is particularly fraught with peril, far more so than the average
> package that follows GNU configure conventions. So starting on
Yes. That general concept is something we should explain on the wiki.
But in plenty of cases the problems are unnecessary; glibc should detect
the most common bad configurations or build environments; glibc shouldn't
claim to support old versions of build tools that actually don't work; and
so on.
> libc-help is still right for anyone but seasoned veterans who can
> confidently identify a bug.
If you want then libc-help could be a default CC for build bugs (like
libc-locales is for localedata bugs)....
--
Joseph S. Myers
joseph@codesourcery.com