Launchpad itself

Bug #777874
Comment #11

Comment 11 for bug 777874

Revision history for this message

Gary Poster (gary) wrote on 2011-07-14:

#11

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 projects (and revert it if there are problems). Launchpad has a position that we control the definition and workflow of statuses, and this is our decision of how we want to define the statuses. We will expect to take some flak over the change.

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 projects (and revert it if there are problems).  Launchpad has a position that we control the definition and workflow of statuses, and this is our decision of how we want to define the statuses.  We will expect to take some flak over the change.