Re: Bugzilla and build bugs

[Roland McGrath <roland at hack dot frob dot com>]

I don't entirely agree, though I don't object to some change here.

But first, I must object to your summarily drawing conclusions and
implementing them, especially on subjects in which I was originally
involved, without waiting for feedback from me.  I was out sick the last
two days of last week, and then there was a long weekend for US workers,
but you'd chosen an outcome to this discussion and implemented it before
I even caught up on the email backlog--in fact, before there had even been
a single workday in the US.  That's not collaboration.  It renders raising
the subject for debate at all nothing more than tokenism.  I think you
already know better, so please act like it.

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.

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
should be affected by those are the developers, and they should discuss on
the development mailing lists (or just fix things themselves, when trivial).

The most common complaints about building are from clueless users.  We
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.
That's what it's there for.  People subscribed to that list have explicitly
volunteered to help educate neophyte users.  Even if we had a coherent team
of bugzilla triage volunteers, as I hope we will get, what those people
will have volunteered for is to help the developers by managing and
refining the bug queues, not necessarily to hold the hands of clueless
users.

A build component does make sense for build bugs that survive into
releases.  Still, user error is more common than real bugs.  Building
glibc is particularly fraught with peril, far more so than the average
package that follows GNU configure conventions.  So starting on
libc-help is still right for anyone but seasoned veterans who can
confidently identify a bug.

It is generally reasonable to make configure explicitly reject
unsupported configurations.  But there must be a balancing test.  Adding
checks for truly stupid things or things it's very unlikely anyone but
the thoroughly clueless would ever attempt is liable to do more harm, in
making the configure scripts even more byzantine and harder to maintain,
than good, in short-circuiting user confusion.

I think the issue of testsuite failures is a separate one worthy of its
own separate discussion.


Thanks,
Roland