Rename New/Accepted statuses as Unconfirmed/Confirmed, and other tweaks

+1 to Unconfirmed/Confirmed/Being fixed.

I think it may also be useful to show who confirmed the bug. Some "confirmations" are more confirmatory than others. ;)

Showing who made the change would fall naturally out of <https://wiki.launchpad.canonical.com/BugHistory>.

On Thu, Dec 01, 2005 at 08:59:45PM -0200, Christian Robottom Reis wrote:
> UI and functionality change. I'd like to get sign-off from you on this
> proposal.
> [...]
> To resolve this confusion and encourage better Malone workflow, bradb, mpt, and kiko have concluded that Malone should have these states:
> "Unconfirmed" (renamed from "New")
> "Needs Info" (renamed from "NeedInfo")
> "Rejected" (no change)
> "Confirmed" (renamed from "Accepted")
> "In Progress" (new state)

These seem reasonable.

> "Fixed" (renamed from "PendingUpload")
> "Released" (renamed from "Fixed").

It is very confusing for users to see a bug marked "Fixed" but to be unable
to get the fix anywhere. I recommend that the final state continue to be
called "Fixed" or "Closed", as these are widely used terms in bug trackers
with a well-understood meaning.

I would support renaming PendingUpload to something more meaningful, which
indicates more clearly "someone has implemented a fix, but it's not
available in the usual place yet".

The states we currently have in Bugzilla are:

NEW "Unconfirmed"
ASSIGNED "Confirmed
NEEDINFO "Needs Info"
UPSTREAM This is handled by other means in Malone(?)
PENDINGUPLOAD Could be named better
RESOLVED/FIXED "Fixed"
RESOLVED/... Rejected

--
 - mdz

mdz, we assume developers will instinctively consider a bug as "fixed" as soon as they commit the fix, even before it appears in a release, and that we should recognize that in the status name. Eventually "Released" may be replaced by a field letting people specify which release(s) the bug is fixed *in*.

Le 2-Dec-05 à 7:50 AM, Matthew Paul Thomas a écrit :

> Public bug report changed:
> https://launchpad.net/malone/bugs/971
>
> Comment:
> mdz, we assume developers will instinctively consider a bug as "fixed"
> as soon as they commit the fix, even before it appears in a
> release, and
> that we should recognize that in the status name. Eventually
> "Released"
> may be replaced by a field letting people specify which release(s) the
> bug is fixed *in*.

mdz, would you be comfortable with "Fixed" and "Released" for now,
with a view to collapsing that into Fixed + branch and/or release
metadata in the future?

Cheers,

--
Brad Bollenbach

On Fri, Dec 02, 2005 at 06:10:53PM -0500, Brad Bollenbach wrote:
> Le 2-Dec-05 à 7:50 AM, Matthew Paul Thomas a écrit :
>
> >Public bug report changed:
> >https://launchpad.net/malone/bugs/971
> >
> >Comment:
> >mdz, we assume developers will instinctively consider a bug as "fixed"
> >as soon as they commit the fix, even before it appears in a
> >release, and
> >that we should recognize that in the status name. Eventually
> >"Released"
> >may be replaced by a field letting people specify which release(s) the
> >bug is fixed *in*.
>
> mdz, would you be comfortable with "Fixed" and "Released" for now,
> with a view to collapsing that into Fixed + branch and/or release
> metadata in the future?

I think it would be unnecessarily confusing to deviate from _both_ the
existing Ubuntu bug tracking definition of "fixed" (Bugzilla) and the common
usage of it in other open source projects.

If we want to represent the state where a bug has been fixed somewhere other
than in the Ubuntu archive, I think that's fine, but we should absolutely
not call it "fixed".

--
 - mdz

On Mon, Dec 05, 2005 at 07:54:04AM -0000, Matt Zimmerman wrote:
> I think it would be unnecessarily confusing to deviate from _both_ the
> existing Ubuntu bug tracking definition of "fixed" (Bugzilla) and the common
> usage of it in other open source projects.

In http://bugzilla.mozilla.org/ the RESOLVED FIXED status+resolution is
used to indicate something that is fixed-in-CVS. The same is used for
http://bugzilla.gnome.org/. The Python bugtracker (in sf.net) uses Fixed
to mean essentially the same thing.

Bugzilla's "normal" model is to use the VERIFIED and CLOSED statuses to
indicate what happens post-RCS-landing -- in
http://bugzilla.mozilla.org/ we use VERIFIED when someone tests a CVS
build and agrees that it is fixed, and CLOSED is when there is a version
released that includes that fix.

