Closed Bug 55970 (bz-branch) Opened 24 years ago Closed 8 years ago

Bugzilla needs to deal better with branches (implement sightings)

Categories

(Bugzilla :: Creating/Changing Bugs, enhancement)

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

Tracking

()

Status:
RESOLVED WONTFIX

People

(Reporter: braden, Unassigned)

References

(Depends on 1 open bug, Blocks 1 open bug,
URL
)

Details

(Keywords: meta, Whiteboard: [roadmap: 4.0][see comments 18-19 for proposed implementation])

Attachments

(6 files)

Specification
6.88 KB, text/plain
LpSolit
: review+
Details
WIP, v0.1
15.71 KB, patch
Details | Diff | Splinter Review
General Plan of Action
38.22 KB, application/pdf
Details
Suggested Different Plan of Action
33.17 KB, application/vnd.oasis.opendocument.text
Details
General Plan of Action, as text
5.61 KB, text/plain
Details
Initial sightings design doc.
114.54 KB, application/pdf
Details
As Mozilla "branches out", bugs may occur only on a particular branch (for instance, bug 55695). Bug reports need a way to consistently identify the branch the bug appears on.
Sounds like the purpose of version to me.
Target Milestone: --- → Future
I feel we really need something like this, but not just for comments but for almost everything. When 0.9.4 branch will be cut, Netscape alone will probably work on 0.9.2, 0.9.4 and trunk simultaneously. We need a way to identify the branches were a bug appears, when it was fixed on what branch, when it was verified on what branch and so on. Priorities, keywords, status whiteboard messages etc. may apply to the bug on just some branches, not all. We can also have temporary developer branches (like we have these branches for big and scary landings to shake out the bugs first on the branch), so Bugzilla should either let someone easily create branches or take them automatically from CVS. Version is not exactly a branch, but maybe it could be used to help implement this. Currently we are trying to manage this with keywords and special comments in the summary and status whiteboard which is confusing to say the least.
->New product Bugzilla
Assignee: tara → justdave
I mean it this time! (sorry for spam)
Component: Bugzilla → Bugzilla-General
Product: Webtools → Bugzilla
Version: other → unspecified
*** Bug 99418 has been marked as a duplicate of this bug. ***
How feasible is this feature to develop? As we work on more and more branches/trunk, there may be different open/resolve/verify status for each branch vs. trunk. In addition, there may be different QA contacts or developers for them (ie. Netscape, IBM, mozilla.org may prioritize looking at one branch over another, etc). Currently, we use keyword mechanisms. While that is a temporary solution and is working ok right now, it doesn't cover a lot of fields (milestone, qa, eng, etc). Of course, one option is to file separate bugs for branches, but that involves a lot of duplicate work. I hope Jud won't mind, but to quote him: "no keywords and no multiple bugs for this. we basically need the ability to "view" a bug in the context of a given branch. does this bug exist on branchX, has it been fixed/verified on said branch...etc" Thanks.
Misc thoughts (I had a bit more detail, but lost my comment when the power went out here. Besides, this is what brainstoring is for, right? :-) : If we're staring to talk about different qa contacts, then I really think that a separate bug is the way to go. In theory, the custom fields stuff may allow 'list of bug #s' as one of its options. Thats unliukly to be in the first round, though. Why can't you just use the version field to handle 'reported with build X' ? I know that bmo only has one version field, but theres no reason that you couldn't add '1.0branch' to the list. What is wrong with the keywords? bug flags should allow the nsbeta1/nsbeta1-/nsbeta1+ stuff to happen more smoothly, anyway. You could abuse the flags to make -==occurs, ?==fixed, +==verified, or something, although I'm not too sure how well that will scale, esp from a UI persepective. I don't really think we want to clone everything, since usually the same (or slightly similar) patch gets applied to all the appropriate branches anyway, so all the discussion on what the problem is, how the fix works, and so on is the same, as are (usually) the dependancies, url, and so on. custstatus may give us RESOLVED->RESOLVED-1.0-BRANCH, but thats not happening in the near future, and I don't know if even that would be flexable enough
See comment 2 and comment 6 in this bug. Any ideas, guys? Need some brainstorming. With all the fields that are being asked to keep separate, I'm starting to think separate bugs for each branch may actually be the best way... HOWEVER, we might be able to come up with a creative UI to link them together (sorta like how dependencies are done now, but specifically for the same bug on different branches) where you have a list of branches affected at the top of the bug (with an Add Branch link which would essentially clone the bug and let you set the new branch tag) and clicking on a branch name takes you to that bug. We might be able to make them a "pool" rather than a "parent-child" relationship, so that the same list of branches would show up at the top of all of the branched bugs, though I'm not quite sure how you'd implement that. We'd probably want the status/resolution of the linked bug by each branch link.
This is partly the "version should be a multi-select element" point, but it's also the general question of how you can cope with different sites' arbitrarily complex branch rules. I've been having some thoughts on this recently; I'll write them up when I get back from church. Gerv
(My comment comes before justdaves, but after gerv's - see bug 176979)
It's true that version is the best way to indicate which version(s) a bug appears in, and making it a multi-select field would help. But we need to continue to be careful of adding complexity to the show_bug UI over and above that, if it can possibly be avoided. But I think that the best way to satisfy this general sort of request would be a "clone bug" feature. The UI would be that you click a "Clone Bug" link, and it brings up an enter_bug page with all the fields pre-filled, and an extra check-box: [X] Associate with bug 123456 Here, within the limits of the enter_bug page (yes, yes, I know :-) you could alter any fields that were different for this copy of the bug, and then file it. You could clear the checkbox if you were cloning merely for convenience rather than association. Back on either bug, the UI would be as a set of tabs at the top of the bug, each of which was a hyperlink to the different associated bugs, using GetBugLink, so it had a title of the resolution etc. info. (We'd have to think about how to get version information into this.) If we get it right, this tab line would give you a quick overview of the status of the different related bugs. This mechanism is good because it allows the cloning of bugs for _any_ purpose, and the decision about when to clone and when to use the same bug can be a site-specific policy. And it could compensate for single-valued version fields while that's still a problem. It also means that the cloning could happen late in the process; you discuss the fix and develop the patch in the same bug (an important component of any solution), and then clone it to track the checkin on e.g. a branch where there are checkin hoops to jump through. Basically, this is a third bug relationship (along with dependson and blocks), but with a different, and appropriate, UI. There is a bug open on cloning, and there's been discussion in it recently - bug 81642. Gerv
*brainstorm* It's a bit of a problem that Bugzilla wasn't designed to support multiple "views" of the same bug. The scenario that is pointed out is quite common: the same bug occurs in slightly different form in more than one version of the code out there; how do we handle it. I initially thought that Version being MULTIPLE would solve things, but now that I see that we need different parameters for each of the versions. Gerv's proposal sounds acceptable, but the UI for this could get us in the hall of shame if we are not very careful when doing it. How common would the cloned bug that has different variables actually be? Is this a corner-corner-case or is it an everyday issue for Mozilla?
The cloning of a bug could be a good idea. However, would this make it so that one dev owner may then have two or more bugs on the same thing assigned to him/her? And, if the bug gets cloned early enough, would there be a way to update comments on one main bug and have it copy over to the "cloned" bug? (There may be times when a bug needs to be cloned early enough. For example, two different dev or qa owners. And, then someone else wants to make the same comment and it applies to both - or more - cloned bugs.) To answer the question: "How common would the cloned bug that has different variables actually be? Is this a corner-corner-case or is it an everyday issue for Mozilla?" From my point of view, this could be a common case as many companies and mozilla.org have varying priorities. For example, in bug 176140, it's been mentioned that Ian Hickson wants to be the default QA contact for some modules, but he's stated that his focus is on the trunk. Companies that ship products off the branch would like to be able to track some of these trunk bugs which are fixed and then pulled into the branch. I would prefer that the branch bug have a different QA contact.
Reassigning all of my "future" targetted bugs to indicate that I'm not presently working on them, and someone else could feel free to work on them. (sorry for the spam if you got this twice, it didn't take right the first time)
Assignee: justdave → nobody
QA Contact: mattyt-bugzilla → default-qa
Target Milestone: Future → ---
I'm morphing this bug, the oldest "branch" request, into our general tracking bug for "branch" issues.
Alias: bz-branch
Assignee: nobody → general
Keywords: meta
Priority: P3 → P1
Summary: Bug reports need a field to identify the branch they appear on → Bugzilla needs to deal better with branches
Whiteboard: [roadmap: 3.2]
Target Milestone: --- → Bugzilla 3.2
Depends on: 79964
Depends on: 336790
Whiteboard: [roadmap: 3.2] → [roadmap: 4.0]
Target Milestone: Bugzilla 3.2 → Bugzilla 4.0
Assignee: general → mkanat
Okay, LpSolit and I seem to have a consensus on a way to fix this that would be very "Bugzilla-like" and still fit the needs of all the users that I have spoken to and who have spoken here. The basic idea is that each "branch" gets its own bug, but each bug in the list shows information about every other one in a simple table on that bug. That is, every bug shows the current status, resolution, assignee, version, target_milestone, severity, and priority of the other bugs. Each bug can access the comments of the other bug by clicking on a + (or something) which expands them. Instead of this implementation, the other option (that LpSolit and I originally discussed) instead of making it a many-many relationship is to make it a parent-child relationship, where one bug is the "master" bug and shows information about all its children, and the children only have a link that allows them to view the comments of the parent bug. As far as how new bugs would be filed and new branches would be added, there's a few possibilities: 1) Add an "Affected Branches" field to bugs, which is hidden if there are no values for that product. If somebody selects more than one Branch on filing the bug, more than one bug is filed, and they are all set up in this relationship. On entering the bug they all use the same Description. On show_bug somebody can select an additional branch and then select which comment should be used as the description of the new bug. The summary is always the same between the bugs (at least initially). 2) Instead of "Affected Branches", the user can click a button which gives them a whole new area where they can choose the Product and Version affected. 3) The user can select multiple versions and that automatically files the new bugs, without the Branch concept. (I'm against this one.) I think right now I'm most in favor of #2. I have a client who will actually want this feature implemented directly for them as a customization, so I think that will be a really good proving ground for this, and also a great way to get detailed feedback from an organization that isn't Mozilla. I'll also point a few other organizations at this bug and find out if this would serve their needs.
Attached file Specification —
Okay, here's a basic spec for how the branch problem will be solved. I welcome comments from other Bugzilla developers. Comments on how well this will meet requirements are welcome from non-Bugzilla-developers. However, comments on the implementation details are not welcome from non-Bugzilla-developers. I expect that the things written in this spec will be implemented in stages. That is, it will not all be one big patch on this bug.
Comment on attachment 304328 [details] Specification I like it and matches what we discussed a few months ago. The implementation and UI are going to give us some headache though, I suppose. But that's why coding is so much fun. :) r+'ing it to say I agree with this spec.
Attachment #304328 - Flags: review+
I like the thinking here. However, a few points need clarifying: - Exactly which fields can vary between sightings? Any field at all? Or are some held constant? - The "sighting" terminology is actually quite good. Do you have better terminology? "Also affected" seems looser than it should be. I'm not sure about "root cause" though. Would "master bug" be more generic? - Why is it important to allow the identity of the "root cause" bug to change between bugs in a set? - I'm not sure how the edit UI would work without getting very complex. Do you have screenshots of an existing implementation, or an HTML/graphic mockup? - How would it ever make sense to add a sighting when filing a new bug? Surely, by definition, a sighting is related to an already existing bug, not a new bug? Gerv
(In reply to comment #21) > - Exactly which fields can vary between sightings? Any field at all? Or are > some held constant? Any field can vary--they're all individual bugs. However, in the sightings table at the top of the bug, only certain fields would be displayed for change. > - The "sighting" terminology is actually quite good. Do you have better > terminology? "Also affected" seems looser than it should be. I'm not sure about > "root cause" though. Would "master bug" be more generic? I don't really have any better terminology, and "sighting" has been working well at the client who I wrote this for, for many years, as a local customization. I prefer "root cause" as more explicit than "master bug", which I think would be too vague. > - Why is it important to allow the identity of the "root cause" bug to change > between bugs in a set? For the same reason that sometimes we dup a bug to a later-filed bug. Similar situations could happen with sightings. > - I'm not sure how the edit UI would work without getting very complex. Do you > have screenshots of an existing implementation, or an HTML/graphic mockup? I do, but they aren't under my copyright as of this time. Also, they don't represent what I have in mind for upstrmam Bugzilla. Imagine an expandable version of the Launchpad "also affects" table that had a few editable fields in it. > - How would it ever make sense to add a sighting when filing a new bug? Surely, > by definition, a sighting is related to an already existing bug, not a new bug? Yes, it might not make sense to add one during bug filing at all. The original spec actually said "You cannot add a sighting while filing a bug." That's something that we could wait and see how people use it and if there would be something useful to add on the enter_bug page.
(In reply to comment #22) > I prefer "root cause" as more explicit than "master bug", which I think I prefer "master bug" than "root cause". I even prefer "meta bug" than "root cause". > > - Why is it important to allow the identity of the "root cause" bug to change > > between bugs in a set? > > For the same reason that sometimes we dup a bug to a later-filed bug. Similar > situations could happen with sightings. I'm not so sure. If the "master bug" is a dupe, then all its "children" are as well. I don't think one of them would become the master bug. At least that's not something I would implement without good examples of this happening.
(In reply to comment #23) > I prefer "master bug" than "root cause". I even prefer "meta bug" than "root > cause". Hrm. Perhaps you're thinking more like a long-term bmo user than a typical bug-tracking-system user. I think "root cause" makes the purpose of the system much clearer. You can't make everything generic, or people won't know which features to use for what. That leads to questions in IRC where people go, "Well, I'm doing X to accomplish Y..." and we go, "You're doing X?!?!?!?" We are first and foremost a software bug tracker. For more on what I'm talking about, search for the word "generic" in this blog: http://www.codesimplicity.com/archives/12 > I'm not so sure. If the "master bug" is a dupe, then all its "children" are as > well. I don't think one of them would become the master bug. At least that's > not something I would implement without good examples of this happening. I wasn't talking about duping anything. I was making an analogy. I mean that sometimes you decide that the root cause is a new bug, and that an old bug is the sighting.
I don't particularily like the term "root cause" either. We use that term in our company to explain why the bug happened. It is not a bug in itself but it can be part of the bug report. Typically when we file a bug resolution report to a customer it would include the symptoms, the reason it happened (i.e. the "root cause"), and what we did to fix it. Maybe the term "root bug" would be better.
+1 for root bug, not only because I like it more and I agree with Stephen about the possible confusion about "root cause" as the reason, but also because it could be combined with the possibility of Bugzilla to change the main word for describing "bugs". For example in my installation I use "ticket" instead of bug, and hence the final word would be "root ticket", which also makes sense IMO.
Hrm, okay. I'll poll the developers list as to whether they prefer "root bug" or "master bug".
who cares what you call it, so long as you put it into global/variables.none.tmpl! I think that "initial [% terms.bug %]" would be best for me. We already do this, by cloning issues and duplicating the alias field. So however it happens is a good way, since I won't need to again duplicate all the changes I made into yet another version of bugzilla. :-)
I agree that a more-specific term is better. I like "root bug", but putting it in a template is a great suggestion. In our organization, what this really boils down to is "the bug with all the gory details in it". This may be the one that was found on the trunk or the one that was found on the branch, but it's almost always the one that was entered first, and rarely (maybe never) changes. QA will rarely if ever need to enter additional "sightings" when creating the original bug. But we sometimes have developers entering bugs like this on their own, and they know at bug entry time that the bug affects multiple branches. That said, it doesn't seem particularly onerous to me to create the additional sightings after the first bug has been filed. A potentially related use case: we have some "perennial" bugs that apply to every release. (For example, we have a bug that reminds us to upgrade to the latest version of Java each release.) Would it make sense to create a new "sighting" bug for each release?
(In reply to comment #29) > A potentially related use case: we have some "perennial" bugs that apply to > every release. (For example, we have a bug that reminds us to upgrade to the > latest version of Java each release.) Would it make sense to create a new > "sighting" bug for each release? That's an interesting question, and really I have no idea. It depends how you want it to show up in the search. If you never close the master bug, this is probably fine. Otherwise, if you limit your searches to just master bugs, you'll always only get the master bug. If that's what you want, then you're probably fine. This does make me realize that we should definitely have open sightings sort to the top.
Blocks: bz-majorarch
From my experience, this is going to lead to disaster. We already run into this with bugs that have dependencies, where the conversation about the issue ends up fractured between various bugs. Additionally, no matter what product or version I'm looking to fix a bug in, the patches and conversation about the original fix will be very relevant. If we could somehow make it so that bug B which is a sighting of bug A acted like a soft file link, with comments and references all being synchronized between them, that would be great. In everything except for the independent state of the resolution flag, this feels like just saying B is a dupe of A, and this feels like a much heavier solution than just allowing for there to be some metadata in bug A about the various states of resolution in other products & branches.
I think I agree with beltzner here. Can we get a real mockup of what this is supposed to look like, before we say this is right or not? We should start with interaction, and then solve the backend pieces, IMO.
(In reply to comment #33) > I think I agree with beltzner here. Can we get a real mockup of what this is > supposed to look like, before we say this is right or not? We should start > with interaction, and then solve the backend pieces, IMO. Sure, I'd love to have that. Whenever somebody works on this, it would be nice to have a UI mockup if we can get it.
Some of us in mozilla development are trying to put together some use cases for what we want with bugzilla branch support. Feel free to add your thoughts and comments here, and use this wiki as a tracking ground: https://wiki.mozilla.org/QA/BugzillaBranchUseCases
Now that we are mostly done with $bug->update, could we revive this bug, please? I think that, together with the implementation of $bug->set_all(), they are (or should be) the main project for 3.8.
Component: Bugzilla-General → Creating/Changing Bugs
Whiteboard: [roadmap: 4.0] → [roadmap: 4.0][see comments 18-19 for proposed implementation]
Target Milestone: Bugzilla 4.0 → Bugzilla 3.8
I just had a discussion with mkanat on IRC about some implementation aspects, and we agreed that: - when you comment on a bug, you have a checkbox or radio button above/below the "Additional Comments" box to make your comment visible in all sightings, or the current sighting only. The master bug would always display all comments of all sightings, independently of this checkbox. - from an implementation point of view, when you comment on a bug, the comment is stored in this bug (from a DB point of view), but other sightings would see all "public" comments from all sightings (as defined above), thanks to Bugzilla::Comment->match({bug_ids => ...sighting IDs...}) in $bug->comments. - the same UI and backend implementation would apply to attachments: stored in the bug the file is attached, but visible by other sightings thanks to Bugzilla::Attachment->match(...). The goal is obviously to not duplicate data in the DB. Now my personal feeling about how to display comments in the master bug and sightings: - we could use a different background color (as we do with private comments), e.g. light yellow to indicate that such or such comment is for a specific sighting only. Comments with the usual background color would be those which are visible from the master bug and all sightings. About buglists: - I think the master bug should be displayed in buglists when one of its sightings matches the query, as proposed in the specification, but the matching sighting (or even all sightings) should be displayed right below it, slightly indented to the right and with a distinct color (and eventually in italic) so that the user understands why the master bug is displayed (else you may wonder why it's listed here despite it doesn't match your query). This way, you don't need extra columns nor any special action to display sighting-specific metadata. I will try to attach a mockup or two when I have some free time, probably next week.
Depends on: bz-bug-set-all
No longer depends on: 79964, 336790
As you know, Mozilla is an organization which is crying out for better support for branches. However, two major, senior and long-standing Mozilla contributors have suggested that the current implementation would be "a disaster". Since they said that, has their feedback been taken into account, and further opinions sought from them, or are you ploughing on regardless? I recently wrote on LpSolit's blog that: "I think some of the frustration in the Mozilla community is caused, rightly or wrongly, by the perception that the Bugzilla team isn’t listening to their needs, doesn’t implement the features they (as a large software engineering organization and a heavy user of Bugzilla) are looking for, but does implement features that are entirely useless to them." http://lpsolit.wordpress.com/2010/02/11/who-is-fixing-bugzilla-bugs-these-days-part2/ Is this going to turn into another of those? I really hope not, because I'm sure it's going to be a lot of effort, and I would love for it not to be wasted. Tony Chung (in comment 35) has tried to do some use case work to help you guys understand the Mozilla position better, although that appears to have stalled. We can certainly get it going again if it would help. Gerv
(In reply to comment #40) > However, two major, senior and long-standing Mozilla contributors > have suggested that the current implementation would be "a disaster". Since > they said that, has their feedback been taken into account, and further > opinions sought from them, or are you ploughing on regardless? It seems you didn't read my comment 39, or didn't understand it. beltzner and mconnor's questions are answered there. I repeat again below. > by the perception that the Bugzilla team isn’t listening to their > needs, doesn’t implement the features they [...] are looking for, but does implement > features that are entirely useless to them." I'm not going to debate this here, and I think your comment is inappropriate in a bug comment. If you want to know what I think about this, email me or ask me on IRC. (In reply to comment #32) > We already run into this with bugs that have dependencies, where the > conversation about the issue ends up fractured between various bugs. As I said in comment 39, *all* comments from *all* sightings are *all* displayed in the master bug. Moreover, without an explicit action from the commenter, *all* comments are also visible from *all* other sightings. I still want the commenter to be able to not share his comment with other sightings when his comment is really specific to a single branch, and where his comment would spam other sightings with no benefit. But even if he does this, the master bug would still display it. So there is no risk to split the conversation between bugs. > Additionally, no matter what product or version I'm looking to fix a bug in, > the patches and conversation about the original fix will be very relevant. Here again, I explained in comment 39 that attachments, including patches (and consequently reviews tighted to them), would be shared with other sightings too. > If we could somehow make it so that bug B which is a sighting of bug A acted > like a soft file link, with comments and references all being synchronized > between them, that would be great. That's what my implementation in comment 39 suggests! In everything except for the independent > state of the resolution flag, this feels like just saying B is a dupe of A, and > this feels like a much heavier solution than just allowing for there to be some > metadata in bug A about the various states of resolution in other products & > branches. No. As some comments indicate (e.g. comment 2 and comment 6), there are more things than just the status and resolution which may differ per branch (e.g. the assignee and QA contact, who may be responsible for only a subset of branches). So bug 336790 may be enough for Mozilla, but not necessarily enough for all companies using Bugzilla. And even for Mozilla, not only would the status and resolution be different between branches, but also flags, the target milestone, and why not the priority of the bug (following what I saw in older releases, with P1 meaning "blocks the next release", etc..., a bug could be P1 for a stable branch, but P2 or P3 for the trunk because you are in alpha stage and the bug is not so urgent here). (In reply to comment #33) > Can we get a real mockup of what this is > supposed to look like, before we say this is right or not? That's the last sentence of my comment 39. Am I totally blind and deaf and you still have the impression that we don't listen, or do you finally have the feeling that we do listen (in reply to your comment in comment 40 and on my blog)?
Frédéric: you are right, I didn't read comment #39 carefully. But I get the impression that mconnor and beltzner's comments are not the sum total of their views on the subject, and I suspect other Mozilla people have views too. So answering their points in a couple of bug comments isn't the end of the matter. As you know, the correct UI for this is a matter of some debate! If resources are now available to work on this, I really think we need to start with requirements gathering. I am happy to help do that in the Mozilla community if that would help. I apologise if my comment was inappropriate; but I am honestly only reflecting what I hear regularly when I hear senior Mozilla people comment about the Bugzilla development process. I am not saying that all the fault is on the Bugzilla community side, by any means, but I do think we have not yet got to the right place in terms of seeking sufficient customer input ("listening") on the design of major new features like this one. Gerv
Gerv: If "senior Mozilla people" (who specifically?) have comments on the Bugzilla development process (what specifically from who specifically?) then I'd have to imagine that if they're senior, they also have the power to work with us to put actual resources toward solving the problem, which the Mozilla Corporation hasn't ever done--at least in the six years that I've been working on Bugzilla. The services that Mozilla does provide (hosting and legal support) are very appreciated, but there is no development support provided whatsoever. If Bugzilla were important to me as an organization, then I would put some actual development resources (people or funding) toward it instead of just discussions or suggestions. I think that's part of the fundamental basis of open source--that you *can* put resources toward a project's feature set if that feature set is important to you.
(In reply to comment #43) > Gerv: If "senior Mozilla people" (who specifically?) Pretty much everyone called Mike (shaver, connor, beltzner) and some other people too. You can't throw a brick in the Mozilla world without hitting someone with strong opinions about Bugzilla. Jesse, Gavin, johnath, ... > have comments on the > Bugzilla development process (what specifically from who specifically?) I don't think they have strong opinions about _how_ you develop (the process) so much as _what_. :-) > then > I'd have to imagine that if they're senior, they also have the power to work > with us to put actual resources toward solving the problem, which the Mozilla > Corporation hasn't ever done--at least in the six years that I've been working > on Bugzilla. As I said above, and in the blog post on Frederic's blog, I am not placing all the blame solely in one place. To be honest, I don't know why the dissatisfaction with Bugzilla has not resulted in MoCo hiring someone - but, for whatever reason, it hasn't. And we have to work with what we have. > If Bugzilla were important to me as an organization, then I would put some > actual development resources (people or funding) toward it instead of just > discussions or suggestions. I think that's unfair. True, no-one at MoCo has the job "Bugzilla hacker". But at MoFo, we've been working hard with you to try and put together a sustainability and fundraising plan for Mozilla (regarding which, the ball has been in your court for a couple of months now...) and I personally have spent at least a man-month of hacking time designing and doing a test implementation of the sort of API for Bugzilla that people will actually _use_. (And they are.) > I think that's part of the fundamental basis of > open source--that you *can* put resources toward a project's feature set if > that feature set is important to you. I agree. But if an organization which is a heavy user of your product doesn't choose to do that, for whatever reason, I still think that it's reasonable to give them a voice in your development process commensurate with that usage. In other words, I am not saying that you should give Mozilla's input _more_ weight than another randomly-chosen Bugzilla-using organization who has been using the product for 10 years, has a database of 500,000 bugs and 30,000 active users, but I think you should give it at least as much weight as that. Even if you think they should be helping out more and they aren't, and you're annoyed about it. Gerv
(In reply to comment #44) > Pretty much everyone called Mike (shaver, connor, beltzner) and some other > people too. You can't throw a brick in the Mozilla world without hitting > someone with strong opinions about Bugzilla. Jesse, Gavin, johnath, ... Okay. In that case, I'd like them to individually come to us in some way or another (not on this bug, which is not an advocacy location) and explain their personal viewpoints. I saw johnath's video, for example, and it was helpful. If any of them would like to have meetings with me individually, then I'd be happy to take their feedback in person, in Mountain View, if/when they are around. > I still think that it's reasonable to give them a voice in your development > process commensurate with that usage. [snip] I do, and it's feedback that's very important to me, and that I always consider in the appropriate context along with the larger Bugzilla community.
Just in case you are wondering, I started working on this bug today.
FWIW, I have some ideas about this if you are interested in them. I'll try to find time to jot them down. I haven't interacted with Bugzilla too much but I managed many bugs with assorted release branches previously at Apple and am extremely familiar with Radar (their bug tracker). I could give you a different perspective as a new Mozilla release driver, new bugzilla user, and experienced Apple release driver with tons of Radar experience. Shoot me an email if interested.
(In reply to comment #47) > Shoot me an email if interested. Of course we are interested. But better is to comment in this bug.
As I said yesterday, I started working on this bug. For now, I only played with comments and attachments, which are shared between all sightings and the master bug. I also added a "New Sighting" link at the bottom right of the page, besides "Clone this bug", to create a new sighting. See https://landfill.bugzilla.org/bug55970/show_bug.cgi?id=11575 for an example on how it looks like for now. Keep in mind that I don't care about making things pretty for now. And I intentionally keep some debug code for clarification while implementing it. Initial feedback welcome!
URL: https://landfill.bugzilla.org/bug5597...
(In reply to comment #49) > Initial feedback welcome! I like it. I'd like to request/suggest that installs with target_milestone turned on may also want to focus on the "Fixing" in branches as much as the "Reporting" against branches functionality. Of course once you get the bugs tied together it should be easy enough to customize, so long as you code it that way. :-)
(In reply to comment #50) > I like it. I'd like to request/suggest that installs with target_milestone > turned on may also want to focus on the "Fixing" in branches as much as the > "Reporting" against branches functionality. Part of this is to take an existing bug, and instead of adding a 'Sighting', add another branch to deliver the fix in.
Assignee: mkanat → LpSolit
Attached patch WIP, v0.1 — — Splinter Review
Here is the very initial patch I wrote to implement sightings. This is really WIP, by far not finished, nor polished. I don't even remember if I left debug code in it or not.
Reassigning to mkanat as he has more time to work on it these days.
Assignee: LpSolit → mkanat
Summary: Bugzilla needs to deal better with branches → Bugzilla needs to deal better with branches (implement sightings)
Attached file General Plan of Action —
Here is a list of steps detailing exactly how I plan to implement the specification. Each step would be a separate bug.
Looking at the WIP on landfill (comment 49): 1) I think the "(from bug NNN)" note should be omitted when NNN == this bug. 2) I'd prefer the sightings table down next to the attachments table. It feels a bit too prominent way up at the top of the page as it is now. 3) How will linkification work with comments that are sync'd across sightings? For example in the landfill bug, if I put the text 'comment 0' in a comment on bug 11575, does that yield a link to what's shown as the description (which is sync'd from bug 11574), or what's shown as comment 2 in the bug (which is the first comment actually in bug 11575)? Reading your plan of action, I see a couple of things that would trip us up at my organization (and probably others as well): 4) "Bugs may not be made into sightings of another bug after they are filed." The "mark as sighting" feature will be missed -- people will expect it to be analogous to "mark as duplicate." Just as duplicates can be filed even after a diligent search, it seems very likely that sightings will be filed as independent bugs, even if I search for related bugs first. This is esp. true if I limit my search to the version I'm using, but none of the sightings is filed against that version. 5) "Sync the following fields between all sightings (so that they have identical content): short_desc, status_whiteboard, keywords." This will be a problem because one use of the whiteboard and keywords is to track various bug life cycle events. In our org., we use "HaveFix" and "CheckIn" keywords to indicate when a fix is ready for review and when it has been reviewed. (Perhaps we should be using flags, but we're not.) Preventing different sightings from having different keywords is going to severely curtail the utility of those keywords.
Hi Max, I wanted to comment on your Plan of Action, but it seemed that perhaps the best way to do this was to make a copy of the text, turn on Change Tracking, and then edit it into the Plan of Action I think we should be executing. Hopefully, this should allow you to understand how and, to an extent why, people think this feature should be done quite differently - both architecturally and from a UI point of view. Certainly, if this feature is the answer to "Bugzilla needs to deal better with branches", then I don't think the Plan of Action will produce something which meets the Mozilla project's need to deal better with branches. And I don't think we have particularly unusual requirements in that area. (If you disagree, I'd love to hear about that.) We hope to have a meeting at the Mozilla Summit to try and figure out exactly what our ideal "branch management UI" would do. Hopefully, the outcome of the discussion might inform development of this feature. Gerv
Yes, I think we should all get in a room at the summit and discuss.
(In reply to comment #57) > Yes, I think we should all get in a room at the summit and discuss. Except that I will not be at the Summit.
Hey Gerv. Thanks for submitting your alternate plan. I agree that it was better to just post it than to try to discuss the existing one in a long series of comments--it's very clear to see what you've changed here and how your needs differ. The original Specification and the General Plan of Action come directly from a Requirements Document written by Everything Solved for a client that needed this feature. It also matches the requirements of various other Bugzilla-using organizations. However, I think there could be an interesting utility and flexibility in your suggestion of arbitrary bug relationships, and also in a lot of your other suggested changes. It's something that I will have to consider in the context of all Bugzilla-using organizations, and also something that I would indeed like to discuss in-person with as many different factions of Mozilla as possible. However, as I mentioned above, I won't be at the Summit (there haven't been any Bugzilla developers invited since the first one, and I don't think I'd be able to make the trip anyway), and there isn't anybody, AFAIK, who will be at the Summit who has my experience with the broader requirements of bug-tracking in both open-source and proprietary development organizations, separate from Mozilla. So it's certainly possible that you guys could come up with something great in terms of Mozilla's needs, but I suspect that without me being in the room, it may not be a very productive exercise for the Bugzilla Project. I do, however, live in Mountain View, so if at any time Mozilla would like me to come over and discuss the implementation of this feature and their needs with various developers--either one-on-one (which I'd prefer) or as a group--I'd be only too happy to work out a time that would work for all of us, even if it's several meetings across several months.
Target Milestone: Bugzilla 4.0 → Bugzilla 5.0
Target Milestone: Bugzilla 5.0 → Bugzilla 4.2
Hi Max, I'm afraid Summit invitations are not in my gift :-( However, I see your point. I think there's value in Mozilla deciding exactly what it wants, and it's important to realise that this is not necessarily what Bugzilla will implement - but if it's done in such a way that it's possible for us to implement what we want on top of what you want, then that would be good. I am in MV the week after the Summit, and would really love to meet up. Let's coordinate that by email. Gerv (packing at 11.45pm!)
I agree with Matt's "4)" in comment 55. I suppose the workaround in the current proposal is to dupe the new bug to the master bug, then open the master bug and create a sighting, then copy any relevant comments from the closed bug into the new sighting. On the other hand allowing random bugs to become sightings after the fact raises all sorts of issues with merging comments and attachments. Unlike Gerv (if I'm reading his counter-proposal correctly) I do like having a common comment stream -- after all I wanted the simpler (to me) bug 336790. I played with the WIP a bit, and compared it to the current cumbersome and ugly branch custom fields we're using in the browser Products here at BMO. Visually sightings win with a simple clear table using normal status terminology (then again, no surprise because that's what I wanted with bug 336790). Creating a sighting was slower and more work than flipping a status flag. If I've just fixed a topcrash on the trunk and want to nominate it as a blocker for the Firefox stable branches I currently set the blocking1.9.1 and blocking1.9.2 fields to "?". For sightings I have to click "New Sighting", click the product on the next page, and then submit the new bug form with the blocking flag set to "?". And then repeat those steps for the next release branch. I do get the flexibility to set different assignees which is nice, sometimes it's necessary. It'd be nice to remove at least the "pick the product" step -- can you presume the same product and let users move the bug after the fact? Or if sighting into new products is common in some installations (It'd never happen for Firefox) maybe two different links to create sightings, one for new version and another for new products? Once the sightings are created, some of my standard queries are fine, but some become impossible (quicksearch format) Branch nominations: curr: ALL blocking1.9.2:"?" new: ver:1.9.2 flag:blocking? Open blockers curr: ALL blocking1.9.2:%2b -status1.9.2:fixed new: ver:1.9.2 flag:blocking%2b The approval-related ones are about the same: if attachments are shared then we'll still need branch-specific approval flags. The ones to cover bugs fixed in a particular release on a branch get a little more socially complicated -- either we'll have to use date ranges or train people to use the "Target Milestone" to indicated the fixed-in release. Assuming the latter the queries are at least easy: bugs fixed in 1.9.2.5: curr: ALL status1.9.2:.5-fixed new: FIXED target:1.9.2.5 But another set of queries I run won't be possible at all in a sightings world, at least from what I can tell from landfill and the attached plan. When security bugs are filed I have to make sure that the fix makes it onto all the affected branches. That also means I need to make sure someone has checked to see what branches are affected. In our current scheme that means for security bugs I insist that the branch status flags be set to some explicit state (either fixed, wanted, unaffected, or wontfix) and assume the default lack of setting means no one has checked. Fixed security bugs not fixed on branch: FIXED group:security status1.9.2:wanted Fixed security bugs needing branch testing: FIXED group:security status1.9.2:---,"?" basically I need to be able to query whether bugs have or don't have sightings set up, and if they do restrict by various attributes of the sighting.
(In reply to comment #61) > On the other hand allowing random bugs to become sightings after > the fact raises all sorts of issues with merging comments and attachments. Right, which we'd rather avoid for the moment. The proposal doesn't mean that you'll *never* be able to mark a bug as a sighting after the fact, it just means that *at first*, you won't be able to. > For sightings I have to click "New Sighting", > click the product on the next page, and then submit the new bug form with the > blocking flag set to "?". And then repeat those steps for the next release > branch. Right, that's different than how my proposal will work. > basically I need to be able to query whether bugs have or don't have sightings > set up, and if they do restrict by various attributes of the sighting. Okay, that's good to know. I'm working on an overhaul of the backend code for boolean charts for 4.2, so I'll keep that requirement in mind.
so I think I can compensate for the "missing queries" by adding flags, keywords, or additional status whiteboard marking conventions. It's maybe an unusual case and I don't need you to design around it. Then again, maybe it's not so unusual, so it'd be sweet if you could work in related-sightings fields into the boolean charts. If you're messing with boolean charts the lack of good OR queries is a higher priority -- I've been stumped by that in many more cases as have many others I've talked to. That is, ((w OR x) AND (y OR z)) works, but you can't do ((w AND x) OR (y AND z)).
Being able to find bugs that are missing sightings on a particular milestone would be useful at my organization, too.
wsmwk pointed me at bug 419050 for boolean chart ORing. It's completely independent of this bug, but if you're overhauling boolean charts as mentioned in comment 62 I hope that bug is part of it (or that it's a dupe of one that is).
mkanat, could you attach your proposal as text/plain file? I don't agree with everything you wrote and I want to be able to comment on it.
Note that I agree even less with what gerv suggests.
I just copy-pasted from the PDF into a new document for my version; here's what I started with, as text. As there's obviously disagreement about what function we actually need here, I'm very glad we are having this conversation! :-) We should all try and explain "why" as well as "what" when outlining our suggestions; if the "why" of anything I am suggesting is not clear, please ask. Gerv
Great, thanks Gerv. Just so that everybody is clear on this, we aren't going to be designing this feature by committee. I'm going to be meeting with various Mozilla developers in August to gather requirements, and then there will be a single, non-committee decision on the eventual implementation of this feature. So discussion is valuable, particularly if it brings evidence of requirements to the table. That is, people who actually need this feature saying, "I need to do exactly Blah," like dveditz did, is valuable. But just a general discussion of "I like this" or "I don't like this" is not a scientific design process, and is the fastest way to get absolutely nowhere on this feature in the same way that we have for the last 10 years.
(In reply to comment #69) > Just so that everybody is clear on this, we aren't going to be designing this > feature by committee. I'm going to be meeting with various Mozilla developers > in August to gather requirements, and then there will be a single, > non-committee decision on the eventual implementation of this feature. I hope you realize that what you are saying is "I (mkanat) don't care about most of you and your opinions. I will make all the decisions myself, and only my implementation is correct."?
LpSolit: I don't think there's anything wrong in principle with having a single designer for a feature. We've had that many times. And I don't think Max is saying he doesn't care about the views of other people, only that he would like specific use cases to back them up. But yes, we should certainly gather as much info as possible about the use cases and needs for the single designer to work from. Gerv
Yes, Gerv is exactly correct. Thank you, Gerv. :-)
My organization needs the following: 1) To say "Existing Bug A in version T.6 is a new sighting of existing Bug B in version U", after both bugs are open. 2) To organize sightings, preferably from one screen: Bug A in version T has been fixed in T.7 Bug B in version U is targeted for Release U.2 Bug C in version V is targeted for Release W 3) To mark each sighting-bug as fixed/verified, independently of each other. This is most important. We compile releases with some time between them, so as not to overwhelm the testing organization. If Bug A is fixed a month before Bug C, we need to track that. We also use the 'Verified' status to 'verify' that a bug was actually fixed in a release. Sometimes the fix was completed, but got skipped or undone at build time. We need to verify each sighting independently. 4) To still be able to mark Duplicates. (Bug D in Version T is a dup of Bug A) 5) To be able to add a 'sighting' right from the master bug reusing most of the fields: component, owner, product, platform. 6) To be able to add custom fields that can be unique per-sighting. We track verification dates, which is never the date when it is marked as verified. We also track SW's progress in the whiteboard, which may or may not be the same for each 'sighting'. 7) We reuse target_milestones as the fixed_in_release field. Perhaps this would be helpful to change in Bugzilla as well. The two fields are significantly related and roll into each other once a bug is fixed. 8) We would like a way for other users to metoo a bug. This way if the original sighter in Version T is no longer available, we can ask one of the metoo's for more detail/debug data. A metoo feature would be great if they could specify a version that they found it in. -- I would actually like to go to the master bug, and have separate panes or tabs for each sighting. This way we have access to each of them but they are still grouped. We've hacked 3.0 to use the alias field to group bugs to overcome this particular bug for now. The alias is set to the initial bug_id, and each 'sighting' gets that same alias. Admittedly I haven't had time to look at your plans or the sandbox you've started on.
I'm having in-person meetings all this week with various people at Mozilla about this feature, and I had my first one today, with dveditz. The meeting was really useful. Here are the two decisions that affect this bug: * dveditz needs some way to find bugs that *lack* sightings with certain fields set. For example, he needs to be able to ask, "Find me bugs that have been fixed on the trunk that haven't been fixed on branch X.Y.Z." * I think it would be best to not sync anything between sightings and the master bug by default, even comments or attachments. This will allow us to be able to mark bugs as master bugs after the fact, and change sightings from master bug to master bug if we need to. It's also not a universal requirement or need that people have a unified set of attachments and comments. In fact, in Mozilla's case (and probably in most cases), it would be better if patches were only attached to the specific branch bug that they affect. Once the feature itself is complete, then people (or we) can implement extensions that offer the capability of syncing fields between sightings in the fashion desired by individual organizations.
(In reply to comment #74) > * dveditz needs some way to find bugs that *lack* sightings with certain > fields set. For example, he needs to be able to ask, "Find me bugs that have > been fixed on the trunk that haven't been fixed on branch X.Y.Z." What about the slight variation of finding bugs that lack sightings at all on certain branches? I.e., "Find me bugs that have been filed on the trunk but have no sighting filed for branch X.Y.Z." Or is this the same thing at some level?
(In reply to comment #75) > What about the slight variation of finding bugs that lack sightings at all on > certain branches? I.e., "Find me bugs that have been filed on the trunk but > have no sighting filed for branch X.Y.Z." Or is this the same thing at some > level? Yeah, what you're describing is a clearer version of dveditz's actual requirement. :-) So it was at least the same thing in my mind. :-)
Blocks: 597719
Hi All, I just tried the patch "WIP, v0.1 (15.71 KB, patch)" from Frédéric Buclin. Basically it could be used to mark the relationship of master bug and sighting bugs. The fix status in each branch is well display in show_bug.cgi page also. From patch source code, I see sighting field in bugs table and 2 shared fiedls in tables longdesc and attachments are added to record the relationship of master bug and sighting bugs. May I expect that Bugzilla will use this DB change also in the further version for purpose of tracking bug fixes in multiple branch? We are considering to use this patch to track bug fixes in multple branch and want to know the DB changes decision in this topic since this part impacts most efforts we may take in futhure Bugzilla version upgrading :) Anyway, thanks all the efforts on this!
The more I think about this, the more I think that we should do this work on an experimental branch, and then merge it in if and when we deem that it is actually the appropriate solution to everybody's problem. The thing is, I need to be sure that we can actually do the sort of required searches that people need, that the architecture will stand up to high-load environments, and that the UI will actually be workable. The only way that I can think of to do that effectively is to actually *develop* the entire system, but on a branch that is separate from the main Bugzilla trunk. Then we can play with it ourselves, offer it to a few organizations that want to take the risk of experimenting with it, and really get some general feedback about the solution before irrevocably making a major design decision that will impact the future of Bugzilla forever.
mkanat: that sounds like an excellent idea. Gerv
(In reply to comment #79) > mkanat: that sounds like an excellent idea. +1 Another comment about implementation: It would be great to create secondary bugs with different components. For example if adding a 'Custom Field for Type User' (bug 287332) will hit the Search, Admin, Show Bug, and Documentation components, these may be worked by different people. In larger organizations, it would be logical to have different bugs for each component, linked together by some master bug.
Any progress with this bug?
Blocks: 518932
Target Milestone: Bugzilla 4.2 → Bugzilla 5.0
Attaching a copy of the design for implementing the initial version of sightings into Bugzilla.
Assignee: mkanat → rowebb
Status: NEW → ASSIGNED
Depends on: 679547
Depends on: 685363
Depends on: 706629
We are going to branch for Bugzilla 4.4 next week and this bug is too invasive or too risky to be accepted for 4.4 at this point. The target milestone is set to 5.0 which is our next major release. I ask the assignee to reassign the bug to the default assignee if you don't plan to work on this bug in the near future, to make it clearer which bugs should be fixed by someone else on time for 5.0.
Target Milestone: Bugzilla 4.4 → Bugzilla 5.0
We have a complete solution to this feature and are in the process of getting the different patches approved. I am, however, moving on from my company who has been so kind to allow me to work on implementing this feature and push it back up to Mozilla. Chris Kamradt (ckin2001+bugzilla@gmail.com) will be following up with my work and be continuing to get these patches updated and submitted for review. I'm reassigning this bug over to him, though I'll still be on the CC-list to track the progression.
Assignee: rowebb → ckin2001+bugzilla
Target Milestone: Bugzilla 5.0 → ---
(In reply to Robert Webb from comment #85) > We have a complete solution to this feature and are in the process of > getting the different patches approved. Chris Kamradt > (ckin2001+bugzilla@gmail.com) will be following up with my work Any news?
(In reply to Andre Klapper from comment #86) > Any news? The next step is bug 706629, see the dependency list, but this patch is waiting for review.
*Bump* This bug is now more than 16 years old. Any chance this will ever be implemented? This is a feature we would really like at $workplace.
In comment 85 three years ago, this task got assigned to Chris Kamradt. According to their "User Activity" page, Chris has not been active in this Bugzilla since June 2014. Hence I am unassigning this task to avoid cookie-licking. The "P1" priority might also need correction to reflect reality.
Assignee: ckin2001+bugzilla → create-and-change
Status: ASSIGNED → NEW
This bug has a lot of baggage. It's never going to be done as stated here. Maybe multiple versions could be a thing, or maybe we could copy Tracking Flags from BMO. Either way, this bug is WONTFIX
Status: NEW → RESOLVED
Closed: 8 years ago
Priority: P1 → --
Resolution: --- → WONTFIX
I'd be very interested in what the actual requirements magnus@johansson-skytt.se has. Reach out to me in #bugzilla on irc.mozilla.org.
Flags: needinfo?(magnus)
Flags: needinfo?(magnus)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: