keeping track of regressions during the development cycle

[Steve Langasek]

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.

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek at ubuntu.com                                     vorlon at debian.org