Community
Participate
Working Groups
The current bug tracking mechanism/tool imposes lots of work on the committers doing the bug triage. Given that most committers spend a noticeable amount of time in Bugzilla there should be improvements to make committer's live easier. Bugs are often incomplete or duplicates of existing bugs. Other projects for example have mandatory fields (e.g. the build id, log entries, reproducible steps, …) and show a list of possible related bugs which the bug reporter can check for duplicates before reporting a new one.
These FRs could be opened against Bugzilla. We have agreed that we would keep running "vanilla" applications on the eclipse.org infrastructure to ensure we have a clean, simple upgrade path. D.
When you say "we", who are you referring to? Is that Mike?
This is an issue that causes projects with a high number of problem reports a considerable amount of manual work. This request focuses on lowering the burden of administrative work for the projects and make them more productive in their direct project work. Please consult Mike on this subject before resolving.
(In reply to comment #1) > These FRs could be opened against Bugzilla. > > We have agreed that we would keep running "vanilla" applications on the > eclipse.org infrastructure to ensure we have a clean, simple upgrade path. Bugzilla provides support for "guided" bug reporting. However, this requires to maintain a wizard for filling bugs. Example: http://bugzilla.mozilla.org/enter_bug.cgi?product=Bugzilla This might not solve alle problems but might be a workaround to force a user to enter more information when reporting bugs.
(In reply to comment #2) > When you say "we", who are you referring to? Is that Mike? We discussed this at our staff meeting in July. Even Skip agreed that running vanilla software was the way to go =) Although we agreed to not touch the bugzilla code, nothing stops us from developing third-party tools to access and manipulate the bugzilla database. These tools could potentially impact data integrity and could break when upgrading Bugzilla, but at least the core bugzilla code hasn't been changed. Adding Mike to the CC. Mike, can you comment on this? D.
(In reply to comment #5) > (In reply to comment #2) > > When you say "we", who are you referring to? Is that Mike? > Adding Mike to the CC. Mike, can you comment on this? Ah yes. The omnipresent Mike. First, let me say that I think that bug triage is a big problem that we need to fix. Far too much committer time is being wasted on dups and poorly written bugs. Unfortunately I have a personality disorder that causes me to immediately start to wonder about the macro case. We have always resisted modifying the source code for our tools (primarily Bugzilla and CVS) because of the obvious support burden this would put on us. In fact, my recollection was that we discussed and agreed to this at the Board. But all of this is a statement in time, not a religious position. If we decide that the pain of using Bugzilla "as is" is greater than the pain to change it, then we could look at making the changes and supporting them. (Or perhaps contributing resources to the Bugzilla project??) But where does this stop? I am pretty worried that we are getting onto a slippery slope if we start making and supporting major modifications to our development infrastructure. If that is really the way we need to go, then: (a) I think that a group of concerned committers need to work with Bjorn and Denis to really get a handle on *all* the required changes. If this has already been done, then let's get a document out for community review and comment. Or do we really believe that this bug is the only thing people want? (Translation: starting a never-ending series of incremental changes is not my idea of fun.) (b) If many changes are required, perhaps its time to think outside the box. Look at alternatives ranging from switching to JIRA and Subversion to outsourcing the whole thing to SourceForge or Collabnet that are in this business. (Translation: Let's have a clear strategy.) (c) Every other open source project I know of approaches this problem as a community issue. If the committers are unhappy with the infrastructure, one obvious solution is to create a project led by Denis or Bjorn with help from concerned committers where they build and maintain the modifications. Making this work entirely a Foundation issue does not scale and is missing an opportunity for community building IMHO. (Translation: Let's see if we can engage the community.) If, in the end, we decide that staffing a position at the Foundation to build and maintain these mods is the right thing to do, I am certainly willing to consider it. But right now I am neither convinced that is necessary or the right thing for the community. But I know Bjorn can be persuasive :-)
This issue seems to be open with Mozilla since 1999: https://bugzilla.mozilla.org/show_bug.cgi?id=22353
I'm closing this as LATER. Feel free to reopen if you have a follow-up to comment 6. D.
(In reply to comment #6) > First, let me say that I think that bug triage is a big problem that we need to > fix. Far too much committer time is being wasted on dups and poorly written bugs. You might want to have a look at what the KDE project did to bugzilla -- basically a PHP frontend that guides bugreporters in a wizard-like manner to submit better reports. To avoid as many dupes as possible, the reporter needs to enter some keywords (typically the summary line) with which a bug database search is performed. The reporter is presented the results and is asked to look for reports that look like his own problem. If he finds one, he usually adds a comment to that bugreport and adds himself to the CC list. If he doesn't he can go on and submit a new one. That process helped tremendously in preventing dupes. To see it in action, visit http://bugs.kde.org -- you need to create an account to access the reporting wizard, though.
(In reply to comment #9) > You might want to have a look at what the KDE project did to bugzilla -- > basically a PHP frontend that guides bugreporters in a wizard-like manner to > submit better reports. > > To avoid as many dupes as possible, the reporter needs to enter some keywords > (typically the summary line) with which a bug database search is performed. > > The reporter is presented the results and is asked to look for reports that > look like his own problem. > > If he finds one, he usually adds a comment to that bugreport and adds himself > to the CC list. > > If he doesn't he can go on and submit a new one. > > That process helped tremendously in preventing dupes. > > To see it in action, visit http://bugs.kde.org -- you need to create an account > to access the reporting wizard, though. I think that this one could be a really good enhancement for Mylar. There was few others that should simplify process of submitting bugs agaianst the Eclipse itself...
Regarding enhancing Bugzilla by Regarding enhancing Bugzilla, I think it would be a bad idea to fork the codebase. That's what CollabNet has done and they haven't kept up with the improvements, since Bugzilla does have a steady momentum behind it. Also, Bugzilla.org seems quite responsive to patches so many of the desired improvements could come in that form if the foundation singed up for it. In general I'm +1 for some foundation resources going to Bugzilla improvements, and think it would be great if Eclipse eventually had a committer on the project that could help tailor Bugzilla to eclipse.org's needs. Regarding other options, I think that as an open source brand we need to build and work on other open source technologies whenver possible. Not just for the open source principles that guide us, but also because we are large enough that the ability to contribute, or fork if all else fails, is probably both more valuable and less expensive than being tied into a vendor (even if they are OSS friendly like JIRA). Regarding specific options, I judged the project management and bug tracker categories for the Jolt Awards and so reviewed the two dozen leading solutions. As a quick summary of the ones that could scale to ecipse.org I think that CollabNet and SourceForge EE would work worse that our current infrastructure and not add much. Wrt to bug trackers JIRA is probably the best. But it's only big improvement over Bugzilla is a better web UI. Unsurprisingly I believe that Bugzilla+Mylar is a much better user experience than JIRA, thanks to the Eclipse integration and all that it enables. Let me know if you want more opinions on any of the leading solutions. Regarding Eugene's suggestion and the description, yes, this is something we could do pretty easily if there was interest (bug 143567). We already have a prototype backround search facility that will find related reports based on stack trace matches but have not enabled this in the UI since we were concerned about overloading the Bugzilla. But making it work on submission makes sense and would probably result in fewer searches in the end ;) Also, the automatic creation of a bug report from an Eclipse Error Log view that we're planning (bug 135605) would greatly benefit from finding reports with the same stack trace.
I would like to suggest tikal open source Bugzilla (2.20) enhancement which has great improvment over the regular bugzilla: * Issue Type, which enable issue tracking * Version Control Integration CVS and Subversion * Multi Target and Fixed in versions * Sub-tasks issues * Keyword helper * Browse Dashboard * and more... Please, feel free to use this version https://dev.tikalk.com/bugzilla_tr Browser Prompt: User: eclipse Password: eclipse
Reopening LATER/REMIND bugs.
https://bugzilla.mozilla.org/show_bug.cgi?id=22353 This is RESOLVED/FIXED with BZ 4.0, which we will be deploying in a couple of weeks.
There's a JSON perl library that's not installing properly. This is preventing us from enabling the Duplicate Bug Detection.
Duplicate bug detection is enabled.
