This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Joel On Software - a must-read article "Painless Bug Tracking" http://www.joelonsoftware.com/articles/fog0000000029.html: > When a bug is resolved, it gets assigned back to the > person who opened it. This is a crucial point. It does not > go away just because a programmer thinks it should. The > golden rule is that only the person who opened the bug > can close the bug. The programmer can resolve the bug, > meaning, "hey, I think this is done," but to actually > close the bug and get it off the books, the original > person who opened it needs to confirm that it was actually > fixed or agree that it shouldn't be fixed for some reason. I think we must adapt this solution. We must care of the user more.
Maxym - I agree completely with this description of issue flow. I guess you are suggesting that IZ should automatically assing a fixed issue back to the reporter ? Assigning to Collab - Collab, of course IZ is going away sometime soon, perhaps too soon to implement this request, but pls consider it as a feature request for Scarab.
I'm sorry that our issue scrub has caused some confusion. Here are a few notes to clear things up. When we went through and changed the status of the issues that have a release assigned to them for the fix, we marked the issues Resolved, Fixed. This means that this will be taken care of in the release indicated in the status whiteboard. There are 2 other status values after resolved fixed, verified and closed. Our intentions are to go through each of the issues that has been marked resolved fixed after each upgrade(they are still assigned to support), verify ourselves and then request that the issue be verified by the Netbeans team as well. It would then be up to the Netbeans team to change the status of the issue to "CLOSED" or reopen the issue. I'm afraid I misspoke in some of the updates and said I was closing the issue. I should have said "marking resolved fixed". We have carefully documented the issues that are assigned to specific releases and will be testing them post upgrade. CollabNet is currently preparing more detailed documentation on our issue tracking procedures for our clients. To follow up on this issue, I'll look into Scarab's behavior around marking an issue "CLOSED". Thanks, Kristen
Refinement: Reporter reports. STATUS: NEW Programmer fixes. STATUS: RESOLVED FIXED Original issue reporter is asked in a SPECIAL e-mail to verify the issue. If all is OK, he(she) says, it works! STATUS: RESOLVED VERIFIED I have no clue, who should mark issue CLOSED ;) Maybe QA people (I'm against this), or it should be done automatically when the product (with this bugfix integrated) actually ships (I'm pro). QA may want not to look at the issue at all, if it's not much important (P3 or less), which gives QA the possibility to concentrate only on the important bugs!!!
It is ultimately up to the domain and project administrators to define the workflow for issue tracking within the capabilities of the product. CollabNet support is currently evaluating how we handle our support issues with customers and looking for ways to make improvements. We plan to update this issue once the process has been defined, the guidelines have been agreed upon by Sun and we have received instructions. We would not suggest that there is one way that works best for everyone on all sites or projects but can post our findings here as a model. Please let me know if there are any other suggestions or concerns on the timeframe for the next update in this issue. Thanks, Kristen
Change in our Update Plan: Our plan is to update this issue in 2 weeks with a status update on the Collabnet Support Issue process. Please let us know if there are any additional thoughts on this issue or concerns about the timeframe for the next update. Jan
Dear Jan, do you speak English? ;-) Please, please, please, speak human language: "We lost this issue, and I'll try to get some more info in 2 weeks. Is that OK?" Smile: ********************************************** > Change in our Update Plan: A change in my ever-lasting plan to change my way of doing changes. > Our plan is to update this issue in 2 weeks me too! me too! I also want to post here every twoo weeks, may I ;) > with a status update on the Collabnet Support Issue process. It's such a complex process to post here the letters, well, maybe I should pay more for my mozilla > Please let us know if there are any additional thoughts on this issue The only thing I could get from the whole letter. Maybe I'm getting too clever ;-? > or concerns about the timeframe for the next update. whose updates? yours? - one big concern Collab seems not to have any timeframes. (but that's another story) ours? - I plan to update my personal homepage in about a month, if you're seriously interested ;> ********************************************* Smile again Sincerely, Maxym Mykhalchuk
Update: This is an ongoing discussion within our support team and we're currently testing out a couple of flows for the issue process. Action Plan: The support team will continue working out some of the questions around our issue flow internally. Next Update: Within 2 weeks. Thanks, Kristen
Update: We're still working on this issue. Action Plan: Support will continue to discuss this and explore options. Next Update: By 12-13-02 Thanks, Kristen
I'd paste here what I got from Jack in issue 27336: Additional Comments From jcatchpoole@netbeans.org 2003-01-08 08:48 PST 'Yosh, the current procedure that Collab have been following in general is to close any issue fixed in an upcoming release. It should then be verified when that release rolls out. Personally I don't think that is a good policy (closing before the user has the fix), but maybe consistent bad policy is better than inconsistent :-) I mean to be consistent this issue should probably be closed, if it is fixed in Truckee. Just my 2c.' I kind of agree with Jack regarding consistent policy. So, I'd close this issue. We could revisit of course after the upgrade by reopening for further discussion or verifying it. Thanks.
Just for reference, I am attaching an email I sent to Collab in September 2002. This is only for reference, as I periodically seem to go through my mail archives searching for this. It relates to this issue so I am filing it here.
Created attachment 11618 [details] reference email regarding RESOLVED/FIXED status of SC issues
This is not fixed in IZ. This is a good oppurtunity to track this for PT as it will be a good enhancmecement for it.
Jack, What we are upto on this issue? Are we tracking them for the issue handling process? I hope you are aware of our new issue closing policy and do you have any questions about that? What we are expected to do in this issue?
I'm not Jack, but at least please revisit all RESOLVED FIXED issues assigned to support and change them to RESOLVE LATER. Bad consistent policy is better than bad inconsistent policy after all.
Currently, the closure of the enhancement issues that are fixed in releases after 3.5.1 are marked as RESOLVED LATER. A monthly review of resolved later queue is followed up to mark the target milestone pertaining to the release in which the feature is implemented. As you have mentioned, issues marked RESOLVED FIXED previously will be moved to RESOLVED LATER queue soon. Regards, Ramya
We recently moved out from Collabnet's infrastructure