Dealing with bugs that are only in trunk.

Aaron Bentley aaron.bentley at canonical.com
Thu Dec 12 19:14:11 UTC 2013


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 13-12-12 01:09 PM, Curtis Hovey-Canonical wrote:
> I think the number of open critical and high bugs is inflated. The 
> open critical bugs are an incentive to release soon, but many of
> the critical bugs were really closed the moment trunk merged the
> fix.

I think you mean open, but fix-committed here, right?  Because open
bugs is not traditionally a good reason to release.

> We close bugs when we know we have delivered a fix to the affected 
> users. Our practice of targeting to milestones/releases is a
> little misleading if we assume the bug was in the previous release.
> Some bugs only affect users of trunk, such as developers and
> testers.

I suppose it is legitimate that if a bug was never actually released,
then we shouldn't have to wait for a release in order to mark it
closed.  I think the "Fix released" terminology confuses the issue.

Perhaps we should tag un-released bugs specially when they're
reported, so that we know to mark them fix-released instead of
fix-committed when they are fixed.

> There are several bugs targeted to 1.17.0 that were introduced in 
> trunk and were fixed a few days later. I think these bugs are fix 
> released since developers and CI are no longer affected. I want to 
> close the bugs. It would then be easy to see which critical bugs
> we want to release to users.

> I have previously downgraded bugs to high when the fix hit trunk,
> or if the fix was delivered in a stable point release. I don't like
> this practice because it looks like critical importance was used 
> deceptively.

I guess I think of critical as a potential release-blocker.  Once the
release is no longer blocked, it may not be critical.

> Since we review all the open bugs to write release notes, we are
> constantly re-reading bugs that don't affect anyone who will get
> the release.

Seems like the pragmatic thing to do.

Aaron

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlKqCwMACgkQ0F+nu1YWqI1eNQCffyQFyQgxtBqUq3VZ6q85wK+K
MckAn0IG/gHiK2pYUlIZM9h3XVd8tvQs
=vuBO
-----END PGP SIGNATURE-----



More information about the Juju-dev mailing list