Community
Participate
Working Groups
Add a new state to bugzilla (RELEASED) to distinguish between a bug that has been fixed in the CVS but not yet in a release (RESOLVED/FIXED) and a bug that has been fixed in both the CVS and on the update/download site (RELEASED/FIXED). I envision using this state either as: (a) OPEN -> RESOLVED/FIXED -> RELEASED/FIXED -> VERIFIED -> CLOSED, or (b) OPEN -> RESOLVED/FIXED -> VERIFIED -> RELEASED/FIXED -> CLOSED depending on whether the verified is a binary user (a) or a source code developer (b).
I think a released status indication is not a bad idea. We could also use the status whiteboard for it. A bug could be released to multiple environments (eg. test or production, stable build or release build, HEAD and/or branch x.y.y and/or branch x.y.z). Just a RELEASED status would not reflect this properly. (In reply to comment #0) > (a) OPEN -> RESOLVED/FIXED -> RELEASED/FIXED -> VERIFIED -> CLOSED, or > (b) OPEN -> RESOLVED/FIXED -> VERIFIED -> RELEASED/FIXED -> CLOSED How can you verify a bug that hasn't been released yet? Just from code review? Also, in the first case, all bugs marked as RESOLVED/FIXES are somehow automatically RELEASED/FIXED, i.e. they are RELEASED into the source repository. But who is going to move them from a RESOLVED to a RELEASED state? A build engineer after it actually was build? A release manager after a build has been promoted?
Bjorn, I just read your blog entry. Isn't that what you are asking for the "Target Milestone" field? Unfortunately, the field has two meanings. One could be read as "scheduled for" and the other as "fixed in". The Platform UI team uses this for all their bugs in both meanings. So one can see that a bug was "fixed in" 3.2 RC6 (for example).
I agree that informing users of when they can verify that their bug has been resolved is important. But when you have continuous integration the user can verify by downloading a nightly build (in the case of Platform) or a dev build (in the case of Mylar or AJDT). As Gunnar points out the Target Milestone is how we indicate to users when the fix will be in a release. In addition our practice when marking RESOLVED is to point them at the dev build to verify, and they frequently do which is great. So I'm -1 for adding a new state. As the flowchart indicates (http://www.eclipse.org/projects/dev_process/bugzilla-use.php) there are already a lot of states for users to wrap their head around, and it seems to me that we should promote continuous integration where RESOLVED means RELEASED, modulo some acceptable build delay that is up to the project (e.g. 24 hours).
Bjorn's blog post on this issue (referred to by Gunnar in comment #2): http://eclipse-projects.blogspot.com/2006/07/customer-service.html
Heck, just having some good advice on when bugs should move from FIXED to VERIFIED would be good. Should the original poster verify the bug, or another person? Or the fixer after the first cycle? My feeling is that RESOLVED is used as a place-holder for pretty much any other state than assigned and open. For example, RESOLVED LATER isn't resolved at all -- it's just moving the bug out of the visible queue into an invisible queue that might get lucky if it's reopened later (but mostly not). Even worse, you can make a bug report in an old stream (e.g. 3.0) and have it marked as RESOLVED LATER because it's outside of the timescale. If you then re-raise it for 3.1, it gets marked a duplicate of RESOLVED LATER and thus gets delayed until 3.2. Just search for the number of RESOLVED LATER for Eclipse releases scheduled < 3.1, and you'll get a picture of how bad it is. This is just one of the ten things I hate about Eclipse (http://alblue.blogspot.com/2006/02/eclipserant-10-things-i-hate-about.html). I've also raised issues about the proper bug reporting cycle before; bugs that get marked duplicated often lose context (or even suggestions) from subsequent bug reports (bug 36009) and improvements to the bug patching (bug 55857), both of which were closed WONTFIX. So really, how is having a new state RELEASED going to address anything? Frankly, there's a state CLOSED which many projects don't even use, and there's even less standardisation between projects about what the individual states are for, or what their lifecycle is. I'd say fix the existing problems rather than stick a new plaster on top of a seeping wound.
(In reply to comment #5) > [...] and improvements to the bug patching (bug 55857), both > of which were closed WONTFIX. I agree, bug 55857 is a nasty UI issue but it's clearly an Bugzilla issue and should have been reported at bugzilla.mozilla.org. Anyway, before we get too deep into this issue there is still bug 121703 that needs a decision. Otherwise we won't have any chance to implement this one.
Back to the Eclipse user perspective again... Verifying that a bug has been fixed is one thing, being able to use the Eclipse product with the fix is another. When I read Bjorn's blog post, I sympathized more with the user that wants to use the fix than the developer/tester that needs to verify that the fix works. Having said that there are two big reasons I can see (and probably more) why an Eclipse user might not want to use anything but an *official* Eclipse release: 1. They can't. Their IT department forbids it OR their team is synchronized on the same version of Eclipse OR the product they are developing is based on version x.y.z of Eclipse and won't update until later OR... 2. They don't want to risk their valuable production source and workspace data with a version of Eclipse that might be unstable. These people can't just pick up a nightly or milestone build and use it. Someone might wonder: when will my bugfix or new feature be in an official Eclipse release? Sometimes you can deduce this from the Target Milestone (if it's filled out). Sometimes you can deduce that it'll be in the next maintenance release. But at maximum, that time could be up to a year given the current release cycle timeline. That could be a long time to wait in the RESOLVED state without a deployed fix. Should regular Eclipse users need to know this much about Eclipse release cycles just to get their fix? Will changing Bugzilla help? I'm not sure about that. But we've identified a sore spot and can start talking about it.
I don't believe that a new RELEASED state will change anything. The target milestone should be used to reflect in which release the fix is available. The biggest problem in this case is that there can be only one target milestone for each bug. A bug could be fixed into multiple branches (3.0 maintenance, 3.1 maintenance, 3.2 maintenance and 3.3 HEAD). What we should really have is the ability to specify multiple target milestones for a single bug. Replying to comment 2, this is not an issue. RESOVED/FIXED or VERIFIED/FIXED with a target milestone means it is available in this build. ASSIGNED/OPEN/... with a target milestone gives an idea when the bug is fixed. My 2 cents.
(In reply to comment #8) > The target milestone should be used to reflect in which release the fix is > available. The biggest problem in this case is that there can be only one > target milestone for each bug. A bug could be fixed into multiple branches (3.0 > maintenance, 3.1 maintenance, 3.2 maintenance and 3.3 HEAD). > What we should really have is the ability to specify multiple target milestones > for a single bug. Multiple target milestones are a simple solution to that problem. A more in deep approach solving the issue is the ability to branch bugs. But honestly, nobody really wants that. It really complicates things. ;) So, cast your vote here if you want multiple target milstones. :) https://bugzilla.mozilla.org/show_bug.cgi?id=198384
Done :-).
Summarizing, +1 for this proposal. I was about to send an email to Bjorn requesting the creation of this state when I was pointed to this bugzilla. I will paste here the email in which I am explaining why this would be important for projects like EMF. --- Short story: ============ For quite a while we (EMF team) have been discussing the need for a new bugzilla state. This state would indicate that a given fix or feature implementation is available in a published build (regardless if it is a milestone or a simple N/I build). The word "Released" is the best that I can come up with. Long story: =========== The EMF team is quite small and we have a very large user base (including all the Eclipse projects that rely on us) that actively monitors and uses not only our weekly builds but also our source code from CVS. In this scenario, the formal definition of the bugzilla states (as described in https://bugs.eclipse.org/bugs/page.cgi?id=fields.html) is not really useful because, up to now, we could easily track "who is doing what" and because it doesn't address our need to indicate when the source is in CVS and when a build with the change is released. Because of that, we've ended up tweaking (maybe "twisting" would be the proper term) the Eclipse's default bugzilla flow to: 0. The bug is reported - State: NEW 1. One of us start working on the bug (remember that we are a small team) - State: NEW (no changes) 2. The change is available in CVS and our users can experiment with it - State: ASSI 3. The fix is available in a build - State: FIX This has been working really well for the last 2.5 years but now we are starting to see the need to simplify answering the "who is doing what" question - not that our team is growing... we are just doing too many things ;-). This would be a good opportunity to go back and use the states as intended by Eclipse. For this to happen though we would need the new bugzilla state described in the "Short story" section above. With it, our flow would be 0. The bug is reported - State: NEW 1. One of us start working on the bug - State: ASSIG 2. The change is available in CVS and our users can experiment with it - State: FIX 3. The fix is available in a build - State: REL I would suggest this new state to be optional so that the other teams are not forced to use it immediately and also to require a comment, that should be the either build ID or web link. A side but important note... The EMF build process is very rich and automates what we call "build promotion" which comprehends: 1. Copying the build files to the Eclipse servers 2. Generating and deploying the UM files 3. Generating a release notes with the list of bugzillas addressed in the build 4. Updating the "what is new section" in our web page 5, Post a "New build available" message in our newsgroup 6. Move all the addressed bugzillas to the "FIX" state The reason I am mentioning this is to show that the bugzilla transition to this new state can be automated. Actually, Nick, the maintainer of this infrastructure, is now a committer for the Eclipse ReleaseEng component what makes it easier to start a discussion about making this process available to other teams.
+1
Adding a new state without the core Bugzilla support is probably impossible. But once https://bugzilla.mozilla.org/show_bug.cgi?id=101179 has been implemented it might become very easy for a project to customize its workflow. Anyway, here are some proposals that would work already today and don't require modifying the Bugzilla installation. - The combination "Target Milestone" and RESOLVED/FIXED" already works pretty well to indicate a milestone build where the fix is contained in - Use a "released" flag to indicate if a fix is available in a build - A "released" keyword might also work too (but I thing a flag is better) - Use the Status Whiteboard field to indicate the build number The advantage is that all those fields are already available and do perfectly work within Bugzilla. They also allow queries based on them.
It seems to me that folks typically use the target milestone to indicate the milestone that they are targetting to have the work completed by. I.e., it's set to indicate an intent/plan to have it done for that target, rather than something that's set after it's done to indicate it's actually done for that target. Also, target milestones aren't typically generated for weekly I builds, so they don't seem fine grained enough. Often groups use the assigned state to indicate that the bugzilla is actively being worked on so that two people don't work on the same thing accidentally. Others use it to indicate that the bugzilla has been triaged and is waiting on a particular person's queue, although assigning it to an owner should suffice for that, if there is a generic in-box type owner to start with. We use it to indicate that the work is completed (committed to CVS) and is pending availability in the next I build. I think one could argue that the assigned state is not necessary and could be handled by various other flag combinations, yet it's already there and it's useful to many groups. Similarly, I think an additional state that more closely reflects the changing status in the bug's life cycle would be useful and could be ignored by those who don't consider it useful (just as the ASSIGNED state can be ignored).
Just curious... any progress on this?
(In reply to comment #15) > Just curious... any progress on this? > This won't likely happen until this is implemented: https://bugzilla.mozilla.org/show_bug.cgi?id=101179 (I can't add an external bug as a dependency)
Would the ability to customize the resolutions be of any help here? Mozilla have marked the enhancement fixed, for Bugzilla 3.0: https://bugzilla.mozilla.org/show_bug.cgi?id=94534 Custom statuses is on the roadmap for Bugzilla 3.2: https://bugzilla.mozilla.org/show_bug.cgi?id=101179
Bugzilla 3.2 is slated for release next week, and it ships will the ability to define custom statuses. That will enable us to add a RELEASED status, is it is still desired.
fyi, Mylyn does not currently expose custom state changes and will require significant work to fully support custom status workflow: bug#259291.
(In reply to comment #15) > Just curious... any progress on this? FWIW, I no longer want/need this, as we've long ago ported our workflow to use this process, and don't need this extra state. New > (Assigned) > Resolved/Fixed (code in CVS) > Verified/Fixed (code *released* in a build, published at Eclipse.org). I'm changing my vote to: 0 (indifferent, this doesn't affect me) or perhaps -1 (do we really need to give the Mylyn guys extra work, or Denis more things to support?)
Removing my vote as well...
Also removing my vote.
So do we still want this?
I'll close this bug as WORKSFORME for three reasons: 1. Many have removed their vote for it 2. In the three years it's been open, it hasn't gathered a very widespread support 3. I think most people (and apps like Mylyn) know and understand the RESOLVED/FIXED > VERIFIED > CLOSED workflow.
