Improving Release Tracking (post 0.7)
Daniel Boelzle
on this wednesday's status call, I asked how we should proceed tracking
the next release after 0.7 w.r.t. bugzilla.
We've used the blocking flag for 0.7 to focus on what we want to do,
what's blocking and what would be great, and that has caused some
discussion and confusion, because people were not used to use that flag
that way. Thus I think it's worth to rethink that handling for post 0.7
and look for different options:
1) We use a wanted-flag (e.g. 0.8-wanted) to tell people what's
wanted/planned/important, so individuals could easily jump in and know
what's relevant for the next release. Proposols are acknowledged or
denied by the release drivers. Blocking flags may be used towards
finalization of the release, to tag the "must have" bugs. IMO there is
often only a subtle difference between wanted and blocking, but this
distinction makes sense.
2) We use the "target milestone" field to state what we want for the
next release. While not so prominent as flags, it offers us the
possibility to plan (in a very lightweight manner) what we want for the
upcoming releases, not only the next one. Blocking flags may be used
towards finalization of the release, to tag the "must have" bugs.
3) We use a collective release bug, which depends on all wanted bugs.
Blocking flags may be used towards finalization of the release, to tag
the "must have" bugs.
4) A mix of 1) and 2). We plan larger topics (e.g. roadmap items) via
target field, but use flags for release tracking (e.g.
"next-release-wanted" and "next-release-blocking").
5) A mix of 2) and 3). We plan larger topics (e.g. roadmap items) via
target field, but use a collective bug for release tracking (e.g.
"next-release-wanted" and "next-release-blocking").
Personally, a wanted-flag attracts me most, because individuals could
formally suggest bugs, and prefer 4) for now.
Feedback appreciated, especially from the QA guys,
thanks and best regards,
Daniel
Michiel van Leeuwen
> 1) We use a wanted-flag (e.g. 0.8-wanted) to tell people what's
> wanted/planned/important, so individuals could easily jump in and know
> what's relevant for the next release. Proposols are acknowledged or
> denied by the release drivers. Blocking flags may be used towards
> finalization of the release, to tag the "must have" bugs. IMO there is
> often only a subtle difference between wanted and blocking, but this
> distinction makes sense.
For the calendar team, is there much value in saying that a bug is
'wanted'? I mean, the team is not that big, and is likely quite busy
with working on the real blocker bugs. I don't think that there is
anybody who is bored, and thus will need a list of 'wanted' bugs to find
something to work on. (this is mostly based on the current use of the
blocking0.7? flag, which I think you want to replace with the wanted flag)
> 3) We use a collective release bug, which depends on all wanted bugs.
> Blocking flags may be used towards finalization of the release, to tag
> the "must have" bugs.
That's what was used in the past, for old mozilla releases. That had
serious downsides, and thus flags were invented. So please don't go back
to huge tracking bugs.
> 4) A mix of 1) and 2). We plan larger topics (e.g. roadmap items) via
> target field, but use flags for release tracking (e.g.
> "next-release-wanted" and "next-release-blocking").
What is the difference between those two categories? If something is on
the roadmap, doesn't it block the release?
Talking about release tracking: for 0.7, in a lot of bugs there was a
comment like: "nobody is working on this -> not blocking". I really
don't understand that. IMO the blockingness of a bug should be based on
the impact of the bug. Then, if a bug blocks, developers should start
working on them. That's how you assure quality. If you let the
individual developers decide on what to work on, and thus on what
blocks, how can you assure that the important-but-annoying-to-work-on
bugs ever get fixed?
Michiel
Simon Paquet
>Talking about release tracking: for 0.7, in a lot of bugs there was a
>comment like: "nobody is working on this -> not blocking". I really
>don't understand that. IMO the blockingness of a bug should be based on
>the impact of the bug. Then, if a bug blocks, developers should start
>working on them. That's how you assure quality. If you let the
>individual developers decide on what to work on, and thus on what
>blocks, how can you assure that the important-but-annoying-to-work-on
>bugs ever get fixed?
Since I made some of the comments that you speak of, I'll chime in here.
IMO there's always a tradeoff between releasing on time and releasing
with a certain degree of quality. Having a strictly time-based release
will certainly degrade quality, because important bugs that are found
late in the game will not be fixed. Having a strictly quality-based
release will in many cases lead to releases that come weeks and months
after their initially scheduled release date.
We have suffered more from the latter than the former in the past
especially during the 0.5 release cycle. Therefore for 0.7 the rationale
was that we'd really like to release on time for once and not 2-3 months
late as was the case with 0.5. We haven't really pulled that off, as you
probably have noticed (we're currently 2-3 weeks late regarding the RC1)
but we may yet pull this off, if no big blockers arise after the RC1 is
pushed out to the masses as our scheduled release date of 0.7 is
mid-October.
We can certainly discuss the specifics of some of the bugs that got
pulled from the list of blockers, but it wasn't as simple as you
described it.
All the bugs where I removed the blocking flag had the blocking+ flag set
for a few weeks or even longer. And the rationale was not just "nobody is
working on this" but more like "nobody has been working on this, even
when it was on the blocker list and we're running out of time".
I'm fine with being the bad guy on bugs like this, because as a
non-developer I notice the tendency to squeeze just one more bug into a
release with many developers and I try to at least counter-balance that a
bit.
Simon
--
Calendar l10n coordinator
Calendar Website Maintainer: http://www.mozilla.org/projects/calendar
Calendar developer blog: http://weblogs.mozillazine.org/calendar
Daniel Boelzle
> Daniel Boelzle wrote:
>> 1) We use a wanted-flag (e.g. 0.8-wanted) to tell people what's
>> wanted/planned/important, so individuals could easily jump in and know
>> what's relevant for the next release. Proposols are acknowledged or
>> denied by the release drivers. Blocking flags may be used towards
>> finalization of the release, to tag the "must have" bugs. IMO there is
>> often only a subtle difference between wanted and blocking, but this
>> distinction makes sense.
>
> For the calendar team, is there much value in saying that a bug is
> 'wanted'? I mean, the team is not that big, and is likely quite busy
> with working on the real blocker bugs. I don't think that there is
> anybody who is bored, and thus will need a list of 'wanted' bugs to find
> something to work on. (this is mostly based on the current use of the
> blocking0.7? flag, which I think you want to replace with the wanted flag)
Actually there has been discussion/confusion about why we've used the
blocking-flag to also express what we want to do and not only for
serious release stoppers. My primary motivation for that has been to get
rid of those next release wiki pages, but use bugzilla to cover what's
wanted for the next release: it ends up in bugs anyway.
I agree that developers should know what's relevant, but it's really
helpful having a prominent flag to stay focussed. Moreover it's easier
for non-developers to see whether their favourite bug will be fixed soon
and vote/propose it for the next release.
>> 3) We use a collective release bug, which depends on all wanted bugs.
>> Blocking flags may be used towards finalization of the release, to tag
>> the "must have" bugs.
>
> That's what was used in the past, for old mozilla releases. That had
> serious downsides, and thus flags were invented. So please don't go back
> to huge tracking bugs.
>
>> 4) A mix of 1) and 2). We plan larger topics (e.g. roadmap items) via
>> target field, but use flags for release tracking (e.g.
>> "next-release-wanted" and "next-release-blocking").
>
> What is the difference between those two categories? If something is on
> the roadmap, doesn't it block the release?
Using a wanted/blocking flag is supposed to be used only for the next
release whereas the target field could be used for further releases, not
only the next one.
> Talking about release tracking: for 0.7, in a lot of bugs there was a
> comment like: "nobody is working on this -> not blocking". I really
> don't understand that. IMO the blockingness of a bug should be based on
> the impact of the bug. Then, if a bug blocks, developers should start
> working on them. That's how you assure quality. If you let the
> individual developers decide on what to work on, and thus on what
> blocks, how can you assure that the important-but-annoying-to-work-on
> bugs ever get fixed?
Simon has commented on that and I second his opinion. It's a trade-off
between quality and schedule. IMHO *both* aspects seriously affect
satisfaction.
thanks for your comments, regards,
Daniel
Michiel van Leeuwen
> And on the seventh day Michiel van Leeuwen spoke:
It wasn't the seventh day, but who cares ;)
> IMO there's always a tradeoff between releasing on time and releasing
> with a certain degree of quality.
That's very true. So a decision needs to be made if releasing on time is
more important, or if quality is. To me, quality wins here, for two reasons:
1: a month or so after the release, whether or not the release was on
time doesn't really matter any more. People then only have to work what
was released, and then the quality matters.
2: for the impatient, there are new builds every day. There isn't much
sense in just picking one daily build as the release. A release must
have value over the daily builds. Quality is that value.
So I vote for a quality based release. I know it can't be perfect,
because that would take an infinite amount of time. There is still a
trade-off, but it can be shifted towards the quality.
> Having a strictly time-based release
> will certainly degrade quality, because important bugs that are found
> late in the game will not be fixed.
Neither are long standing bugs, like bug 308538. That has seen quite
some switching from in its blocking flags.
> All the bugs where I removed the blocking flag had the blocking+ flag set
> for a few weeks or even longer. And the rationale was not just "nobody is
> working on this" but more like "nobody has been working on this, even
> when it was on the blocker list and we're running out of time".
So? If the blocking+ list is still long, the developers were busy on
other bugs. They will go and look at the bugs when the list get shorter.
They have to, if they ever want to release.
> I'm fine with being the bad guy on bugs like this, because as a
> non-developer I notice the tendency to squeeze just one more bug into a
> release with many developers and I try to at least counter-balance that a
> bit.
That's not really what happened. Bugs were on the list for quite a while
when they got removed. They were never squeezed in.
Michiel
Michiel van Leeuwen
> Actually there has been discussion/confusion about why we've used the
> blocking-flag to also express what we want to do and not only for
> serious release stoppers. My primary motivation for that has been to get
> rid of those next release wiki pages, but use bugzilla to cover what's
> wanted for the next release: it ends up in bugs anyway.
That's a good idea. Let's not split the information over too many places.
> I agree that developers should know what's relevant, but it's really
> helpful having a prominent flag to stay focussed. Moreover it's easier
> for non-developers to see whether their favourite bug will be fixed soon
> and vote/propose it for the next release.
MY point was more on bugs that were marked as blocking?. In practice,
that means that they won't get fixed. When the blocking+ list is empty,
the release will happen. So I think that there isn't much use in keeping
a list of bugs that one can work on when bored (if I may call it that
way), simply because nobody was bored. There is more then enough work
for the small team.
Michiel
Clint Talbert
confusion that ensued with the 0.7 release.
As I've followed this discussion and the phone calls, I think there are
a couple of goals here:
Goal 1: Do NOT have two separate release tracking forums. (i.e. wiki and
bugzilla)
Goal 2: Have a means so that people can easily track "important bugs
that we don't have time/people to address".
Goal 3: Clarify the use of the blocking flag.
== About "Goal 2" ==
This is what the blocking? became. It became something of a means to
keep track of bugs that we thought were important enough that we didn't
want to lose during the course of 0.7. This is *not* what the blocking
flag was intended for, and it caused confusion.
To keep track of these "Goal 2" bugs, I think a wanted flag is overkill.
Here's why: Try explaining to a new person whether their bug should
set the wanted? or the blocking? or both? Furthermore, who has cycles
to triage both the blocking? and the wanted? bugs? That's a mess
waiting to happen in my book.
It seems to me that the intention of "Goal 2" bugs is really a way to
share a query of "important stuff that we need to do sooner rather than
later" among the developers and would-be developers. Therefore, I think
some kind of whiteboard flag would be sufficient for that.
== My Proposal ==
Goal 1: Keep everything in bugzilla, but create a wiki tracking page
with the proper bugzilla queries, like we did for 0.7. However unlike
0.7, make that page more prominent.
Goal 2: Use a whiteboard flag, maybe [wanted0.8] that we can set as part
of triage, and that we can also make a query for so that we can point
new dev's or bored devs (I don't think we have bored devs though) to
when they need something to do.
Goal 3: Use blocking? **only** when asking if a bug should block a
release. Use blocking+ **only** when the bug should block the release.
This time, unless we are about to slip more than a year, I recommend
that we do **not** remove blocking+ bugs from the list without fixing
them. This is because we are nearing 1.0, and we need the quality to
drastically improve during the 0.8 release. I prefer 0.8 to be late and
0.9 and 1.0 to be "on time".
This is also because really, if we want to ship a good 1.0 release, then
0.8 should be the last "new feature" release. 0.9 Should be bugfixes
and UI polish, and 1.0 should be only bugfixes. That's how I see it,
feel free to disagree.
== Target Milestone ==
If people would find that useful, then go for it. But, I make the same
caveat that I just said above: 0.8 has to be the last feature release.
So, pushing stuff on to the mythical future release is not going to buy
us anything but further delay. I prefer we take that delay in 0.8 and
do two quicker 0.9 and 1.0 releases with complete features and only polish.
So, I don't really find the target milestone to be that useful, unless
you want to use it to place bugs into buckets of when we intend to fix
them. But, then couldn't you also just use a [wanted0.9] or [wanted1.0]
whiteboard flag too?
== What about both [wanted0.8] and blocking? ==
Can something be both wanted and blocking? I think this is where we
really got ourselves confused with 0.7. For 0.8 I think we should make
a clear distinction between the "Goal 2" bugs and the "blocking release"
bugs for 0.8. I assert that a bug can be [wanted0.8] and blocking? But,
if that bug gets blocking+ then it CAN NOT have [wanted0.8] set on it.
Why? Because if the bug is blocking+ then it does not fit the criteria
of "something we want in the release but don't have time/people for".
Saying that we are going to make it blocking+ means that we are going to
fix it, and we'll either reallocate people/time or we'll recruit/beg for
help, but we'll get it fixed before 0.8 ships.
== Disclaimer ==
I'm not mandating this policy, but suggesting it. So, let's tear into it
and see what will work, what won't. I **do** want this question
completely resolved **before** the first flag is set and the first bug
is triaged for 0.8.
Clint
OB
1)blocking+ serious bug or major loss of function blocking release.
Calendar won't ship without it
blocking? candidates for blocking release.
2)Target milestone and priorities can also be used (based on
roadmap-like for Firefox- taken from
http://wiki.mozilla.org/Firefox3/Firefox_Requirements):
Target milestone 0.8 = a bug that is on roadmap for 0.8
P1 Mandatory - The set of features required as a minimum for this
release to be complete. The product will not ship without these.
P2 Highly Desirable - A key feature that will make the product more
complete, has great benefits to the end-user and major strategic impact.
P3 Nice to Have - Lowest priority feature that may be incorporated,
dropping first in favour of delivering P2 items.
Omar
Simon Paquet
First of all, thanks for starting this discussion again.
>All right, we need to figure this out because none of us want the
>confusion that ensued with the 0.7 release.
>
>As I've followed this discussion and the phone calls, I think there are
>a couple of goals here:
>
>Goal 1: Do NOT have two separate release tracking forums. (i.e. wiki and
>bugzilla)
>
>Goal 2: Have a means so that people can easily track "important bugs
>that we don't have time/people to address".
>
>Goal 3: Clarify the use of the blocking flag.
I agree.
>== About "Goal 2" ==
>This is what the blocking? became. It became something of a means to
>keep track of bugs that we thought were important enough that we didn't
>want to lose during the course of 0.7. This is *not* what the blocking
>flag was intended for, and it caused confusion.
Yes, we did poorly there. Seeing how bad we slipped with 0.5 party due to
poor tracking of important bugs, we were probably a little bit too
extreme for 0.7.
>To keep track of these "Goal 2" bugs, I think a wanted flag is overkill.
> Here's why: Try explaining to a new person whether their bug should
>set the wanted? or the blocking? or both? Furthermore, who has cycles
>to triage both the blocking? and the wanted? bugs? That's a mess
>waiting to happen in my book.
Exactly my point. This is confusion waiting to happen.
>== My Proposal ==
>Goal 1: Keep everything in bugzilla, but create a wiki tracking page
>with the proper bugzilla queries, like we did for 0.7. However unlike
>0.7, make that page more prominent.
>
>Goal 2: Use a whiteboard flag, maybe [wanted0.8] that we can set as part
>of triage, and that we can also make a query for so that we can point
>new dev's or bored devs (I don't think we have bored devs though) to
>when they need something to do.
>
>Goal 3: Use blocking? **only** when asking if a bug should block a
>release. Use blocking+ **only** when the bug should block the release.
Fully agreed.
>This time, unless we are about to slip more than a year, I recommend
>that we do **not** remove blocking+ bugs from the list without fixing
>them.
Nope. We've have a bad history of elevating too many bugs to blocker
status, although some bugs clearly aren't. Otherwise I'd never have
gotten my reputation with regards to blockers.
Bugs that may look severe at first, may not look the same a few weeks
later. Removing bugs from the blocker list *MUST* be possible.
>This is because we are nearing 1.0, and we need the quality to
>drastically improve during the 0.8 release. I prefer 0.8 to be late and
>0.9 and 1.0 to be "on time".
I again do not agree. We (as a project) still suffer from our bad
reputation earned during the 0.2 and 0.3 days. I really like our current
release schedule with 3 releases a year (3 months of development and 1
month of stabilization). We should not lose that now. If we cannot fit
enough bugfixes into such a schedule until 1.0, then we need to put in
additional releases (e.g. 0.8.5, 0.9.5, whatever) but people can and
should expect our next release to appear somewhere in February 2008.
>This is also because really, if we want to ship a good 1.0 release, then
>0.8 should be the last "new feature" release. 0.9 Should be bugfixes
>and UI polish, and 1.0 should be only bugfixes. That's how I see it,
>feel free to disagree.
I do. If we can fix all our major features for 0.8, great. If we can't
then we need another feature release (e.g. 0.8.5).
>== What about both [wanted0.8] and blocking? ==
>Can something be both wanted and blocking?
Yes.
>I think this is where we really got ourselves confused with 0.7. For 0.8
>I think we should make a clear distinction between the "Goal 2" bugs and
>the "blocking release" bugs for 0.8. I assert that a bug can be
>[wanted0.8] and blocking? But, if that bug gets blocking+ then it CAN NOT
>have [wanted0.8] set on it.
Agreed.
Daniel Boelzle
> As I've followed this discussion and the phone calls, I think there are
> a couple of goals here:
>
> Goal 1: Do NOT have two separate release tracking forums. (i.e. wiki and
> bugzilla)
>
> Goal 2: Have a means so that people can easily track "important bugs
> that we don't have time/people to address".
Yes. This has already been the primary 0.7 reason to track 0.7 like we
did, using a flag.
> Goal 3: Clarify the use of the blocking flag.
That indeed caused confusion, especially on mvl.
> == About "Goal 2" ==
> This is what the blocking? became. It became something of a means to
> keep track of bugs that we thought were important enough that we didn't
> want to lose during the course of 0.7. This is *not* what the blocking
> flag was intended for, and it caused confusion.
>
> To keep track of these "Goal 2" bugs, I think a wanted flag is overkill.
> Here's why: Try explaining to a new person whether their bug should
> set the wanted? or the blocking? or both? Furthermore, who has cycles
> to triage both the blocking? and the wanted? bugs? That's a mess
> waiting to happen in my book.
That has been my point ever since we are discussing about using the
blocking flag to track the release for 0.7: IMO there's a floating
transition between "we plan this for the next release, we want it" and
"it blocks the next release". That has been the reason for me to flag
"nice to have bugs" as proposed blocking (?), and "we really need this
resp. it plain blocks" as blocking granted (+).
But I've been convinced that this scheme deviates from common usage in
other mozilla products on bugzilla and thus should not be continued.
> It seems to me that the intention of "Goal 2" bugs is really a way to
> share a query of "important stuff that we need to do sooner rather than
> later" among the developers and would-be developers. Therefore, I think
> some kind of whiteboard flag would be sufficient for that.
No, I don't think that's prominent enough, and more important: I'd like
to have an easy, but formal channel for outsiders to propose stuff for
0.8. A wanted-flag provides that.
> == My Proposal ==
> Goal 1: Keep everything in bugzilla, but create a wiki tracking page
> with the proper bugzilla queries, like we did for 0.7. However unlike
> 0.7, make that page more prominent.
I buy that, however I don't think that page has been under represented
in the past: It's our roadmap page. It's linked in almost every status
call agenda and on wiki. It could be linked better from the web pages,
though.
> Goal 2: Use a whiteboard flag, maybe [wanted0.8] that we can set as part
> of triage, and that we can also make a query for so that we can point
> new dev's or bored devs (I don't think we have bored devs though) to
> when they need something to do.
IMO not prominent enough, and IMO lacks a formal way to easily propose
bugs. Moreover the release drivers need to keep track on any change,
retriage that list over and over again, else it gets bloated (has no
focus). We need that cycles anyway.
> Goal 3: Use blocking? **only** when asking if a bug should block a
> release. Use blocking+ **only** when the bug should block the release.
Yes. Moreover I'd like to add "blocking bugs SHOULD have a responsible
assignee", else those put the release in danger.
> This time, unless we are about to slip more than a year, I recommend
> that we do **not** remove blocking+ bugs from the list without fixing
> them. This is because we are nearing 1.0, and we need the quality to
> drastically improve during the 0.8 release. I prefer 0.8 to be late and
> 0.9 and 1.0 to be "on time".
IMO you're calling the "trade-off between time-boxed and bug-free
releases" discussion. That has been extensively discussed in the past on
this forum. I second Simon's opinion.
> This is also because really, if we want to ship a good 1.0 release, then
> 0.8 should be the last "new feature" release. 0.9 Should be bugfixes
> and UI polish, and 1.0 should be only bugfixes. That's how I see it,
> feel free to disagree.
makes sense.
> == Target Milestone ==
> If people would find that useful, then go for it. But, I make the same
> caveat that I just said above: 0.8 has to be the last feature release.
> So, pushing stuff on to the mythical future release is not going to buy
> us anything but further delay. I prefer we take that delay in 0.8 and
> do two quicker 0.9 and 1.0 releases with complete features and only polish.
>
> So, I don't really find the target milestone to be that useful, unless
> you want to use it to place bugs into buckets of when we intend to fix
> them. But, then couldn't you also just use a [wanted0.9] or [wanted1.0]
> whiteboard flag too?
IMO the target milestone gives bug readers an *indication* when a
feature/bug is roughly planned to land; no more, no less.
> == What about both [wanted0.8] and blocking? ==
> Can something be both wanted and blocking? I think this is where we
> really got ourselves confused with 0.7. For 0.8 I think we should make
> a clear distinction between the "Goal 2" bugs and the "blocking release"
> bugs for 0.8. I assert that a bug can be [wanted0.8] and blocking? But,
> if that bug gets blocking+ then it CAN NOT have [wanted0.8] set on it.
>
> Why? Because if the bug is blocking+ then it does not fit the criteria
> of "something we want in the release but don't have time/people for".
Why can't wanted+ bugs have assignees working on it? That said, I
disagree to use wanted only for "something we want in the release but
don't have time/people for".
I'd say blocking is stronger than wanted, thus once a bug is blocking,
wanted is obsolete.
regards,
Daniel
Daniel Boelzle
...
> 2)Target milestone and priorities can also be used (based on
> roadmap-like for Firefox- taken from
> http://wiki.mozilla.org/Firefox3/Firefox_Requirements):
>
> Target milestone 0.8 = a bug that is on roadmap for 0.8
I agree, we should give bug readers a good indication when a feature/bug
is expected to land and should put the roadmap items into bugs.
> P1 Mandatory - The set of features required as a minimum for this
> release to be complete. The product will not ship without these.
> P2 Highly Desirable - A key feature that will make the product more
> complete, has great benefits to the end-user and major strategic impact.
> P3 Nice to Have - Lowest priority feature that may be incorporated,
> dropping first in favour of delivering P2 items.
I doubt that anybody (especially people from outside) have these
categories in mind when reading a bug.
regards,
Daniel
Pete
> To keep track of these "Goal 2" bugs, I think a wanted flag is
> overkill. Here's why: Try explaining to a new person whether their
> bug should set the wanted? or the blocking? or both? Furthermore,
> who has cycles to triage both the blocking? and the wanted? bugs?
For what it's worth, I really like the Wanted flag. It doesn't seem
like there are that many people who participate in the Calendar part of
Bugzilla, and I think that most of us know what it means and how to use
it. I think that it's a nice, simple way for us non-developers to
communicate our wishes with the calendar team, and it seems like some
developers like it to (I noticed a lot of use of it today with Simon and
Daniel).
I know that there are other ways to communicate this information, but
none seem as elegant. Users can vote for bugs, but we only get three
votes! (Plus the voting system is not really accurate because older
bugs will likely have more votes than newer bugs.) We can add a comment
to the bug (+1 for that!) but that clutters the bug and it's not easy to
track such comments. As far as using whiteboard flags, I for one don't
have the ability to add those to other people's bugs.
> Goal 1: Keep everything in bugzilla, but create a wiki tracking page
> with the proper bugzilla queries, like we did for 0.7.
+1
> This is also because really, if we want to ship a good 1.0 release,
> then 0.8 should be the last "new feature" release. 0.9 Should be
> bugfixes and UI polish, and 1.0 should be only bugfixes.
I don't see how you can stop adding features after 0.8 because there are
things that are supposed to be in the 1.0 release that are not done and
are not scheduled in the 0.8 roadmap. I generally agree with you, but
as other people have already suggested, maybe there have to be more
intermediate releases (0.8.5/0.8.6/0.8.7/etc.) and then follow your
suggestions for 0.9 and 1.0.
> So, I don't really find the target milestone to be that useful,
> unless you want to use it to place bugs into buckets of when we
> intend to fix them. But, then couldn't you also just use a
> [wanted0.9] or [wanted1.0]
I'm also thinking that the Target Milestone is a little redundant if
there are also Wanted flags for each release. If you decide to choose
one over the other, I again prefer the Wanted flag. It just seems like
a really elegant and quick way to triage the bugs.