If multiple reports on new bug, mark it confirmed

Bug #777874 reported by Kate Stewart on 2011-05-05
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Launchpad itself
Gary Poster

Bug Description

If a new bug, has >2 duplicates associated with it, or >2 people have indicated that this bug affects them, then automatically mark it confirmed.

This will get more common bugs looked at earlier, and match the definition of confirmed. (https://wiki.ubuntu.com/Bugs/Status). Have been seeing instances of bugs as new, which have several duplicates, etc. as working through Natty.

Related branches

Robert Collins (lifeless) wrote :

The whole confirmed/triaged workflow needs an overhaul; there are a few sketches floating around about how we might do this. This particular one is probably fairly easy to do and not incompatible with fixing up the whole situation (but entirely redundant with the data-driven variations of the proposals)

Changed in launchpad:
status: New → Triaged
importance: Undecided → Low
tags: added: bugs
Kate Stewart (kate.stewart) wrote :

While this may be low from a Launchpad perspective, its pretty high to get things efficient in the Ubuntu project. Adding a task related to Ubuntu, and indicating our importance on this.

Changed in ubuntu:
status: New → Triaged
importance: Undecided → High
milestone: none → oneiric-alpha-1
Jonathan Lange (jml) on 2011-05-07
tags: added: ubuntu-platform
Changed in ubuntu:
milestone: oneiric-alpha-1 → oneiric-alpha-2
Bryce Harrington (bryce) wrote :

I agree with robert that the confirmed/triaged workflow could benefit from some additional thinking.

There's actually two separate problems here, as I see it.

First, the core problem I think Kate is trying to get at is that the volume of bug reports to Ubuntu is very high, well beyond the available developer / package maintainer / triager resources to stay atop. Launchpad needs to be better at helping developers filter down their lists of bugs to ones that really do need attention. So having a way to limit your view to "bugs that affect N or more people" would help here.

The second problem is that the Confirmed state is confusing to users and a bit redundant with the 'affects me too' function. I think given a well designed solution to the first problem, the Confirmed state could possibly just go away.

Jonathan Lange (jml) on 2011-06-20
tags: added: bug-lifecycle
Francis J. Lacoste (flacoste) wrote :

Escalated by Kate on the stakeholders mailing list.

Changed in launchpad:
importance: Low → Critical
tags: added: escalated
Francis J. Lacoste (flacoste) wrote :

Would like to see this deployed before Alpha 3 (Aug 4th)

Martin Pitt (pitti) on 2011-07-07
Changed in ubuntu:
milestone: oneiric-alpha-2 → oneiric-alpha-3
Gary Poster (gary) on 2011-07-13
Changed in launchpad:
assignee: nobody → Gary Poster (gary)
status: Triaged → In Progress
Gary Poster (gary) wrote :

We know Ubuntu wants this behavior. We are less confident that other projects will.

Francis suggested feature flags as an initial cut for a distinguishing mechanism. I think we could do this by, for instance, looking for a feature flag that specifies a comma-separated whitelist of projects that want this behavior. After this is deployed and configured for Ubuntu, we can then decide if we should apply this policy to all projects, if we should make it opt-in or opt-out, and if we should make it configurable.

A particularly nice thing about this approach is that we can deploy the change in a no-downtime deployment, as early as possible, for Ubuntu; and then other opt-in/opt-out choices that require a database change can be pushed out to a db change/downtime deployment.

Francis J. Lacoste (flacoste) wrote :

I'd rather suggest a boolean feature flag and then we use a custom scope selector. The scope handler (project:?) could take a comma list of project names.

That way we don't need custom flag parsing logic in the feature, and we have a reusable feature scope!

On Thu, Jul 14, 2011 at 6:43 AM, Francis J. Lacoste
<email address hidden> wrote:
> I'd rather suggest a boolean feature flag and then we use a custom scope
> selector.


> The scope handler (project:?) could take a comma list of
> project names.

I'd start with (perhaps pillar:) taking just one name and use multiple
rules to represent multiple things. Its what we've done for pageids
etc, and I don't think we'll be overwhelmed with projects wanting it
before we go full-on || option-in-project-config.

> That way we don't need custom flag parsing logic in the feature, and we
> have a reusable feature scope!


Martin Pool (mbp) wrote :

In implementation, please think about how the change of status will be
represented in the web ui and in email notifications. If it looks
like the particular user that checked 'affects' also changed the
status that might cause some confusion.

Perhaps the flag scopes should be "distribution:ubuntu" and
"project:bzr" just to be a little more clear.

Robert Collins (lifeless) wrote :

On Thu, Jul 14, 2011 at 11:47 AM, Martin Pool <email address hidden> wrote:
> Perhaps the flag scopes should be "distribution:ubuntu" and
> "project:bzr" just to be a little more clear.

We have a single unified top levelnamespace, it would be overly
precise to insist on type safety there.

Gary Poster (gary) wrote :
Download full text (3.4 KiB)

In regards to the feature flag, I had considered that general approach. The problem is that feature flags are for page context. That's not what we are interested in here: we are interested in bug tasks. For any bug modified, we will need to iterate over its bug tasks to see if the bug is pertinent. We could force feature flags to have this connotation as well, but it would be different than what devs would generally expect a feature flag to do: if I say "project:launchpad" for a scope then I would expect that to be pertinent to be pages within a pillar. Making it mean both would be surprising in a bad way, IMO. Therefore, I was thinking of the simple default scope with comma-delimited values for distributions and projects. I presented this to Graham and Francis over the phone, and they agreed.

I had a pre-imp with Graham. The following are what we agreed.

 * Contrary to a strict interpretation of the bug description, but following the "Confirmed" policy from https://wiki.ubuntu.com/Bugs/Status , a bug task should move from "New" to "Confirmed" if there is a single duplicate bug *filed by another person or affecting more than one person* (duplicate bugs >= 1), or if a bug affects more than one person (affects >= 2).
 * OPEN QUESTION: if a bug has been explicitly moved back to "New," should we not make the change--that is, should we honor explicit moves back to "New"? Given current feedback on related issues, I believe the answer is that we should still make the change, ignoring any previous explicit moves. That would certainly be easier.
 * [@Martin] the Launchpad Janitor will be the person who moves the status from "New" to "Confirmed," as recorded in logs and mail.
 * We will decide whether or not we need to change the value under these circumstances, hopefully using event listeners.
   * Duplicate is added. According to Graham we fire events in some but not all of the pertinent cases at this time.
   * "Also affects" is added. Graham thinks we do not fire events for this at all right now.
   * When a bug task is added. Note that in this case we will want the bug to start in the "New" state but then moved to "Confirmed" within the same transaction (but with a separate log entry and notification). That might be a bit tricky.
 * Similarly, for as long as following this policy is optional, here are some reaction thoughts.
   * When a bugtask changes targets (we may be moving from a target that does not participate to one that does) we should react.
   * We should NOT try to undo a move from new to confirmed if the bug task switches targets to a project that does not participate.
 * The feature flag will be able to specify projects and distributions to participate. Packages in a distribution will be affected by the configuration for the distribution. Milestone bugtasks will be affected by the associated project etc.

In a follow-up with Francis, I received another clarification.

 * We plan to roll this behavior out to *all* projects/distros, without a configuration option. The feature flag is just there to help us qa and test, and we should include a "*" option for the feature flag so that we can open the feature up to all pr...


Martin Pool (mbp) wrote :

> The problem is that feature flags are for page context.

[aside] That's generally true at the moment, but it's not the
intention. We have flags that are used in cron scripts (iirc) and
soon we will have flags active for incoming email. It makes sense to
have flags that can be turned on and off depending on the context of
what Launchpad is doing in a broader sense than the page id. It may
take more infrastructural work to make that easy.


Gary Poster (gary) wrote :

I have a branch in which this is all working. The last step is to make adding a bug duplicate or saying "me too" via AJAX automatically update the bugtask statuses. I hope to do that tomorrow. If I don't have it working in a few hours, I will land a branch with the server-side functionality for this bug, and open a new bug for the AJAX synchronization.

Launchpad QA Bot (lpqabot) wrote :
tags: added: qa-needstesting
Changed in launchpad:
status: In Progress → Fix Committed
Gary Poster (gary) on 2011-07-20
tags: added: qa-ok
removed: qa-needstesting
Gary Poster (gary) wrote :

This is ready for deployment (and should be deployed in the next four hours).

In order to turn on the behavior for ubuntu and launchpad, we will need to add these feature rules:

bugs.autoconfirm.enabled_distribution_names default 1 ubuntu
bugs.autoconfirm.enabled_product_names default 1 launchpad

A reasonable commit message for the LOSAs would be "turn on bugtask autoconfirm for launchpad and ubuntu."

If, as we expect, we decide to roll this out for all distros and projects, we will change those rules to the following:

bugs.autoconfirm.enabled_distribution_names default 1 *
bugs.autoconfirm.enabled_product_names default 1 *

As you might expect, a reasonable commit message for the LOSAs would be "turn on bugtask autoconfirm for all distributions and projects."

This should be rolled out now. Not sure if you want to mark it as 'fix released' until you set the feature flags, so I am not touching it :)

