keeping track of regressions during the development cycle

[Matt Zimmerman]

On Wed, Jul 23, 2008 at 10:13:32AM -0700, Steve Langasek wrote:
> On Tue, Jul 22, 2008 at 06:38:17PM +0100, Matt Zimmerman wrote:
> > On Thu, Jul 17, 2008 at 11:21:51AM +0100, Steve Langasek wrote:
> > > From time to time in the course of a development cycle, it's necessary to
> > > make changes of a temporary nature that should be revisited and (hopefully)
> > > reverted before the final release.  In order for the project as a whole to
> > > be better able to track such changes, it would be a good idea to have a
> > > consistent policy for how these bugs will be represented in Launchpad.
> 
> > > The proposed policy is that these bugs should be tracked as release-critical
> > > bugs: nominated for the release, and targeted to the milestone before which
> > > the change needs to be reviewed.  This policy has been documented on
> > > <https://wiki.ubuntu.com/UbuntuDevelopment> and on
> > > <https://wiki.ubuntu.com/RCBugTargetting>.
> 
> > > As usual, please send any feedback to ubuntu-devel / ubuntu-devel-discuss.
> 
> > What about regressions which aren't introduced intentionally?  I think we
> > should have a standard way of keeping track of those (even if it's as simple
> > as a tag), and a process by which we decide which ones should become
> > release targets.
> 
> I think it would be reasonable to consider these all release-critical by
> default, and therefore have them nominated for the release; it would then be
> the release team's responsibility (perhaps with the aid of the QA team?) to
> cull this list by tagging bugs 'wontfix', and opening a task on the
> newly-created ubuntu-release-notes project as appropriate.

I'm not sure what the ratio of regressions is on incoming bugs, or how much
effort it will be to identify them, but this sounds like a reasonable
starting point.  This will need to be documented and the triage teams
informed of the policy in order to try it out.

-- 
 - mdz