We're proposing using a simplified form of the Bugzilla model (omitting
a "Verified" status).

On Thu, Dec 01, 2005 at 03:21:15PM -0800, Matt Zimmerman wrote:
> The states we currently have in Bugzilla are:
>
> NEW "Unconfirmed"
> ASSIGNED "Confirmed
> NEEDINFO "Needs Info"
> UPSTREAM This is handled by other means in Malone(?)
> PENDINGUPLOAD Could be named better
> RESOLVED/FIXED "Fixed"
> RESOLVED/... Rejected

We also have VERIFIED and CLOSED, for the record:

    http://bugzilla.ubuntu.com/show_bug.cgi?id=1223

    Leave as RESOLVED NOTWARTY
    Reopen bug
    Mark bug as VERIFIED
    Mark bug as CLOSED

It appears to not be used in Ubuntu.
--
Christian Robottom Reis | http://async.com.br/~kiko/ | [+55 16] 3376 0125

On Mon, Dec 05, 2005 at 06:19:13PM -0200, Christian Robottom Reis wrote:
> On Thu, Dec 01, 2005 at 03:21:15PM -0800, Matt Zimmerman wrote:
> > The states we currently have in Bugzilla are:
> >
> > NEW "Unconfirmed"
> > ASSIGNED "Confirmed
> > NEEDINFO "Needs Info"
> > UPSTREAM This is handled by other means in Malone(?)
> > PENDINGUPLOAD Could be named better
> > RESOLVED/FIXED "Fixed"
> > RESOLVED/... Rejected
>
> We also have VERIFIED and CLOSED, for the record:
>
> http://bugzilla.ubuntu.com/show_bug.cgi?id=1223
>
> Leave as RESOLVED NOTWARTY
> Reopen bug
> Mark bug as VERIFIED
> Mark bug as CLOSED
>
> It appears to not be used in Ubuntu.

Correct; we don't use those states.

--
 - mdz

I agree with mdz: calling it "Fixed" to mean something like
"PendingUpload" is not a path to user happiness.

kiko, mpt, mdz, are you happy if we leave off creating the extra
"Released" state and focus instead on the common understanding of
"Fixed" + creating a UI to name specific branches and releases in
which the fix is available?

  affects /products/malone status needinfo

Cheers,

--
Brad Bollenbach

No, I think we should find a proper set of statuses we can agree on. mdz's point is not as well-taken if you consider that most other bugtracker users will be used to setting bugs to Fixed when it lands. We do it in Launchpad ourselves.

We already have inconsistency in the PendingUpload status. This bug should be used to resolve that.

The way forward is probably to have a meeting/phone call to synchronize on this and make a plan. I'm available all of next week -- just set it up.

I don't think this blocks the Bugzilla run, though -- we can always just migrate statuses later.

On Sat, Dec 10, 2005 at 02:15:05PM -0000, Christian Reis wrote:
> The way forward is probably to have a meeting/phone call to synchronize
> on this and make a plan. I'm available all of next week -- just set it
> up.

I think it would be good if that phone call resulted in a spec,
documenting all the proposed statuses, and especially documenting all
the use cases.

I think we need just "fixed", and we don't need "released" or "pending upload". The status "fixed" applies to a Bug task, not just to a Bug. We have product bug tasks, and we have source package bug tasks. We also have distro bug tasks.

For source packages, "fixed" means "a package with this fix is available in the archive".

For products, "fixed" means "this fix has been made in upstream RCS".

When we make Malone understand product series better, then "fixed" for products can be targeted at a product series.

Talking with SteveA, I've confirmed that it's okay to proceed with landing Fixed + Released for the first cut, getting some feedback from that in the Real World, and then making adjustments (possibly renaming those statuses) as needed.

I've sent it off to BjornT for review.

On 15-Dec-05, at 9:21 AM, Brad Bollenbach wrote:

> Public bug report changed:
> https://launchpad.net/malone/bugs/971
>
> Comment:
> Talking with SteveA, I've confirmed that it's okay to proceed with
> landing Fixed + Released for the first cut, getting some feedback from
> that in the Real World, and then making adjustments (possibly renaming
> those statuses) as needed.
>
> I've sent it off to BjornT for review.

I changed these statuses to Fix Committed and Fix Released,
respectively, as per SteveA's instructions in Vilnius.

I would have like to have landed this behind the InitialBugContacts
branch today, but unfortunately my IBC merge has spent all day at #1
in pqm's queue. :/

Cheers,

--
Brad Bollenbach