Doh I send it to Jelmer only, sorry! Here goes again: On the one hand, good idea to conform to the practise other bzr projects have. On the other hand, the current state feels _very_ logical to me so my personal opinion would be to keep the current state.
Switching all bugs to fix released is a bit of a pain to do at release time. But on the other hand, if Debian/Ubuntu packagers are subscribed to a certain bug that is reported as well in their package with the current release they are notified at release time the bug fix is available in a stable release. The Ubuntu documentation explains: https://wiki.ubuntu.com/Bugs/Status Fix Committed: * For a bug task about an upstream project: the fix is in CVS/SVN/bzr or committed to some place * For an Ubuntu package: the changes are pending and to be uploaded soon (it's what PENDINGUPLOAD was in Bugzilla) * Fix Committed is also used when an updated package exists in a -proposed repository i.e. hardy-proposed * Fix Committed is not to be used when a patch is attached to a bug Fix Released: * For a bug task about upstream projects: a release tarball was announced and is publicly available * For package maintainers, a fix was uploaded to an official Ubuntu repository o This does not include -proposed i.e. hardy-proposed o Please don't hesitate to add a changelog as a comment, so people know what to look out for * If a bug is fixed in the current development branch, that is good enough for Fix Released. If the bug also needs to be fixed in a stable release, use the "Target to release" link to nominate it for that release. So fix in trunk is good enough for Fix Released I think? Regards, Jasper
signature.asc
Description: PGP signature
-- bzr-gtk mailing list [email protected] Modify settings or unsubscribe at: https://lists.canonical.com/mailman/listinfo/bzr-gtk
