Closed Bug 336790 Opened 19 years ago Closed 16 years ago

multiple status/resolution fields within a single bug for different product versions

Categories

(Bugzilla :: Creating/Changing Bugs, enhancement)

Product:
Bugzilla
Component:
Creating/Changing Bugs
Version:
2.23
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WONTFIX

People

(Reporter: asa, Unassigned)

Details

(Whiteboard: [wanted-bmo])

See prior attempts and related bugs at bug 55970, bug 79964, and bug 277917. Please do not dupe this against any of those. If this specific feature request is shot down, then just shoot it down :-) The Problem: It is a common situation that a bug applies to multiple versions of a product. It's also common that in those situations the overwhelming majority of information on the bug applies to all of the product versions. At Mozilla, we already manage patches for different versions in the same bug using the fantastic attachment management + flags feature but we cannot easily track the actual bug status/resolution for each of the versions affected. The Solution: Create a status/resolution manager, akin to the patch manager, for tracking multiple version status/resolution combos in a bug. This will initially be populated by the version selected in enter_bug. The Details: * show_bug UI similar to the attachment manager. Something like this: +====================+================+=================+===========+ | Version | Status | Resolution | Actions | |====================+================+=================+===========| | Firefox 1.0.8 | [Obsolete|v] | | [Submit] | |--------------------+----------------+-----------------+-----------| | Firefox 1.0.9 | [Verified|v] | Wontfix | [Submit] | |--------------------+----------------+-----------------+-----------| | Firefox 1.5.0.1 | [New |v] | | [Submit] | |--------------------+----------------+-----------------+-----------| | Firefox 2.0 | [Resolved|v] | Fixed | [Submit] | |--------------------+----------------+-----------------+-----------| | Add Version: [________________|v] | +-------------------------------------------------------------------+ * To change a status/resolution, you just pick the Status from the first select widget and that populates the Resolution widget (if applicable) with the corresponding choices. You then chose the correct Resolution from the second select and hit submit. * To add a new version to the table, you simply select the version from the Add Version select. (This satisfies msot of bug 79964 and bug 55970, I believe.) * Status choices would include at least New, Resolved, Verified, and Obsolete (or Invalid) * Resolutions would include at least Fixed and Wontfix. An alternative, and possibly simpler UI, would combine the Status and Resolutions into a single HTML select widget: +-------------------+ | New |v| |-------------------| | Resolved Fixed | | Resolved Wontfix | | Verified Fixed | | Verified Wontfix | | Obsolete | +-------------------+ * Version status/resolution is independent of Bug status/resolution. The normal process at b.m.o. will be that bugs remain open until all versions have a resolution. At that point, the bug can be resolved.
OS: Windows XP → All
Hardware: PC → All
Version: unspecified → 2.23
I just realized Asa filed something slightly different from what I envisioned after our hallway discussion. I wanted branch status rather than specific version status. Since we quite often bump middle-priority bugs out to the next release (multiple times, even) this would help prevent a proliferation of version lines. See some of the bugs with blocking1.8.0.3-, blocking1.8.0.4-, blocking1.8.0.5-... fixed1.8.0.7 or similar. So in my variant we'd need: Branch name (1.8.0 branch, 1.8 branch) Status Resolution Target Milestone (1.8.0.1, 1.8.0.2, 1.8.0.3..., 2.0a1, 2.0a2 etc) blocking flag (nom, plus, minus) A nice refinement would be an automatically set "fixed-in" field (for the main bug, too) since the target-milestone sometimes differs. It'd be at least as easy to maintain a "active release for branch" list as it is to keep creating fixed-X/verified-X keywords and all the blocking/approval flags.
Asa: I apologize for hijacking your enhancement request if you really hate my version. Obviously we can only get one or the other (and probably lucky if we get that) so it seemed better to hash out variant suggestions here than create competing mutually exclusive requests. I think doing it by branch rather than version specific would lend itself better to how we manage security releases and lead to less visually cluttered bugs.
No problem, Dan. One thing to consider here is that we're likely going to need a feature that's too not Mozilla process specific.
Whiteboard: [wanted-bmo]
Blocks: bz-branch
Status: NEW → ASSIGNED
As timello asked me on IRC my opinion about this bug, here is what I think: I don't like adding new fields to bugs. We already have many of them. Bugs about the same issue should all be blockers of a meta-bug, one per branch and which you can resolve individually. The meta-bug would then be closed when all its blockers (i.e. all branches) are resolved. This way, you can have different priorities and/or severities, different assignees, different sets of CC users, etc... per branch. Now you say that comments may be the same across all branches. Maybe bugs having a meta-bug could have an additional checkbox near the comment textarea "Share this comment with all its brothers", where a bug's brother would be the same issue but for a different branch. So the only change we would have to do is basically to have a new kind of bug, a.k.a meta-bugs. This only a single attribute to add to each bugs. Technically, the meta_bug column in the DB would have the ID of the meta-bug. It would be NULL for bugs not having one.
(In reply to comment #4) > This only a single attribute to add to each bugs. ... only consiste to add a single attribute...
I believe we will be WONTFIX'ing this bug in favor of a solution that implements more of the needs of all the various organizations using Bugzilla. See bug 55970 comment 18. If you think there's an advantage to this bug over that one, feel free to comment here and discuss it before we WONTFIX this in favor of that. For what it's worth, this bug describes my original ideas on the situation as well, but after discussing it with the other Bugzilla developers and one of my clients in the field, I think that what I've described in bug 55970 will be more broadly useful.
Per my comment 4 in this bug -> WONTFIX.
Okay, WONTFIX unless somebody shows us some huge advantage over bug 55970.
Status: ASSIGNED → RESOLVED
Closed: 17 years ago
Resolution: --- → WONTFIX
This is entirely different than bug 55970. That bug would see us creating multiple bugs for each branch, this one doesn't have that requirement.
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
(In reply to comment #9) > This is entirely different than bug 55970. That bug would see us creating > multiple bugs for each branch, this one doesn't have that requirement. Yes, but we're only going to implement one of them, and bug 55970 is a broader solution. The fact that we're creating multiple bugs will to a large degree, ideally, seem like just an implementation detail, as long as we do the UI right. You're free to present a case for this bug and request that we re-open it, but since none of the developers on the Bugzilla Project plan on implementing this over bug 55970 (as far as I know), we are going to leave it as WONTFIX for now.
Status: REOPENED → RESOLVED
Closed: 17 years ago → 16 years ago
Resolution: --- → WONTFIX
FWIW, I originally implemented requests as related bugs (one per request), but I threw that implementation away and reimplemented them from scratch as an attribute of bugs because the initial implementation proved unwieldy, both code-wise (working out the right interactions and interrelations between bugs and their request bugs) and in terms of user interaction (giving users the right affordances for creating and manipulating requests). I won't argue that my second implementation of requests is particularly elegant, but I do think it's much better than the first. I thought that bugs were an appropriate model for requests because requests are similar to bugs in that they have a state, a reporter, and an assignee, but what I had failed to realize is that bugs have a bunch of other heavy machinery that isn't relevant to requests but would have to accommodate them, both in the code and in the user interface. I haven't read the two bugs well enough to say if this situation is similar, but based on my experience with requests, I would be very cautious about reusing bugs to represent the states of other bugs.
(In reply to comment #11) > I haven't read the two bugs well enough to say if this situation is similar, > but based on my experience with requests, I would be very cautious about > reusing bugs to represent the states of other bugs. I think this particular situation maps much more sensibly to bugs than the requests system did. This bug requests multiple status and resolution values for a single bug. Once we have that, people will also want multiple target milestones. (Perhaps not here, in this Bugzilla, but for many products people will want to say when different branches will be fixed.) Once you have that, some projects will want to have different assignees for different branches (a fairly common occurrence in corporate environments where there's a separate maintenance team). Some installations want the ability to say that one bug affects multiple products, each of which has various branches and different assignees. Sometimes the priority of one branch will be high, to fix, but the priority of another will be low. Then people will want to be able to do reporting on all of these things. Pretty much everything I mentioned above was the actual case scenario at the client for whom I wrote the specification in bug 55970--they implemented a limited feature like this bug requests, and the scope just crept and crept, until it became so unwieldy that they could no longer afford to maintain the solution. The bug-based solution satisfies all of the requirements of various organizations, whereas this is a limited stopgap that would involve a rather invasive architectural change to Bugzilla.
If bug 55790 will be ergonomic enough in group editing of all related bugs -- who would notice the difference? ;-)
(In reply to comment #13) > If bug 55790 Sorry bug 55970 of course
Can we instead morph this into a BMO-only bug if this is, indeed, what Mozilla wants? :) Personally, from the description of how bug 55970 works, I think it's much more complicated than what this bug offers. I'd much rather see this bug implemented than bug 55970.
Dan, is this kind of what you had in mind (ignore the excessive whitespace at the bottom and the lack of good JS in general)? http://people.mozilla.com/~ss/336790/ If so, I'd propose we implement this for BMO. As part of it, we'd want a "Status Versions" part of the Administration section similar to Keywords and only allow certain people to add new versions to it. It could be auto-completed if people desire (personally, I hate autocomplete, but that's a story for another day). Likewise, we'd probably want to add the ability to remove versions from a bug (which isn't part of my mockup). Adding new statuses/resolutions to a bug should be limited to people with editbugs. I specifically did *not* include blocking flags in this because I don't think it makes sense. In that case, you'd have to list all versions (or the most recent ones) and have blocking flags for each of them. This doesn't scale well, imo. It also makes the entire thing messy. We can add the "branch" in addition (so that "Mozilla 1.8.1.21" becomes the "target milestone") and move those fields up, if that's the desired outcome as well. Doing that would mean a *bunch* of new target milestones though, which might be fine, but we should consider it. I'll keep working in this closed bug for now, but ultimately I think it should be a BMO-only bug. Thoughts?
You know there's already a multi-select Fixed In field for bugs on bmo, with its own per-product value list, yeah? I understand it would be useful to mark some branches as WONTFIX or WORKSFORME, but is it important enough to justify the cost involved in performing this as a customization? This would be a big thing, not just some tiny change, and since we wouldn't be doing it upstream, you'd have to maintain it forever (including forward-porting it to future versions) if you kept wanting Bugzilla to work this way.
(In reply to comment #17) > You know there's already a multi-select Fixed In field for bugs on bmo, with > its own per-product value list, yeah? Does it support VERIFIED? It's *incredibly* important for branch bugs (for maintenance releases) to show if a bug has been verified or if it's simply landed. Is the Fixed In field searchable? I did not know, mostly because it's not exposed anywhere (unless I'm missing something; but I'm not an admin).
(In reply to comment #17) > I understand it would be useful to mark some branches as WONTFIX or WORKSFORME, > but is it important enough to justify the cost ... [snip] Err... and maybe. Is it important to say that security bug is WORKSFORME on the trunk, but still clearly an issue on the current release branch? If a developer sees "WORKSFORME" they immediately move on. We've often lost bugs this way because we haven't paid close attention to if they are applicable on a branch. Then, old security bugs sit unfixed in the releases that hackers are attacking. Does it justify the cost? I'm sure that's debatable. Is it important? Yes. We've been using the whiteboard for this for years with varying results, often negative ones.
How do you plan to make bugs with multi-status and resolutions searchable? How are they supposed to be displayed in buglist.cgi? The "one bug per branch" alternative is not affected by these problems. Also, we could imagine that one bug would display other branch bugs status and resolution as you did in your mockup, to have a good overview of the issue. And the status/resolution table at the top of the page (which looks nice; I like it) would have an additional column "bug ID" with a link pointing to the other branch bug. This way, you can easily go from one branch to the other one, without having to maintain this bmo-only hack forever. I still think bug 55970 is the right way to go.
(In reply to comment #20) > How do you plan to make bugs with multi-status and resolutions searchable? How > are they supposed to be displayed in buglist.cgi? Add a field for it? "Status version" or whatever it's called in the long run. > The "one bug per branch" alternative is not affected by these problems. No, it's affected by different problems. The idea that I, as a branch driver, have to open up to three other bugs to find out the various details of how to implement a patch on the current branch I'm working on is very frustrating. Unless you're syncing comments between all bugs across branches (which I highly doubt you are for other reasons), I have to check in every bug to make sure some implementation detail isn't missed -- some regression, dependency, or blocking bug that's not linked properly in the current bug, which happens all the time. I also want to know exactly how we got to the patch. If it took 20 patches to get from a WIP to a final patch, that's important to me when we take the branch patch since it means that fixing this bug was a harder-than-usual process. Why? I need that context. And I especially want to be able to easily compare the patch that landed on trunk to the ported patch to my branch. Size-wise, is it the same? What's different? Having all the attachments on one page saves time. Are you syncing attachments in addition to comments? Some developer's going to ask me what bug they're actually working in if there are four different ones for on actual issue... It also becomes confusing in other cases... Say bug 1 is fixed on the trunk and we want to take it on the 1.9.1 branch. Bug 1 has two dependencies: bug 2 and bug 3. In your scenario, I create bug 4 (which is linked to in bug 1) and create two dependencies for bug 4 (bug 5 and bug 6, which are linked to in bug 2 and bug 3, respectively). But, when porting, we determine that bug 2 (nay, bug 5) doesn't need to be ported to the 1.9.1 branch because it's not the sort of dependency that actually needs to get ported for bug 1 (nay, bug 4) to be fixed on the 1.9.1 branch. Are you confused yet? I am... I want to be able to look at bug 1 and check its dependencies (bug 2 and bug 3) and immediately know if we need them on the 1.9.1 branch. In my world, we can distinguish that by specifically stating their status (bug 2 would be RESOLVED WONTFIX and bug 3 would be NEW/ASSIGNED for 1.9.1) for all applicable branches. Maybe you can show status/resolution in bug 2 from bug 5 (as you say later). That still doesn't fully help me with the context needed for porting any of the patches (as I said above) or how we determined the status/resolution decided on. Finally, having multiple bugs for each branch can be confusing for developers as well. In some (maybe 20% of the time?) cases, a patch applies across trunk, 1.9.1, 1.9.0, 1.8.1, and 1.8.0 because the underlying code is just that old. We would have to create four new bugs in your scenario and attach four of the same patch to each of them to track them properly. That's just busy work that no one wants to do. > the status/resolution table at the top of the page (which looks nice; I like > it) I'm glad we agree on that. :) I'm sure it can use some improvements, though. My design skills aren't as l33t as I'd like. ;)
Re-reading the spec... "You should be able to read the comments from any sighting by simply clicking a link on the sighting. The comments will be displayed without going to a new page (they will be pulled from Bugzilla via AJAX or some method and displayed right there)." This can't possibly be good UI-wise. Either the frame you display it in will be too small or awkward, or I'll care about how things fit in together throughout the timeline and you'll put them all inline. But then, what's comment 1? And when I comment, where is it going? Mixing comments from one bug into another is confusing so I doubt you'll go that route. Displaying it in a frame is awkward and doesn't give me a good, time-based way to see exactly what's happening with this bug/patch (across all branches). And in the case where submitting a comment submits it across all "sightings" (btw, if this *is* going to get implemented, it probably needs a better name; the concept I get but the name is weird to say... I've been trying to think of better ones), some other products might not care and might actually be annoyed. A Camino implementation of some obscure cert UI will likely be different than a Firefox one, but you want the bugs as sightings since they're really the same bug, right? In any case, you're treating "sightings" as their own bugs sometimes, but not others, which ends up being confusing overall. It'll be unclear to people if they're commenting in one bug or ten. People following one of the sightings of a root cause might not know changes are taking place in another sighting. On the reverse side, sending comments to all of them might annoy a lot of users who only care about one of the sightings but not the others. The whole system reads confusing and awkward. We need something simple and basic, even if we have to maintain it on our own (which, fwiw, I agree isn't ideal).
Please discuss any problems with sightings in the sightings bug, not this one. (In reply to comment #21) > The idea that I, as a branch driver, > have to open up to three other bugs to find out the various details of how to > implement a patch on the current branch I'm working on is very frustrating. You don't. You should read the spec, or at least see a UI mockup (which we don't have yet). There must be some very good reason why the primary Bugzilla developers, who have a lot of experience with bug-tracking across many different organizations, would think it was a better idea than this bug. > Unless you're syncing comments between all bugs across branches (which I highly > doubt you are for other reasons), I was considering implementing it that way. > In my world, we can distinguish that by specifically stating their status (bug > 2 would be RESOLVED WONTFIX and bug 3 would be NEW/ASSIGNED for 1.9.1) for all > applicable branches. The same thing works with the bug-based solution. Anyhow, what if you had a dependency on one bug for a particular branch but not for another branch? This thing doesn't cover that. > Finally, having multiple bugs for each branch can be confusing for developers > as well. I really don't see why. For the most part, people will probably never open or see the child bugs, unless they're doing something very particular with the branch. And anyhow, all related bugs show up on every bug. Children show up on the master, and the master and all its children show up on the children. > We > would have to create four new bugs in your scenario and attach four of the same > patch to each of them to track them properly. Or just do all the work on the master bug, which is a completely valid option. What we are discussing is IMPLEMENTATION, not UI or use. If we used the bug-based solution and only exposed the statuses in the sightings UI, it would work nearly-identically to the solution discussed in this bug. We could *always* hide the child bugs, and then you wouldn't even know how it was implemented, other than that there would seem to be holes in bug numbering. What you want is achievable with the sightings implementation. What Bugzilla as a product needs in general is *not* achievable with this status/resolution implementation. So, you can go with the status/resolution thing and maintain it forever as a customization (and a strange one at that, since there are all sorts of integration pieces, APIs, and features that expect bugs to have only one status or resolution), or you can go with the sightings implementation and customize its UI if you need it to work in some limited way, which would be a much simpler customization.
No longer blocks: bz-branch
You need to log in before you can comment on or make changes to this bug.