Re: Talking about "Where We Are At"

[Gregory Leblanc <gleblanc linuxweasel com>]

On Sun, 2003-01-19 at 06:50, Andrew Sobala wrote:
> Well, I've been thinking about bugs in the post-2.2.0 timeframe, and I
> thought I'd raise some issues here now. Of course the most important
> thing to do now is the pre-2.2.0 things Luis raised in his e-mail, but
> nevertheless this needs discussing eventually.
> 
> * New keyword
> 
> We need GNOMEVER2.2, technically as soon as we release, preferably
> sooner :-)

Nothing should be assigned to this bug until 2.2 is released though.  We
should probably also change the bug entry JS to use the 2.2 keyword as
soon as 2.2 is released.

> * GNOMEVER accumulating
> 
> Some bugs are triaged GNOMEVER2.0,GNOMEVER2.1,GNOMEVER2.3. Which is
> ridiculous. I propose defining keywords as follows:
[snip]

Huh, I was already using them this way, I sort of figured that everyone
was.  Perhaps we just need to update the descriptions.  Having a list of
all of the bugs with multiple GNOMEVER* keywords would be handy for bug
day, as would a list of all of the ones with a GNOMEVER2.0 keyword,
since we ought to see which of those are still in 2.1.  (Then again, I
don't run bug day, so that's all up to you folks who do)

> * TARGET
> 
> In the post-2.0 cycle, we had the equivalent :) of
> TARGET2.0.1,TARGET2.0.2,TARGET2.0.3..... while this sort of makes sense,
> it means we use loads of keywords for something conceptually simple -
> big bugs need fixing. And every "dot dot" release, unfixed bugs in this
> list needed their keywords changing.

I thought the idea was that the TARGET* bugs -were- going to get fixed
for that release, if at all possible.  If they get punted, then yeah,
they need their target changed.

> Priorities would be a simple way to do this. If bugs that should be
> fixed in the 2.2 cycle get TARGET2.2.x (judging from the
> bug_squad->bugsquad renaming mess, if could cause problems if we rename
> TARGET2.2.0->TARGET2.2.x, but with only 40ish bugs we could do it sanely
> via the web). Then bugs that should be fixed by "The next release" get
> "Urgent" or "Immediate" priorities and we can filter a "Must fix" list
> based on that.

Hmm, this certainly sounds OK to me.  Other thoughts?

> * ui-review
> 
> FWIW, I just shunted all ui-review bugs to 2.3 because they will break
> ui freeze.

I don't know that this is the right solution.  The release team website
says -nothing- about post 2.2.0 releases.  That either means that you
can't change anything for any releases past 2.2.0 (which seems silly,
changes are the point of making a release), or that we need some more
information about what "freezes" are in effect.  From what I remember of
the 2.0.x release cycle, some UI changes did go in on the 2.2.x where x
> 0 releases.  Does somebody want to mail the release team and/or DDL
for some clarification?  If not, I can send the mail.
	Greg

-- 
Gregory Leblanc <gleblanc linuxweasel com>