launchpad-dev team mailing list archive

[Jonathan Lange <jml@xxxxxxxxxxxxx>]

On Mon, Oct 12, 2009 at 4:59 PM, Tom Berger <tom.berger@xxxxxxxxxxxxx> wrote:
> 2009/10/12 Jonathan Lange <jml@xxxxxxxxxxxxx>:
>> 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