Gary Poster (gary) wrote :

I'm not quite sure on whether "Fix Released" is appropriate once we have this released exclusively to ubuntu and launchpad (feature flaged), but that's where we are, and that's what I'm doing.

Ubuntu should now have the requested behavior.

Changed in launchpad:
status: Fix Committed → Fix Released
Kate Stewart (kate.stewart) wrote :

I'm thinking that the status should be Fix Released for Ubuntu, and Fix Committed for the general problem, shouldn't it?

Also, just to confirm, this will trigger from now on, but won't address the historical ones?

(and THANK YOU!!! for getting it in)

Gary Poster (gary) wrote :

@Kate: I've marked the statuses as you suggest. You are correct, this will not address historical "New" bug tasks that already have multiple people affected--but even for these old bugs, the first time a new person is affected, the code will be triggered and the status will move to "Confirmed".

Changed in ubuntu:
status: Triaged → Fix Released
Changed in launchpad:
status: Fix Released → Fix Committed
Francis J. Lacoste (flacoste) wrote :

@Kate, it would be possible to write an API script to migrate all historical bugs.

Gary Poster (gary) wrote :

This is fix-released for Launchpad. We will remove either the feature flags or the functionality based on the discussion Matthew Revell and Kate have about this. That is tracked separately in bug 820442.

Changed in launchpad:
status: Fix Committed → Fix Released
Francis J. Lacoste (flacoste) wrote :

An API script which will confirm any New bugs with the same criteria is available in lp:~flacoste/+junk/lp-bugs-tools. It's lp-auto-confirm.py

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers