Change in behavior when bugs marked as resolved - Mozilla

This is a discussion on Change in behavior when bugs marked as resolved - Mozilla ; In the prior release, when a developer marked a bug as resolved,fixed, it could then be reassigned by another person to the qa contact who reported the bug. With 3.0 release I don't see any way to reassign the bug, ...

+ Reply to Thread
Results 1 to 5 of 5

Thread: Change in behavior when bugs marked as resolved

  1. Change in behavior when bugs marked as resolved

    In the prior release, when a developer marked a bug as resolved,fixed, it
    could then be reassigned by another person to the qa contact who reported
    the bug. With 3.0 release I don't see any way to reassign the bug, that
    field is not present. I am logged in as administartor.

    -dave

  2. Re: Change in behavior when bugs marked as resolved

    david souza wrote:
    > In the prior release, when a developer marked a bug as resolved,fixed, it
    > could then be reassigned by another person to the qa contact who reported
    > the bug. With 3.0 release I don't see any way to reassign the bug, that
    > field is not present. I am logged in as administartor.


    So you are saying: "When bugs are closed, it is not possible to reassign
    them without opening them again?"?

    Gerv

  3. Re: Change in behavior when bugs marked as resolved

    There was a long thread last release about reassigning bugs in resolved
    state. (Because BZ doesn't, by default, allow it.) Search this newsgroup
    for reassigning resolved bugs and you should find something. In fact, I
    posted the template changes I made in the thread. It should apply pretty
    closely to the new release. (I just rehacked my BZ3.0 to do this and it was
    just shuffling a couple of lines in the knob template.)

    -Scott

    "Gervase Markham" wrote in message
    news:69mdndzRL_u3E9TbnZ2dnUVZ_j6dnZ2d@mozilla.org. ..
    > david souza wrote:
    >> In the prior release, when a developer marked a bug as resolved,fixed, it
    >> could then be reassigned by another person to the qa contact who reported
    >> the bug. With 3.0 release I don't see any way to reassign the bug, that
    >> field is not present. I am logged in as administartor.

    >
    > So you are saying: "When bugs are closed, it is not possible to reassign
    > them without opening them again?"?
    >
    > Gerv




  4. Re: Change in behavior when bugs marked as resolved

    On May 15, 10:06 pm, "Scott Nance" wrote:
    > There was a long thread last release about reassigning bugs in resolved
    > state. (Because BZ doesn't, by default, allow it.)


    shrug, technically bugzilla does allow it, it just doesn't make it
    easy. i've been doing it for many years (you have to use change
    several and make sure the query includes a single open bug - you don't
    have to reassign that bug, just have it in the list).

    > Search this newsgroup
    > for reassigning resolved bugs and you should find something. In fact, I
    > posted the template changes I made in the thread. It should apply pretty
    > closely to the new release. (I just rehacked my BZ3.0 to do this and it was
    > just shuffling a couple of lines in the knob template.)


    I am curious though, since you appear to need it, could you take some
    time to survey a sampling of bugs where this is use and describe the
    conditions that necessitated its use? what's going wrong w/ the
    lifecycle that is forcing people to need to correct bugzilla?


  5. Re: Change in behavior when bugs marked as resolved

    The problem is one of changing field definitions during the life of a bug.
    Specifically with Assigned To...

    For example, a new bug is entered. Assigned To represents who is
    responsible for the bug at the current time. It stays this way until the
    bug is Resolved. Once a bug is Resolved, the person responsible for the bug
    is no longer the Assigned To but the QA Contact. It remains this way until
    the bug is Closed.

    This is just wrong. There should be ONE field that ALWAYS indicates who's
    responsibility the bug is at that point in time. Period. That field in
    almost every other system is Assigned To.

    It all boils down to accountability. "Who's working on this bug?" Assigned
    To ALWAYS tells you. Want to harass people who aren't moving their bugs?
    Set up a quick Whine to yell at the current Assignees of all bugs not marked
    Closed.

    Heck, I've even written a Daily Bug Summary script that sends out a list of
    bugs to everyone every morning. It's a simple list of every non-Closed
    Defect that's currently Assigned to you. No bugs assigned = no email. Our
    Developers LOVE it. They can come in first thing in the morning, look at
    their email and know right what's on their plate that day.

    Any field should have EXACTLY one meaning at all times in the bug lifecycle.
    And by the same token, every meaning should have EXACTLY one field. What's
    the Severity of the bug? Check the Severity field. What Milestone are we
    planning to ship this fix in? Check Target Milestone. Want to know who is
    responsible for a bug at this moment? It's Assigned To. Always.

    So simple even a Program Manager can understand it.

    -Scott


    "timeless" wrote in message
    news:1180012035.737060.111060@k79g2000hse.googlegr oups.com...
    > On May 15, 10:06 pm, "Scott Nance" wrote:
    >> There was a long thread last release about reassigning bugs in resolved
    >> state. (Because BZ doesn't, by default, allow it.)

    >
    > shrug, technically bugzilla does allow it, it just doesn't make it
    > easy. i've been doing it for many years (you have to use change
    > several and make sure the query includes a single open bug - you don't
    > have to reassign that bug, just have it in the list).
    >
    >> Search this newsgroup
    >> for reassigning resolved bugs and you should find something. In fact, I
    >> posted the template changes I made in the thread. It should apply pretty
    >> closely to the new release. (I just rehacked my BZ3.0 to do this and it
    >> was
    >> just shuffling a couple of lines in the knob template.)

    >
    > I am curious though, since you appear to need it, could you take some
    > time to survey a sampling of bugs where this is use and describe the
    > conditions that necessitated its use? what's going wrong w/ the
    > lifecycle that is forcing people to need to correct bugzilla?
    >




+ Reply to Thread