262161 - "tracking bug" for unblocked aviary bugs with no future target

Status: VERIFIED INVALID

(bugzilla.mozilla.org :: Administration, task)

Description

[Worcester12345]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040928 Firefox/0.10 (bangbang023)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040928 Firefox/0.10 (bangbang023)

There should be additional fields in Bugzilla for any bugs which are marked as
not blocking current versions or whose target milestone is not current versions
(other than "future").

Reproducible: Always
Steps to Reproduce:
1. Go to Bugzilla
2. Find a bug which was marked as blocking but is no longer blocking yet not fixed.
3. View bug information.

Actual Results:  
Bug information is incomplete, leaving room for bugs to "fall through the
cracks" or become ignored.

Expected Results:  
Allowed (better yet, forced) developers, testers, and users to change to a
different milestone or blocking status other than unblock or "future".

This will greatly help the Firefox product and help make it easier to administer
bug tracking for developers, testers, and ultimately, users.

Comment 1

[timeless]

first: you're dreaming.
second: you're dreaming.
third: you're dreaming.

that said, perhaps asa has some idea about other target milestones.

Comment 2

[timeless]

taking the liberty of vetoing the nomination.

Comment 3

[Worcester12345]

Will use this as a tracking bug from here out.

Comment 4

[Mike Connor [:mconnor]]

the idea of "tracking" a set of bugs that can be already be easily queried is
pointless.  We're trying to get far away from meta bugs except for specifically
linked issues.  Killing the giant dep list, marking INVALID.  If you want to
track this stuff, just use a saved query.

Secondly, just because someone nominated a bug for blocking does not mean we're
obligated to force a milestone target.  It might be a "pie in the sky" bug that
would be nice but not worth the effort at present or at any forseeable time, so
Future is a valid target.   What you're suggesting would ultimately mean that
the blocking flags would be ripe for potential abuse by people trying to get
their pet bug prioritized.  Target milestone should be driven by the roadmap and
the development team.

We're not really thinking about the next major version of Firefox, so we're not
ready to lay out a milestone plan as of yet.  "After Firefox 1.0" is about as
accurate as we're going to get right now, but once the dust clears we will start
planning and adding future milestones to coincide with our roadmap.

Comment 5

[Stefan Pietschmann]

I think that pure nominees or "pie in the sky" bugs weren't meant. what he was
trying to "track" are the bugs, which previously had a blocking_aviary1.0+ flag,
but were minused this week trying to get the list down.
The goal was trying separate those from the "normal" nominees which had been
minused from the beginning. oh well ...

I just find it a bit "strange" that there seems to be the big 1.0 goal, but
there is no after-1.0. No plans, no targets... anyway, let's wait for 1.0. I
shut up.

Comment 6

[Asa Dotzler [:asa]]

(In reply to comment #5)
> I think that pure nominees or "pie in the sky" bugs weren't meant. what he was
> trying to "track" are the bugs, which previously had a blocking_aviary1.0+ flag,
> but were minused this week trying to get the list down.

Stefan, that's also easily queried. No need for a tracking bug. 

Comment 7

[Worcester12345]

(In reply to comment #4)
> the idea of "tracking" a set of bugs that can be already be easily queried is
> pointless.  We're trying to get far away from meta bugs except for specifically
> linked issues.  Killing the giant dep list, marking INVALID.  If you want to
> track this stuff, just use a saved query.


I'll be looking for these to disappear soon then, as well, if you are to be
consistent:

[url=https://bugzilla.mozilla.org/show_bug.cgi?id=7251]improve startup
performance tracking bug[/url]

[url=https://bugzilla.mozilla.org/show_bug.cgi?id=248125]Extension Manager error
handling/recovery tracker[/url]

[url=https://bugzilla.mozilla.org/show_bug.cgi?id=203448]Matic's performance
tracker[/url]

Also found
[url=https://bugzilla.mozilla.org/buglist.cgi?query_format=&short_desc_type=allwordssubstr&short_desc=tracker+bug&long_desc_type=substring&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywords=&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&emailassigned_to1=1&emailtype1=exact&email1=&emailassigned_to2=1&emailreporter2=1&emailqa_contact2=1&emailtype2=exact&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0=]15
other tracker bugs.[/url]

Comment 8

[Worcester12345]

(In reply to comment #4)
...
> Secondly, just because someone nominated a bug for blocking does not mean we're
> obligated to force a milestone target.  It might be a "pie in the sky" bug that
> would be nice but not worth the effort at present or at any forseeable time, so
> Future is a valid target.  


Yes, but they were NOT SET as "FUTURE" milestone. I was tracking the ones which
fell out of ANY tracking after being taken off of "blocking" status.


...
> We're not really thinking about the next major version of Firefox, so we're not
> ready to lay out a milestone plan as of yet. 


But you should be. I was attempting to help you with that by allowing some of
this work to be focused here.



 "After Firefox 1.0" is about as
> accurate as we're going to get right now, but once the dust clears we will start
> planning and adding future milestones to coincide with our roadmap.

Yeah, but even "After Firefox 1.0" would have done, if that were a choice to
change it to, which is the point of the bug.

Reopening for general community interest.

Comment 9

[Mike Connor [:mconnor]]

you're trying to change the way we do things, by ensuring that bugs that get
nominated get targeted as well, which isn't always valid/desired.  Sometimes
when minusing stuff I am changing the target, but the existing "After Firefox
1.0" milestone means very little, other than "we're not going to do this for
1.0" which is exactly what the minused blocking flag means.  

Note that I did say that its an EXISTING choice, because "After 1.0" has been a
valid choice since the product was called Phoenix in Bugzilla, at least since
May 2003. 

Stefan, of the list of bugs he had attached to this bug, at least three that I
looked at were never plussed, just nominated, so either his explanation was
wrong, or his data sucks.  Either way, we can easily get the data if we
want/need it.  Some of those other bugs are certainly more useful 

Those are much more valid examples of meta/tracking bugs, since they generally
tend (especially the startup tracker) to be across many products, without a
single keyword that can be used to track them.  If you have to add a keyword to
bugzilla to track an issue, its generally better to have a tracking bug based on
fixing an overall issue than to have a bunch of arbitrary keywords.  Again,
you're not really understanding what the idea is behind the normal/accepted use
of tracking/meta bugs.

Trying to plan for a major milestone after 1.0 when we're a month from shipping
1.0 is taking our eyes off the ball.  Once 1.0 ships, we can sit down, evaluate
feedback from millions of users, and decide what we want to do for the next release.

re-resolving, "community interest" isn't a valid reason to reopen a bug like
this.  The community can still see resolved bugs, so there isn't much other than
you not accepting the response.  Its a dead bug, leave it alone.

Comment 10

[Greg Campbell]

v.
When the next major revision is in sight, there will be blocking-1.whatever
flags. ALL BUGS that don't make 1.0 will be considered for the next version.
Bugs that get minused for 1.0 won't get "lost in the cracks."

Don't get your panties in a wad.

Comment 11

[Worcester12345]

Is there a next version in sight yet, as this one is due out very soon? Where do
bugs go now?

Comment 12

[Mike Connor [:mconnor]]

bugs go where they've always gone.  Please stop nagging people to fit your idea
of how we should run the project.  We'll update the milestones as needed to fit
plans.  We don't need you harping on the subject.

Comment 13

[Worcester12345]

(In reply to comment #12)
> bugs go where they've always gone.  Please stop nagging people to fit your idea
> of how we should run the project.  We'll update the milestones as needed to fit
> plans.  We don't need you harping on the subject.

Just wondering if these milestones have been updated yet. Thanks.