launchpad-dev team mailing list archive
-
launchpad-dev team
-
Mailing list archive
-
Message #01316
Re: [RFC] Change to release management process
On Mon, Oct 12, 2009 at 5:15 PM, Graham Binns <graham@xxxxxxxxxxxxx> wrote:
> 2009/10/12 Jonathan Lange <jml@xxxxxxxxxxxxx>:
>> 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?
>
> Because there's a finite amount of time in a developer's day, and
> sometimes we think we're able to get things finished but life gets in
> the way.
>
I haven't been as clear as I ought. Sorry.
In the plan I described, I had meant for the RM to go through the
milestone at some time shortly after code freeze and move the bugs
that are:
a) on the milestone
b) open
c) not release critical
off the milestone. I say "shortly after" to allow developers time to
retarget the bugs themselves.
My question, now that I think about it, would have been better phrased
as "What's the point of having open, non-release-critical bugs on the
milestone after code freeze?". I think the answer is "there is none".
>> - why would a non-Critical bug be considered as release-critical?
>
> Because importance can change based on context. So, the bug for, say,
> adding certain configuration items to the production configs is High
> during the cycle, but it becomes critical to land before release
> otherwise the production appservers won't start up (or something
> equally dramatic).
>
So we could, in theory, upgrade the bug to Critical if that situation arises?
jml
Follow ups
References