[Cosmo-dev] Next steps for Cosmo
Katie Capps Parlante
capps at osafoundation.org
Thu Aug 30 14:45:53 PDT 2007
Ted Leung wrote:
> On Aug 30, 2007, at 2:01 PM, Brian Moseley wrote:
>> On 8/30/07, Ted Leung <twl at osafoundation.org> wrote:
>>> There are 3 states to bugs according to your proposal: "nominated",
>>> "approved", "fixed". It seems like the only way to indicate
>>> nomination is via a flag or keyword. Indicating approval can be
>>> done with either a keyword or via targetting the bug. So it looks
>>> like using keywords would be using one mechanism that would work for
>>> both purposes. It seems odd to me to target a bug to a release
>>> after it has been fixed, so that would be an argument for using
>>> targetting for "approved". The problem with targetting is that you
>>> then have to untarget bugs that miss the window. Actually, I think
>>> that I am convincing myself that keywords (without version numbers)
>>> is probably the way to go for nominated and approved, and the bugs
>>> get targetted when they are actually fixed/checked in.
>> i will never remember to target a bug when i'm marking it fixed. i'd
>> prefer to have the bug's target tell me that i need to fix it. in
>> other words, i'd prefer to save a query for "my 0.7.1 bugs" and have
>> that be the list of work i have to do for the next week. it doesn't
>> seem too difficult for you to go through the list of unfixed 0.7.1
>> bugs at the end of the week and untarget them - certainly less prone
>> to failure than each one of us having to remember to change the target
> My thinking about untargetting bugs had more to do w/ some theoretical
> view of building releases by adding rather than removing, not by how
> much work it would be for me (not much). But you make a good point
> about the number of people that can make an error. Put me back in the
> targetting camp...
I'm +1 on targeting the bugs to 0.7.1 to indicate "approved" as well.
Another factor to consider is that the Target Milestone can be used as
an axis in a bugzilla table.
Where "fixed" is not captured by the "Status" and "Resolution",
presumably we could also make use of the existing "havefix" keyword.
"Resolving" a bug should mean that it is committed to the "right"
branch? "havefix" means a fix is around somewhere but not on the "right"
That leaves "nominated". fwiw, flags are kind of a pain as it is hard to
write queries and flags don't show up in list views.
What about using the '---' target milestone to nominate? The advantage
is that you can easily see in a table view what has to be considered in
the big picture of how other things are targeted. The disadvantage is
that newly created bugs are mixed in. Another suggestion: create a new
target milestone for "nominated", if it is helpful to separate out new
bugs from bugs nominated for an upcoming release.
More information about the cosmo-dev