Open
Bug 260833
Opened 21 years ago
Updated 2 years ago
New option to only assign initial qa contacts when a bug is resolved
Categories
(Bugzilla :: Creating/Changing Bugs, enhancement)
Bugzilla
Creating/Changing Bugs
Tracking
()
NEW
People
(Reporter: mschrag, Unassigned)
Details
Attachments
(1 file, 1 obsolete file)
3.12 KB,
patch
|
Details | Diff | Splinter Review |
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040910 MultiZilla/1.5.0.3l
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040910 MultiZilla/1.5.0.3l
In our workflow, we don't want to even involve the qa contact until a developer
marks the bug as resolved. In the current Bugzilla impl, QA contact is CC'd on
every change to the bug. With this patch, QA contact will be empty if the
setting is enabled. When a developer resolves a bug, the QA contact is then set
to be the component's initial QA contact (unless another is selected on the form).
This actually also revealed a bug in do_not_change values. If dontchange is not
set, then it defaults to "", but the empty value for qa_contact is "", so a qa
contact can never be cleared. I changed the default do_not_change value to
"--do_not_change--" to make it non-empty.
Reproducible: Always
Steps to Reproduce:
![]() |
Reporter | |
Comment 1•21 years ago
|
||
![]() |
||
Comment 2•20 years ago
|
||
A better alternative is to add an option in the email prefs panel allowing you
to not receive any mail as long as the bug is in a opened state.
gerv, we cannot do that based on the bug status, right? (except for UNCONFIRMED
bugs).
![]() |
||
Comment 3•20 years ago
|
||
Thanks for contributing this patch; however, I think it's too specialised to go
into mainstream Bugzilla. I think even Frederic's suggestion is too specific.
I'd suggest that people who want this sort of behaviour hack it directly into
the functions which send mail - just as we get people to do some access control
by hacking CheckCanChangeField().
Gerv
![]() |
||
Updated•20 years ago
|
QA Contact: mattyt-bugzilla → default-qa
Comment 4•20 years ago
|
||
(In reply to comment #3)
Hello,
I am a little unsure of what this bug is requesting and/or what gerv is arguing against. I would like to have the notification of a new bug sent to the QA Contact once the bug is resolved. I posted to the webtools mailing list and someone interpreted my message to initially mean that the QA contact is not set for the bug until it is resolved at which point bugzilla would set the QA contact to the default QA person at the time. This seems like a reasonable thing but I am hoping that we do not have high enough turnover or bugs that last long enough for this to really matter.
The chart at:
http://www.bugzilla.org/docs/tip/images/bzLifecycle.png
Seems to support my understanding of how QA works but I may be off. It seems that the QA people should only be informed about a bug once it is resolved or when "development is finished with the bug." Only then can the QA person attest to not being "satisfied with the solution" or verify that the solution works.
One of the biggest hurdles for a lot of people that are new to bugzilla is the email system. A lot of people especially outside of nerds are used to recieving email and atleast looking into the problem to see if they can/should take immediate action on the item. Right now all I hear from my users is that "that zilla thing emails me all the time and I hardly have anything to do yet."
Am I missing something? Why is this specialized? I am fairly new to the process of QA so I am not very confident that I understand the common operation of a QA process. Thanks...
![]() |
||
Comment 5•20 years ago
|
||
*** This bug has been confirmed by popular vote. ***
Status: UNCONFIRMED → NEW
Ever confirmed: true
![]() |
||
Comment 6•20 years ago
|
||
> Thanks for contributing this patch; however, I think it's too specialised to go
> into mainstream Bugzilla. I think even Frederic's suggestion is too specific.
>
> I'd suggest that people who want this sort of behaviour hack it directly into
> the functions which send mail - just as we get people to do some access control
> by hacking CheckCanChangeField().
Gerv - I disagree completely. For any large site that has significant development time between new to resolved (happens often here), QA contacts can and do change. Take BMO for example... I think it's best to assign QA contacts when a bug changes to RESOLVED for the first time. Looking at the patch, it seems that's exactly what is done. Also, because it includes the ability to turn the feature on/off, I disagree with you about mainstreaming it. I would rather see a poll of users who would have the option to decide whether or not they would want to use such a feature. I agree with Doug that this is an important feature. I think Fred's work should be included in a soon-coming release. From a cursory look at the code, it seems Fred has done everything to make it easy to use and an option that users can turn on/off.
As the size of organizations increase, it seems the likelihood of this feature being needed increases. In my mind, an enterprise-class business (like AMD) would want this feature as a part of their requirements. People do come and go and bugs do stay open for months at times. Adding work to administrator's plates is not our goal (of course).
I only have twenty votes available to me for all Bugzilla bugs, and I've only voted for three bugs. This is one of them. That's how important it is to me and what I do.
![]() |
||
Comment 7•20 years ago
|
||
OK, then. As long as there's a Param() to change the behaviour, which there is, then I won't argue.
Gerv
Assignee: myk → create-and-change
![]() |
||
Comment 8•20 years ago
|
||
Sorry - missed the Commit button and hit the knob.
Gerv
Assignee: create-and-change → myk
![]() |
||
Updated•19 years ago
|
Assignee: myk → create-and-change
Updated•2 years ago
|
Attachment #9381372 -
Attachment is obsolete: true
You need to log in
before you can comment on or make changes to this bug.
Description
•