This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC 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: What is wrong with Bugzilla?


As an occasional user of the Bugzilla database, I don't find it terrible to use, though
it would be nice if there were an abbreviated interface that looked for the sorts of
queries that users issue the most.  These often-occurring queries might be best determined
by saving a month's worth of queries and ferreting out the types of queries that occur
most often.  I also didn't find the requirement that I register my e-mail address to
be particular surprising or burdomesome.

As an aside, I often stumble into the middle of a Redhat discussion list thread via
Google that seems to relate to a problem that I've encountered.  Redhat for some reason
requires https access, and in IE6, my browser of non-choice, I have to click OK to view
the page.  Now, _that_ is annoying.

What may be confusing to users: where do I report my problem? If I'm a Redhat user,
do I log my potential GCC problem to their support site, or to the GCC site?  To further
confuse matters, for most users, the vendors often modify a given version of GCC to
include specific patches and build options of their choice.  This of course argues
for logging bugs with the vendor.  One wonders whether the vendors are timely in reporting
legit bugs back to the GCC Bugzilla database, but one hopes so.

If we for the moment assume that users of pre-packaged distributions report their bugs
back to the vendor, then the GCC mailing lists and bug lists are left for those brave
souls who are using GCC source code distributions directly.  (perhaps the GCC maintainers
can comment on whether this theory in fact holds).  Matters are further complicated by
the fact that there are now several viable GCC releases to choose from: 3.3.x, 3.4.x,
4.0.x, CVS head, and so on.  There's even the occasional bug filed against one of the
many branches.  When we consider the multitude of choices, it is amazing that there
is any forward progress. <g>

As a casual reader of the GCC lists, I do have one observation: the volume on the
GCC bug list is very, very high.  Often the bug traffic there relates to regressions
and bugs that are found on the CVS head or recent development releases.  As a user
of the older releases (3.3, 3.4), I'd much prefer it if there were too separate bug
reporting lists: one for the more stable released versions, and a separate list for
the "latest".  I'd also like it if there was a web page for each stable release that
showed the results of a canned Bugzilla query which lists open bugs and/or recently
closed bugs agaisnt the stable releases (not sure how this would be organized).

As far as the tenor of the GCC mailing list goes, it is true that responses to "dumb
questions" are often terse, but they're generally helpful.  I think this is to be
expected, when interacting with busy developers who have to balance many priorities
and pressing deadlines.  I've been particularly disappointed by queries to related
lists like the glibc list, which of course is an equally important component of a
useful C compilation system.  I would vote affirmatively to somehow more closely
linking GCC releases with specific GLIBC distributions, and have some sort of tighter
coordination between the two.  However, after delving into GLIBC on a particular
platform, I can see where handling the many varieties of GLIBC builds is a big
problem, and appears to be one that presently the vendors mainly deal with.



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