11:41 a.m.
Hi
Save us a few hours of bugzilla grunt work by not filing two hundred and
seventeen duplicates for a trivial bug. Thanks.
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181064
If anyone has a list of good improvements that can be made to bugzilla
to help is triaging let me know.
--
Rahul
Fedora Bug Triaging - http://fedoraproject.org/wiki/BugZappers
11:56 a.m.
On Tuesday 14 February 2006 11:41, Rahul Sundaram wrote:
Save us a few hours of bugzilla grunt work by not filing two
hundred and seventeen duplicates for a trivial bug. Thanks.
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181064
If anyone has a list of good improvements that can be made to
bugzilla to help is triaging let me know.
Over the years the single biggest complaint voiced on these lists is
the poor search results bugzilla provides. If the searches
provided better results perhaps duplcatess wouldn't be so
prevalent.
Regards, Mike Klinke
12:08 p.m.
Mike Klinke wrote:
On Tuesday 14 February 2006 11:41, Rahul Sundaram wrote:
>Save us a few hours of bugzilla grunt work by not filing two
>hundred and seventeen duplicates for a trivial bug. Thanks.
>
>https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181064
>
>If anyone has a list of good improvements that can be made to
>bugzilla to help is triaging let me know.
>
>
Over the years the single biggest complaint voiced on these lists is
the poor search results bugzilla provides. If the searches
provided better results perhaps duplcatess wouldn't be so
prevalent.
That was not the case for this bug report. Give me specific instances
where bugzilla search didnt provide the results you wanted out of it
while it already had the content you were looking and copy the mails to
dkl AT redhat.com. I suspect a lot of these complaints are wrong user
queries.
--
Rahul
Fedora Bug Triaging - http://fedoraproject.org/wiki/BugZappers
12:13 p.m.
On Tue, 2006-02-14 at 23:38 +0530, Rahul Sundaram wrote:
Mike Klinke wrote:
That was not the case for this bug report. Give me specific instances
where bugzilla search didnt provide the results you wanted out of it
while it already had the content you were looking and copy the mails to
dkl AT redhat.com. I suspect a lot of these complaints are wrong user
queries.
When it is so easy to do a wrong query, there might be something wrong
with the software and not with the user ;-)
- Erwin
12:18 p.m.
Erwin Rol wrote:
On Tue, 2006-02-14 at 23:38 +0530, Rahul Sundaram wrote:
>Mike Klinke wrote:
>
>
>That was not the case for this bug report. Give me specific instances
>where bugzilla search didnt provide the results you wanted out of it
>while it already had the content you were looking and copy the mails to
>dkl AT redhat.com. I suspect a lot of these complaints are wrong user
>queries.
>
>
When it is so easy to do a wrong query, there might be something wrong
with the software and not with the user ;-)
Please be specific enough and provide examples.What is the current
results and what is expected in the search query?. If you are talking
about interface improvements can you provide mockups?. If not what can
you do to help?
--
Rahul
Fedora Bug Triaging - http://fedoraproject.org/wiki/BugZappers
12:24 p.m.
On Tuesday 14 February 2006 12:18, Rahul Sundaram wrote:
Please be specific enough and provide examples.What is the
current results and what is expected in the search query?.
Plug "Sundarm" into the initial bugzilla quick search and compare
the results by plugging:
"Sundaram site:bugzilla.redhat.com"
into Google.
Regards, Mike Klinke
12:28 p.m.
On 2/14/06, Mike Klinke <lsomike(a)futzin.com> wrote:
Plug "Sundarm" into the initial bugzilla quick search and
compare
the results by plugging:
"Sundaram site:bugzilla.redhat.com"
into Google.
Hey, can you write to google and see if you can get them to release
details specifics about their search algorithm so we can re-implement
it in open source codebases. Great! thanks!
-jef
2:50 p.m.
On Tuesday 14 February 2006 12:28, JS wrote:
Hey, can you write to google and see if you can get them to
release details specifics about their search algorithm so we can
re-implement it in open source codebases. Great! thanks!
Not sure I understand your suggestion. Are you suggesting that the
bugzilla search/interface cannot be improved?
I think we have already identified a difference in that bugzilla is
geared toward insuring duplicates are filed a due to the bugzilla
search engine's default configuration.
Regards, Mike Klinke
3:30 p.m.
On 2/14/06, Mike Klinke <lsomike(a)futzin.com> wrote:
Not sure I understand your suggestion. Are you suggesting that the
bugzilla search/interface cannot be improved?
No.. of course it can be improved.. I'm suggesting that your example
does nothing but state the obvious fact that google has a better
search algorithm than bugzilla... and the statement of that obvious
fact doesn't help us identify how the bugzilla search can be made
better specifically.
I'm suggesting that there is very little to be learned from the
specific comparison to google. I'm saying that since we are incapable
of examining the details of how google search works, there is very
little to be gleamed from looking at example output from google at
all. The magic in the google search is the search algorithm which
produces the results. And its exactly that piece of magic which we
don't have access to to examine and reuse. Are you really suggesting
that we blindly reverse-engineer the google search algorithm and apply
it to bugzilla?
-jef"breaking news! google..which basis its whole business model on
being an search service..has a great proprietary search
algorthim..film at 11"spaleta
3:56 p.m.
On Tuesday 14 February 2006 15:30, Jeff Spaleta wrote:
No.. of course it can be improved.. I'm suggesting that your
example does nothing but state the obvious fact that google has a
better search algorithm than bugzilla... and the statement of
that obvious fact doesn't help us identify how the bugzilla
search can be made better specifically.
Because of the comparison Rahul noted that the difference was that
bugzilla defaults to looking at closed bugs only while Google looks
at everything it can find at the site. If the comparison weren't
made we'd probably have missed that. It has little to do with
Google's search algorithms and more to do with bugzilla's default
settings.
Regards, Mike Klinke
4:11 p.m.
Mike Klinke wrote:
On Tuesday 14 February 2006 15:30, Jeff Spaleta wrote:
>No.. of course it can be improved.. I'm suggesting that your
>example does nothing but state the obvious fact that google has a
>better search algorithm than bugzilla... and the statement of
>that obvious fact doesn't help us identify how the bugzilla
>search can be made better specifically.
>
>
Because of the comparison Rahul noted that the difference was that
bugzilla defaults to looking at closed bugs only while Google looks
at everything it can find at the site.
I said bugzilla only looks at open reports by default. Not closed ones.
--
Rahul
Fedora Bug Triaging - http://fedoraproject.org/wiki/BugZappers
12:39 p.m.
Mike Klinke wrote:
On Tuesday 14 February 2006 12:18, Rahul Sundaram wrote:
>Please be specific enough and provide examples.What is the
>current results and what is expected in the search query?.
>
>
Plug "Sundarm" into the initial bugzilla quick search and compare
the results by plugging:
Typo there. Regardless of that bugzilla doesnt search closed reports by
default. Search them by default would waste a lot of time and users
generally care only about open bug reports.
"Sundaram site:bugzilla.redhat.com"
into Google.
An advanced query on the user name and status set to include closed
reports seems to work as expected. http://tinyurl.com/dpyuz
--
Rahul
Fedora Bug Triaging - http://fedoraproject.org/wiki/BugZappers
12:46 p.m.
On Tuesday 14 February 2006 10:39, Rahul Sundaram wrote:
Regardless of that bugzilla doesnt search closed reports by
default. Search them by default would waste a lot of time and users
generally care only about open bug reports.
I'm not so sure of that. I *always* search the closed bugs also. You can often
find similar issues, or possibly something that was just closed... If the
user isn't constantly updating their installed software, they may be running
into a bug that was already closed as resolved in a recent release.
I know, technically, they should upgrade before reporting a bug, but that
isn't always the case, and sometimes the bug is closed as fixed for the next
rawhide release, and the user is staying with a release version, so they
never see the bug... I think maybe searching open and recently-closed bugs
would be a better default (though I dunno what 'recent' should be, exactly.
--
Jarod Wilson
jarod(a)wilsonet.com
8:06 a.m.
At 01:46 PM 2/14/2006, you wrote:
On Tuesday 14 February 2006 10:39, Rahul Sundaram wrote:
> Regardless of that bugzilla doesnt search closed reports by
> default. Search them by default would waste a lot of time and users
> generally care only about open bug reports.
I'm not so sure of that. I *always* search the closed bugs also. You can
often
find similar issues, or possibly something that was just closed... If the
user isn't constantly updating their installed software, they may be running
into a bug that was already closed as resolved in a recent release.
It's a general guideline that the default search request should
turn up *everything* that's possibly relevant. Yes, it's bad to get 50
items, 5 of which are relevant, but it's much worse to get 0 items when 7
are relevant... The latter is what you often see on site-specific search
engines because people set the defaults too tight; people are so used to
getting 0 results when they do a search on a site that they often don't
even try search features embedded in a site.
As for the problem of open vs. closed bugs, there is a simple
answer...
(i) Have a display, either on top or on the side, that says something like
13 bugs unassigned
17 bugs assigned
104 bugs resolved
...
people can click on the link to be directed to just a list of bugs with the
above status.
(ii) Make sure that casual (and serious) users can instantly scan the
status of a bug with a minimum amount of cognitive effort.
(iii) Order the bugs in order of closed status (open first) unless you've
got a much more compelling ranking function (suppose you have some
indication of how many people are interested in a bug, you might put the
popular bug at the top)
RH's bugzilla faces a problem that many sites have: multiple populations
of users. (1) There's a group of RH employees and serious Fedora
contributors who look at bugzilla every day. (2) There's a group of
hardcore Fedora enthusiasts who put bugs into bugzilla on a regular
basis. (3) There's a group of Fedora enthusiasts who use bugzilla only
occasionally, but they've found a problem that concerns them and that
they're passionate about getting fixed.
Since people of class (1) are in charge of maintaining Bugzilla, they
aren't going to have trouble getting their needs met. On the other
hand, making it easy for people to join group (3) and move to (2) is
critical for the success of the project.
It may make sense to make the interface for bugzilla bimodal: have one
interface that's designed to be foolproof for the casual user, and another
one that's customizable so that people who use Bugzilla continuously don't
have their attention distracted by irrelevant stuff (closed bugs) and don't
wear out their wrists with excessive pointing and clicking.
8:11 a.m.
Paul A Houle wrote:
At 01:46 PM 2/14/2006, you wrote:
> On Tuesday 14 February 2006 10:39, Rahul Sundaram wrote:
> > Regardless of that bugzilla doesnt search closed reports by
> > default. Search them by default would waste a lot of time and users
> > generally care only about open bug reports.
>
> I'm not so sure of that. I *always* search the closed bugs also. You
> can often
> find similar issues, or possibly something that was just closed... If
> the
> user isn't constantly updating their installed software, they may be
> running
> into a bug that was already closed as resolved in a recent release.
It's a general guideline that the default search request
should turn up *everything* that's possibly relevant. Yes, it's bad
to get 50 items, 5 of which are relevant, but it's much worse to get
0 items when 7 are relevant... The latter is what you often see on
site-specific search engines because people set the defaults too
tight; people are so used to getting 0 results when they do a search
on a site that they often don't even try search features embedded in a
site.
As for the problem of open vs. closed bugs, there is a simple
answer...
(i) Have a display, either on top or on the side, that says
something like
13 bugs unassigned
17 bugs assigned
104 bugs resolved
...
people can click on the link to be directed to just a list of bugs
with the above status.
Can you file a RFE against bugzilla and let me know the report number?
--
Rahul
Fedora Bug Triaging - http://fedoraproject.org/wiki/BugZappers
12:49 p.m.
Once upon a time, Rahul Sundaram <sundaram(a)fedoraproject.org> said:
Typo there. Regardless of that bugzilla doesnt search closed reports
by
default. Search them by default would waste a lot of time and users
generally care only about open bug reports.
That's a cause of a number of dupes. Users care about bugs; if a report
on the same bug is closed, they won't need to report the same problem
(as it is presumably resolved and the closed report will tell the
resolution).
A convenient shortcut that would be useful for Fedora would be a way to
search "current" releases by default (e.g. 4, fc5t2, and devel at the
moment).
--
Chris Adams <cmadams(a)hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
12:50 p.m.
On 2/14/06, Rahul Sundaram <sundaram(a)fedoraproject.org> wrote:
Typo there. Regardless of that bugzilla doesnt search closed reports
by
default. Search them by default would waste a lot of time and users
generally care only about open bug reports.
I don't really know if you can make that "general" claim.
I find a lot of users who don't religiously run full system updates,
whether it be because of bandwidth or laziness or whatever, wander
into #fedora and ask specific questions about specific bugs which are
clearly closed and incorporated into some sort of update..even if its
a rawhide only fix. And lets face it, somethings which irk users of
current releases get closed as resolution rawhide and don't make it
into an actual release update. Those closed bugreports still have
relevancy even to up-to-date current release systems.
On a persona note, I personally don't bother with the default searches
anymore when tracking down previously reported bugs when
troubleshooting symptoms reported in #fedora.
-jef
1 p.m.
Jeff Spaleta wrote:
On 2/14/06, Rahul Sundaram <sundaram(a)fedoraproject.org> wrote:
>Typo there. Regardless of that bugzilla doesnt search closed reports by
>default. Search them by default would waste a lot of time and users
>generally care only about open bug reports.
>
>
I don't really know if you can make that "general" claim.
Thats the claim being made when selecting the default. Do you believe
that searching through bugzilla for all the closed bug report makes
better sense as the default?
I find a lot of users who don't religiously run full system
updates,
whether it be because of bandwidth or laziness or whatever, wander
into #fedora and ask specific questions about specific bugs which are
clearly closed and incorporated into some sort of update..even if its
a rawhide only fix. And lets face it, somethings which irk users of
current releases get closed as resolution rawhide and don't make it
into an actual release update. Those closed bugreports still have
relevancy even to up-to-date current release systems.
Then reopen it asking for an update against the current release or file
another bug report asking for a fix or better yet provide a patch
depending on the severity of the bug. Some of the fixes would of course
be only available in the next release. I dont see this as improvement
that affects triaging.
--
Rahul
Fedora Bug Triaging - http://fedoraproject.org/wiki/BugZappers
1:14 p.m.
On 2/15/06, Rahul Sundaram <sundaram(a)fedoraproject.org> wrote:
[...] I dont see this as improvement that affects triaging.
I think that any bugzilla improvements resulting in improved bug
reports or reduced numbers of duplicates should in turn increase
triaging efficiency.
n0dalus.
1:23 p.m.
n0dalus wrote:
On 2/15/06, Rahul Sundaram <sundaram(a)fedoraproject.org> wrote:
>[...] I dont see this as improvement that affects triaging.
>
>
>
I think that any bugzilla improvements resulting in improved bug
reports or reduced numbers of duplicates should in turn increase
triaging efficiency.
If you have a bugzilla RFE that directly affects triaging instead of a
generic enhancement like improving search speed, file in against
bugzilla itself as a component in http://bugzilla.redhat.com and let me
know the report number. Thanks.
--
Rahul
Fedora Bug Triaging - http://fedoraproject.org/wiki/BugZappers
7:26 p.m.
n0dalus wrote:
On 2/15/06, Rahul Sundaram <sundaram(a)fedoraproject.org> wrote:
>[...] I dont see this as improvement that affects triaging.
>
>
>
I think that any bugzilla improvements resulting in improved bug
reports or reduced numbers of duplicates should in turn increase
triaging efficiency.
n0dalus.
A related question from a "newbie". If I think I have a bug in
FC(n) and a search finds a remarkably similar bug in FC(n-1), be
it OPEN, CLOSED, NEEDINFO_REPORTER, or whatever, filed by someone
else, what should be my next step?
John D.
7:43 p.m.
On Tue, 2006-02-14 at 21:26 -0400, John DeDourek wrote:
n0dalus wrote:
>On 2/15/06, Rahul Sundaram <sundaram(a)fedoraproject.org> wrote:
>
>
>>[...] I dont see this as improvement that affects triaging.
>>
>>
>>
>
>I think that any bugzilla improvements resulting in improved bug
>reports or reduced numbers of duplicates should in turn increase
>triaging efficiency.
>
>n0dalus.
>
>
>
A related question from a "newbie". If I think I have a bug in
FC(n) and a search finds a remarkably similar bug in FC(n-1), be
it OPEN, CLOSED, NEEDINFO_REPORTER, or whatever, filed by someone
else, what should be my next step?
Good point. If it's OPEN or NEEDINFO it's probably good to tack on to
the bug and say it's still present in FC(n), version x.y-z of the
package. Sometimes "remarkably similar" is only in the eyes of the
reporter, though... I think Mike Harris has mentioned that he gets X
bugs where people with different chipsets but the same symptoms pile
onto the same bug report, making the eventual resolution of the bug next
to impossible.
If it's CLOSED, I'd say that opening a new bug (mentioning the previous
bug if you think there's a relationship) is my gut feeling. Someone
else may have better reasoning that there's a better way to deal with
this though.
-Toshio
1:26 p.m.
On Wed, 2006-02-15 at 00:30 +0530, Rahul Sundaram wrote:
Jeff Spaleta wrote:
>On 2/14/06, Rahul Sundaram <sundaram(a)fedoraproject.org> wrote:
>
>
>>Typo there. Regardless of that bugzilla doesnt search closed reports by
>>default. Search them by default would waste a lot of time and users
>>generally care only about open bug reports.
>>
>>
>
>I don't really know if you can make that "general" claim.
>
>
Thats the claim being made when selecting the default. Do you believe
that searching through bugzilla for all the closed bug report makes
better sense as the default?
Yes.
Or at least, best-when-searching-for-dupes a convenient entry point to
which is part of the submit new bug process. Perhaps most useful is:
search for open or closed bugs in Fedora Release I'm running or later
(FC3, FC4, devel), (FC4, devel), or (devel) currently (although that
requires asking for the FC-release before running the query.)
-Toshio
1:32 p.m.
Hi
>
>
>
Yes.
Or at least, best-when-searching-for-dupes a convenient entry point to
which is part of the submit new bug process. Perhaps most useful is:
search for open or closed bugs in Fedora Release I'm running or later
(FC3, FC4, devel), (FC4, devel), or (devel) currently (although that
requires asking for the FC-release before running the query.)
Can you file a RFE against bugzilla and let me know the report number?
--
Rahul
Fedora Bug Triaging - http://fedoraproject.org/wiki/BugZappers
1:49 p.m.
On 2/14/06, Toshio Kuratomi <toshio(a)tiki-lounge.com> wrote:
Or at least, best-when-searching-for-dupes a convenient entry point
to
which is part of the submit new bug process. Perhaps most useful is:
search for open or closed bugs in Fedora Release I'm running or later
(FC3, FC4, devel), (FC4, devel), or (devel) currently (although that
requires asking for the FC-release before running the query.)
I would propose having seperate entry pages for the different
distribution products.
Do we really need to drive rhel and fedora users to the same default
bugzilla search page? Can we embed different default bugzilla search
box into product specific "portal" sites and drive users into bugzilla
through that embedded search box? Cam we embed a bugzilla query box
into wikipages at fedoraproject.org? If we can you can easily mock up
"portal" default queries for Extras and Core and Legacy and Docs by
giving each part of the Fedora space its own "portal" wikipage with an
embedded custom bugzilla query box.
-jef
1:42 p.m.
On 2/14/06, Rahul Sundaram <sundaram(a)fedoraproject.org> wrote:
Thats the claim being made when selecting the default. Do you
believe that searching through bugzilla for all the closed bug report
makes better sense as the default?
Appropriately organized.... yes. More than lumping all open
rhel+fedora+fedora-legacy into the same single query box. Which is
more relevant to a user of fedora's current release... rhel bugs or
closed fc4 bugs? The single search box for all of the "product"
definitions in bugzilla makes ill-fitting assumptions about relevancy
in an effort to shoehorn all the products in the same single text box.
I think perhaps making it easy to add closed reports for a specific
release into an updated results list without having to go through the
full advanced query interface would make it a smoother process. Make
it easier to refine a query inside the result list page.
Make it clear that the default query box searches all open bugs in all
"product" release get list A of open tickets for rhel+fedora
Core+fedora legacy+whatever
Then in ui that hangs around list A make it easy to narrow the search
to a specific product "rhel OR fedora OR whatever" and add closed bugs
back in into the result...without invoking the full advanced search
UI.
Then reopen it asking for an update against the current release or
file
another bug report asking for a fix or better yet provide a patch
depending on the severity of the bug. Some of the fixes would of
course be only available in the next release.
You misunderstand... how do users reopen a bug they don't know exists
because its not in the default search? Users using the default search
box who are searching for already reported bugs filed against the
release they are using which have been closed rawhide are
unfortunately mislead to believe that the bug has not been reported
yet.. unless they take the extra effort to do the non-default query
and include rawhide resolved bugs. Nor do they see any subsequent
dupes of that bug which get filed and marked as dupes. Having
multiple "normal" users refile the same bug again and again to be
marked as a duplicate again again against the rawhide resolved bug
they don't see in the default search ui is just a waste of time.
I dont see this as improvement
that affects triaging.
Do you want to limit the duplicate filing of already closed bugs or do
you want to encourage the filing of duplicates to already closed bugs?
I understand the value of duplicate bug reports for open bugs, as tool
to guage the extent of occurance of hard to reproduce or hardware
specific problems. But I am unsure of the value of setting up a
default search bug which delibrately hides rawhide resolved bugs and
encourages people to refile bugs which have already been marked
rawhide resolution.
-jef
2:20 p.m.
Regarding the duplicate filings in this particular case, this RFE seems
to address the same problem::
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=169746
On Tue, 2006-02-14 at 14:42 -0500, Jeff Spaleta wrote:
On 2/14/06, Rahul Sundaram <sundaram(a)fedoraproject.org> wrote:
> Thats the claim being made when selecting the default. Do you
> believe that searching through bugzilla for all the closed bug report
> makes better sense as the default?
Appropriately organized.... yes.
I've filed:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181524
Please add anything you think is relevant, Jef.
-Toshio
12:57 p.m.
On Tuesday 14 February 2006 12:39, RS wrote:
bugzilla doesnt search closed reports by
default. Search them by default would waste a lot of time and
users generally care only about open bug reports.
It's not clear to the casual user, there's no "advanced" search
entry point on the page ( bugzilla.redhat.com ) and you're sure to
get dups of bugs that have already been closed. It seem's more
productive to check all bugs by default and select open bugs by
choice if dups are something you're trying to avoid.
Search them by default would waste a lot of time and
users generally care only about open bug reports.
I suggest that "users" really care to know first if what they've
found has been seen by anyone else and then second whether it's
been fixed.
Regards, Mike Klinke
4:37 p.m.
...... Original Message .......
On Wed, 15 Feb 2006 00:09:36 +0530 "Rahul Sundaram"
<sundaram(a)fedoraproject.org> wrote:
Mike Klinke wrote:
>On Tuesday 14 February 2006 12:18, Rahul Sundaram wrote:
>
>
>
>>Please be specific enough and provide examples.What is the
>>current results and what is expected in the search query?.
>>
>>
>
>
>Plug "Sundarm" into the initial bugzilla quick search and compare
>the results by plugging:
>
>
Typo there. Regardless of that bugzilla doesnt search closed reports by
default. Search them by default would waste a lot of time and users
generally care only about open bug reports.
I pretty much always search closed reports (if not all the available
states). Anything else is non-deterministic.
___
Dax Kelson
Sent with my Treo
12:33 p.m.
tir, 14 02 2006 kl. 23:48 +0530, skrev Rahul Sundaram:
Please be specific enough and provide examples.What is the current
results and what is expected in the search query?. If you are talking
about interface improvements can you provide mockups?. If not what can
you do to help?
One of the really good ideas in Malone (Ubuntu' bugtracker) is that the
database can be traversed like a directory, I would love to be able to
do something similar, like this:
+ Fedora
+ Core
+ cdrecord [All open bugs] [All open bugs upstream] [File bug]
So that I don't have to enter search terms to find an application, check
the list of bugs of this application and check upstream for known bugs
(and if relevant point a pointer bug in FC bugzilla to upstream for
tracker blocker purposes, etc.).
- David
If someone could hook up translations in the same way I would consider
them worthy of doughnut rain.
--
Obligatory shameless blog plug - the GNOME commentary located at:
www.lovesunix.net/blog
12:44 p.m.
David Nielsen wrote:
tir, 14 02 2006 kl. 23:48 +0530, skrev Rahul Sundaram:
>Please be specific enough and provide examples.What is the current
>results and what is expected in the search query?. If you are talking
>about interface improvements can you provide mockups?. If not what can
>you do to help?
>
>
One of the really good ideas in Malone (Ubuntu' bugtracker) is that the
database can be traversed like a directory, I would love to be able to
do something similar, like this:
+ Fedora
+ Core
+ cdrecord [All open bugs] [All open bugs upstream] [File bug]
So that I don't have to enter search terms to find an application, check
the list of bugs of this application and check upstream for known bugs
(and if relevant point a pointer bug in FC bugzilla to upstream for
tracker blocker purposes, etc.).
- David
I discussed Malone with the Ubuntu people over email when someone
mentioned this in fedora-test list. It is a proprietary application now
and we would rather use a Free and open source application without our
infrastructure. I heard there are plans to include XML RPC support in
bug buddy so thats a good thing.
If someone could hook up translations in the same way I would
consider
them worthy of doughnut rain.
I would like to keep this discussion specific to improvements that help
in triaging bugs for now. There are broader plans to help with integrate
translation and rest of the infrastructure but thats not what I am
talking about here.
--
Rahul
Fedora Bug Triaging - http://fedoraproject.org/wiki/BugZappers
10:24 p.m.
Mike Klinke wrote:
On Tuesday 14 February 2006 11:41, Rahul Sundaram wrote:
>Save us a few hours of bugzilla grunt work by not filing two
>hundred and seventeen duplicates for a trivial bug. Thanks.
>
>https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181064
>
>If anyone has a list of good improvements that can be made to
>bugzilla to help is triaging let me know.
Over the years the single biggest complaint voiced on these lists is
the poor search results bugzilla provides. If the searches
provided better results perhaps duplcatess wouldn't be so
prevalent.
Regards, Mike Klinke
I agree with the search feature for bugs. Bug searches could return hits
for bugs filed against rawhide with dates related to the bug era
(fc5t1,2 or 3) since these should be test release bugs in reality. This
would cut down on the duplicate bug filings.
Rawhide since yum was adopted does not allow rawhide to be rawhide
during test phases. It is the test release update source also.
I think having actual update repos for the test releases would eliminate
this factor.
Bugzilla itself would work better if it would either group all
duplicates in some type of directory structure or would merge
information from one bug that is a duplicate of another bug into a
common report.
Another ideal condition would be linking all these similar reports into
a common "best of this bug" (Useful data for resolving the bug) for
commonly duplicated bug problems. There are some developers which have
done something similar for highly duplicated problems and the results
were positive. (gcc and mga/intel problem comes to mind)
Jim
The universe does not have laws -- it has habits, and habits can be broken.
12:02 p.m.
On Tue, 2006-02-14 at 23:11 +0530, Rahul Sundaram wrote:
Save us a few hours of bugzilla grunt work by not filing two hundred
and
seventeen duplicates for a trivial bug. Thanks.
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181064
If anyone has a list of good improvements that can be made to bugzilla
to help is triaging let me know.
I assume the two hundred and seventeen duplicates were caused by a
malfunction of the left mouse button.
In this case, double-click protection would have done the trick, i.e.
generate a token when generating the initial form and only accept the
first submission of the form with that token. Or search for existing
bugzillas with identical text upon submission.
David
12:10 p.m.
David Lutterkort wrote:
On Tue, 2006-02-14 at 23:11 +0530, Rahul Sundaram wrote:
>Save us a few hours of bugzilla grunt work by not filing two hundred and
>seventeen duplicates for a trivial bug. Thanks.
>
>https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181064
>
>If anyone has a list of good improvements that can be made to bugzilla
>to help is triaging let me know.
>
>
I assume the two hundred and seventeen duplicates were caused by a
malfunction of the left mouse button.
In this case, double-click protection would have done the trick, i.e.
generate a token when generating the initial form and only accept the
first submission of the form with that token. Or search for existing
bugzillas with identical text upon submission.
Kindly add your comments to
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=28151. Thanks.
--
Rahul
Fedora Bug Triaging - http://fedoraproject.org/wiki/BugZappers
12:29 p.m.
Rahul Sundaram wrote:
Hi
Save us a few hours of bugzilla grunt work by not filing two hundred and
seventeen duplicates for a trivial bug. Thanks.
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181064
If anyone has a list of good improvements that can be made to bugzilla
to help is triaging let me know.
Jesus Christ, what the heck was that??? I reported the bug only once,
and that was on Sunday, not today. I received hundreds of e-mails (!!!)
What the heck is going on??? I swear to God I report the Bug only once.
I never experience something like that. Thanks and sorry for that
embarrassing thing that happened.
--
Igor Jagec
12:54 p.m.
On 2/15/06, Rahul Sundaram <sundaram(a)fedoraproject.org> wrote:
If anyone has a list of good improvements that can be made to bugzilla
to help is triaging let me know.
There is a link at the bottom of a bug search to 'Change several bugs
at once.' Unfortunately it doesn't seem to let you mark bugs as dupes
-- though it lets you do almost anything else. Adding a feature for
this shouldn't be too hard, in case this kind of thing happens in
future.
I think the biggest improvement that could be made to Red Hat's
bugzilla is improving its speed. It takes so long to load every page
that you spend a good portion of any triaging time waiting for it to
load. If this is because the server isn't fast enough, I think Red Hat
needs to consider throwing some more hardware at it -- once you add up
the developer time being wasted because it's slowness, it makes sense
to spend some money and improve it. It may be slow because of the
large page sizes that bugzilla is generating. The large lists of
components and versions etc should really be put in an external
javascript file; this would allow all pages to load much faster as it
could be cached. A non-javascript version should still be available of
course. Bugzilla also doesn't seem to use gzip/deflate, it uses
chunked encoding which I'm not sure provides any compression. It's not
unsual for the pages to exceed 0.5MB in size, and on a 512k connection
that really adds up.
Other improvements that could be made is to make our bugzilla more
like Gnome's. They have their bugzilla modifications available at
cvs.gnome.org.
n0dalus.
1:02 p.m.
* n0dalus <n0dalus+redhat(a)gmail.com> [2006-02-14 13:54]:
I think the biggest improvement that could be made to Red Hat's
bugzilla is improving its speed.
Agreed.
In semi-related news, work is being done on the Bugzilla plugin for
Eclipse. Support was recently added to work with RH bugzilla via XML-RPC.
As XML-RPC makes its way into other bugzillas, the upcoming bug creation
and modification functionality will be extended to those as well. Also, I
did a bit of work to make it work as a standalone appliation (pseudo-RCP
for the Eclipse folks out there).
Interaction suggestions are always appreciated. Just file an RFE or
something in bugzilla against eclipse-bugzilla.
Andrew
6696
days inactive
6697
days old
37 comments
16 participants
participants (16)
-
Andrew Overholt -
Chris Adams -
David Lutterkort -
David Nielsen -
Dax Kelson -
Erwin Rol -
Igor Jagec -
Jarod Wilson -
Jef Spaleta -
Jim Cornette -
John DeDourek -
Mike Klinke -
n0dalus -
Paul A Houle -
Rahul Sundaram -
Toshio Kuratomi