keeping track of regressions during the development cycle
steve.langasek at ubuntu.com
Wed Jul 23 18:13:32 BST 2008
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
More information about the ubuntu-devel