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: 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


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