Closed Bug 119305 Opened 23 years ago Closed 18 years ago

Bugzilla Status, Resolution, and Assignment discussion tracker

Categories

(bugzilla.mozilla.org :: General, defect)

Other
Other
defect
Not set
normal

Tracking

()

RESOLVED WONTFIX

People

(Reporter: timeless, Assigned: timeless)

References

()

Details

Attachments

(3 files)

This bug is to track the discussions from #mozilla about bugzilla status, resolution, assignment, and other bugzilla.mozilla.org behaviors.

Each entry in this bug should be an attachment. Discussions will take place in #mozilla and their logs will be attached here. If absolutely necessary we can overflow into the mozilla newsgroups (probably .qa).  If people are interested in this bug they should silently cc themselves (voting is not enabled for this product).
someone expressed concern about logs.  i'll give people ~12 hours to request redactions before i attach them here), until then they'll be available (unredacted) at the url in the url field.
Attached file synopsis by mental
Attached file my proposal
Timeless asked me to make up a summary to the logs as well. This is my take,
and while I like what I was reading, and agree, my little proposal here doesn't
feel done yet. Mental has a good start too.
Although I don't wish to throw cold water on what is I believe a fruitful
discussion that will likely provide all bugzilla.mozilla.org people and indeed
many other Bugzilla people with long-term benefit, a small dose of reality will
perhaps be useful to prevent anyone raising their expectations too high.

The main problem here is that statuses and resolutions are currently hardcoded
into Bugzilla.  Bugzilla was designed specifically for mozilla.org and its
process, and the need to have something ready reasonably quickly for them. 
These two factors meant that customisable statuses and resolutions were never
going to happen.

Of course, nowadays Bugzilla has many many installations, and even mozilla.org
is changing its process.  It is high time Bugzilla allows this fundamental
customisation.

That being said various installations can and do customise their Bugzilla
software to support different statuses and resolutions, but this is through code
forks.  Such installations must repeat their changes to each new version of
Bugzilla and must be careful the changes don't introduce bugs or miss new places
that need to be customised when the code base is rapidly shifting underneath
them as it is with Bugzilla.  I am not aware of any changes whose scope
approaches the proposal of JesusX.

It is not an option to change the Bugzilla software to support any proposal and
throw out the old way.  Many installations are accustomed to the old way and we
can't expect to be able to force them to change.

It is not an option I believe to ask mozilla.org to fork to such an extensive
degree which is much greater than I assume they have in the past and do in the
present.  Such a process is costly in terms of time, bugs, and the ability to
upgrade regularly, and would be far worse than the benefit this proposal would
provide.

Nor is it a sensible option to provide both systems, new and old - the
mozilla.org process will continue to evolve and this would just be a kludge.

The only reasonable option, therefore, is to allow Bugzilla to support any set
of statuses and resolutions, set up by the administrator.  Then existing
installations could have the old way preserved (and they could customise it at
their leisure), mozilla.org could transition to the new way, and we could even
set up the new way as a default for new installations.

The effort to do this is non-trivial, and indeed quite substantial.

I recognised the need for this some time ago and set out to allow customisation
of resolutions (bug #94534).  Originally the work seemed easy, but the devil was
in the details, and I ended up putting substantial work into this task.  I am
now, for the most part, complete, and the work is sitting on a branch waiting a
couple of prerequisite features and for the 2.16 release to be complete so it
can be reviewed and landed for 2.17.  I am hopeful it will be in CVS within 3
months.

Now customised statuses (bug #101179) are a much more difficult problem.  At the
time I considered it to be too difficult a problem to attempt.  There are
statuses, status transitions, permissions to do status transitions, differences
between open and non-open statuses, differences between confirmed, unconfirmed
and possiblyconfirmed statuses and the bugbear of future automatic transitions
to consider (BLOCKED and REMIND statuses and so on).

But since then, some of the problem has been discussed, and I have been
encouraged by how we have specified the issues, as well as what I have learned
through the resolution work.

I believe I can do most of what we would like for statuses in not much more time
than the resolutions, given that some of the legwork was done for resolutions,
plus other bits of Bugzilla work affected how I did resolutions and made it much
more of a task, such as templatisation, taint mode and administration
refactoring.

So, in a nutshell, while I fully expect the ability to do whatever bmo wishes to
arrive during this year, there is plenty of time to discuss this before it is
feasible.  If customised statuses are in CVS by August and ready to go on bmo, I
would be reasonably happy with the timeframe.  But these things of course can,
and do, slip.  Please bear this in mind in any discussion that occurs.
Assignee: endico → timeless
*** Bug 328152 has been marked as a duplicate of this bug. ***
We've had more recent discussions about Bugzilla workflow than this (see e.g. http://wiki.mozilla.org/BugzillaWorkflowImprovements) and requirements have changed. Any discussion of this sort should probably be part of that thinking.

Gerv
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → WONTFIX
Component: Bugzilla: Other b.m.o Issues → General
Product: mozilla.org → bugzilla.mozilla.org
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: