On Mon, Oct 12, 2009 at 4:59 PM, Tom Berger <[email protected]> wrote: > 2009/10/12 Jonathan Lange <[email protected]>: >> Hello Launchpadders, >> >> I just had a chat with Brad, who managed the last release of >> Launchpad, about the way we go about managing the release. >> >> Currently we have a wiki page called "CurrentRolloutBlockers"[1], and >> we use this to track any bugs / patches that people claim are >> absolutely critical to the release. We don't like using wiki pages >> though, and in this case think that we can dispense with the wiki page >> and just use Launchpad. >> >> Here's what we're going to try. Instead of tracking blockers on a >> separate page, we'll track them on the milestone.[2] Any bug that's on >> the milestone and open on the Monday after we've frozen the code will >> be considered a potential release blocker. Those that aren't deemed to >> be blockers will be shoved off the milestone. Those that are will be >> monitored there until they are Fix Committed. >> >> This process will work _so_ much better if developers close bugs >> promptly and swiftly retarget bugs that have missed the milestone and >> aren't release critical. Please do that. >> >> Any comments, questions or objections? > > That's a really good plan. It will be great to not have to use the > wiki. One suggestion: Maybe limit the bugs on the milestone that are > considered blockers to open bugs with Critical importance? >
That's a good suggestion. It raises two questions, neither of which I know the answer to: - why would there open bugs on the milestone after we've frozen the code? - why would a non-Critical bug be considered as release-critical? jml _______________________________________________ Mailing list: https://launchpad.net/~launchpad-dev Post to : [email protected] Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
