This is just a tracking bug tracking those bugs that appear to be of substantially greater interest to the Mozilla community than the "average" bug. The initial criteria are: 1) More than 100 votes; or 2) More than 50 CCs; or 3) More than 50 dups
Setting QA. Sorry for the spam (no way to set QA at filing time).
On second thought, 50 is a pretty high number for a CC and dup count. Let's try it with 25 and see how that works out. Feel free to add bugs that meet this criteria. Since you can't search on the nu,ber of CCs or dups, it's gonna have to be manual.
Uh, sorry.. i was just CC'ing myself.. Seems like bugzilla doesn't like me ;)
For the mose-duplicated bugs, see http://bugzilla.mozilla.org/duplicates.cgi ... I have just added the remaining bugs with at least 50 dupes drom there.
Well, I think that 50 dupes is a good threshold. Lowering it to 25 would add quite a lot of bugs (see http://bugzilla.mozilla.org/duplicates.cgi).
Some Suggested Bugs to add: bug 91662: Long strings in mail or news header cause scroll bars and attachment window to disappear, making message unreadable CC's: ~80, Votes: 32, Dupes: ~50 bug 92380: Context menu in Personal Toolbar incorrect when Sidebar items selected CC's: 17, Votes: 4, Dupes: ~12 bug 73712: Check in windows desktop/taskbar icons CC's: 87, Votes: 55, Dupes: 40 Bug 56052: Support PGP in PSM CC's: 48, Votes: 88, Dupes: 1 PS. I mentioned this bug in the "Make mozilla 1.0.1 and 1.1 not suck" bugs (bug 158377 and bug 157592). PPS. Too bad THIS bug doesn't have enough CC's or votes yet, or it could depend on *itself* :-D
is this meta bug really necessary? the most duplicated and most voted bugs can be listed already, and I'm not sure that "bugs with most people CC'd" is a useful indicator. if this bug is useful, then the summary is a bit unclear - "major" bugs already have a definition, and the bugs here aren't necessarily major problems, they're just things that lots of bugzilla users are interested in. maybe "most visible bugs"? the 25 threshold certainly seems too low (that will bring in many hundreds of bugs), 50 is better. I'm not sure why you set the votes threshold much higher compared to the ccs threshold - there are only 35 bugs with 50 votes, but there are many more bugs than that with a cc list of 50. also, which components are you including? is there any point in having resolved bugs on the list?
How is this different from bug 92997? Please don't add another bug to spam people. > The initial criteria are: > More than 100 votes; More than 50 CCs; More than 50 dups I agree with michael lefevre. If you have hard criterias, use bugzilla queries (or code some new).
> the most duplicated and most voted bugs can be listed already, and I'm not sure > that "bugs with most people CC'd" is a useful indicator. The point of this bug is not to count how many CCs there are, count how many dups there are, or list top vote bugs just for the sake of counting. This bug is here for the purpose of having a bug that tracks the issues that are most important to the Mozilla community. Other similar bugs do not have arbitrary criteria for bugs which can be added, and instead are just kind of touchy feely about what counts as "good enough" for the bug. > if this bug is useful, then the summary is a bit unclear - "major" bugs already > have a definition, and the bugs here aren't necessarily major problems, they're > just things that lots of bugzilla users are interested in. maybe "most visible > bugs"? > the 25 threshold certainly seems too low (that will bring in many hundreds of > bugs), 50 is better. I'm not sure why you set the votes threshold much higher > compared to the ccs threshold - there are only 35 bugs with 50 votes, but there > are many more bugs than that with a cc list of 50. > also, which components are you including? is there any point in having > resolved bugs on the list? All components which are part of the trunk or branch Mozilla builds. I can think of two reasons to include resolved bugs: 1) It allows one to get an idea, at a glance, at what the fix-rate is of bugs that the community values most, and 2) sometimes bugs have their scope changed and are marked fixed when they aren't really (bug 120327 comes to mind). > How is this different from bug 92997? Please don't add another bug to spam > people. See first response of mine above. > I agree with michael lefevre. If you have hard criterias, use bugzilla queries > (or code some new). Can you have a query email you when one of the bugs in your query changes state?
Ok. The final criteria will be 50-50-50, votes, cc, dups. I think CCs are a relatively good gauge of interest. People add their name to the CC list because they are interested in what happens with that bug.
Sometimes CCs represent people who don't want the bug fixed, but want to monitor what's going on. This bug has major severity, naturally. It's kind of the "skeletons in the closet" bug. What about the problem with marquee being enabled by default? I wouldn't really call it "major," of course. More like ultra-blocker. (No, I'm not on strike.) Other major concerns of mine include profile corruption, as in bug 123929.
I hate <marquee> as much as the next guy, but this bug isn't about what I like, or what any other single person likes. There are already other bugs that track bugs on the basis of opinion. If the <marquee> bugs get enough votes, dups, or CCs to meet the criteria, add them by all means. This bug is to have a tracking bug with objective and predefined criteria so that it is free from the opinions of any one person or small group.
I'm afaird that the bug about adding IE DOM handler (document.all and such) where are many, many CC'd peoples who are against this, will be added here with high proirity.
In answer to comment #12 and #7 is bug #76831. This bug have been around for almost 1 1/2 years but it does not yet break the 50-50-50 barrier. 58 - CCs 27 - votes 11 - Dups Does this count?
it would make way more sense to collect bugs, which are called _outside_ of Bugzilla very very often as an argument not to use Mozilla. That are News Filters, Roaming, Startup time and some more...
Clarification: There doesn't need to be 50 each of CC's, votes, and duplicates -- just 50 of one of those fields. In response to comment #16: I would file those under bug 92997. It seems tailor made for those kinds of things. If there isn't a bug for these things, make one. That's what Bugzilla is for.
Some comments: 1. It is not obvious to me that a bug with significant community interest would necessarily make advocacy harder. It could well be something that the other major browsers also get wrong or don't implement, but that a lot of people would like to see. Therefore, this bug is IMO quite distinct from bug 92997. 2. We should be careful not to infer too much from Cc. We know what vote means, but Cc does not necessarily mean the same. People may be Cced for several reasons -- because they want it fixed, because they emphatically *don't* (this is more common than you think), because they have been consulted by the assignee or someone else about some aspect of the bug, because they filed a dupe, ... In addition, there are a few people (perhaps a hundred) who are Cced to _large_ numbers of bugs (and then turn down what types of changes they get mail for). Some of them systematically Cc themselves to all bugs in a given component, for example. This makes it a lot easier for a bug to get 50 names on the Cc list than to get 50 dupes. I'm not saying that lots of Ccs means nothing, only that we should be careful about reading _too_ much into it. 3. Duplicates imply more than just interest. Large numbers of dupes also imply that a bug is hard to find by searching, either because it has a bad summary, or because it manifests itself in a wide assortment of ways. However, they do also imply interest. 4. I agree with comment 17 that bugs that receive a lot of interest from _outside_ the community make advocacy harder and should be dependencies for bug 92997. This bug is about interest from people who already use Mozilla. However, I do think there are sources of information about this other than Bugzilla that might be worth considering, such as perhaps features that have been requested many times on n.p.m.wishlist.
Adding bug 70030 "Cannot stop animation with stop button or escape key": 50+ CCs, 45 votes
Adding bug 78510 - 82 CCs 81 votes 20 dups
Is this list seperated by platform - A hundred bugs on a Mac version is not too interesting. Maybe the Bugzilla.org can add a directory for TOP 50 bugs per platform as an aid in finding these nasty buggers, and as an incentive to get them solved. Thanks! MRK
Suggest bug 62429: Replying with the "start my reply above the quoted text" pref on should _prepend_ the signature above the quote text. It doesn't have all the votes or CC's, but it will greatly interest a *large* number of regular users (who typically don't participate here). This bug was unwisely wontfixed. Please see bug 62429 comment #70 on how all objections could easily be dealt with.
Bug 135331 should probably be added as this has large community interest and 63 votes.
Nominating bug 121540 – Use ATSUI for text rendering on Mac OS X. 30 votes and 30+ cc:s in the Mac community corresponds to 600 votes and 700+ cc:s in the Wintel community, using "world market share" as a correlation factor.
I agree with Micheal K in Comment #23, it would be good to see such a 'top bugs' list seperated into several different platform specific lists. This would also help the majority of developers who only work with one platform.
Bug 18004: Mozilla should support resumable downloads (50 CC's). My comments from that bug: "I would label any internet application that does not support resuming as crippled. It is unintuitive for a program to restart any interrupted download from the beginning."
nominating bug 92033 53 votes and CCs.
bunch more from a query on bugs with 50 votes...
> Ok. The final criteria will be 50-50-50, votes, cc, dups. nominating bug 163993 which has 86 CCs.
nominating bug 45375 50 votes and 54 CCs.
nominating bug 122411. 50 CCs.
nominating bug 55690 -- 79 cc's
Looking through most duped bugs (30+) and adding: Bug 915 - column style resolution for text-align,vertical-align not yet implemented [CASCADE] 57 votes, 56 CCs, 35 dups Bug 36816 - news should use the server's username / password when authenticating 54 votes, 29 CCs, 32 dups Bug 50255 - some control key sequences don't generate the correct event (ctrl-enter ...) 31 votes, 70 CCs, 34 dups Bug 79889 - Download progress dialog too small [clipped on right side] 7 votes, 55 CCs, 36 dups Bug 104532 - Status bar ticker fails to update when tabs switched. 44 votes, 67 CCs, 34 dups Bug 84128 is on the border of counting - exactly 50 CCs at the mo
Added bug 62429 with 53 votes. Option to put mail signature above the quoted message (i.e. with the reply) when top posting
Added Bug 11056 - Implement new mail check standalone app (nsnotify) since it now has 50 votes.
Adding Bug 33732 - [MW] mouse wheel scrolls listbox, even when cursor is outside listbox 45 votes, 69 CCs, 42 dups
Nominating bug #18574 which has 50 votes, 20 of them cast in the past 12 hours or so to request restoring MNG animation and JNG image support that were removed from the trunk yesterday.
Bug 57724 - View source munging pages (does not display original page source as sent by server) 25 votes, 62 CCs, 0 dups (but several ex-dups)
Bugzilla Bug 38966 Privacy and Security [was Security Policies] pref panel work 76 CCs, 44 votes, 27 dupes. BTW, how does one count the CCs, besides grabbing the source OPTION tags, putting it into Textpad and getting the last line number, like I did? (All of the rest of my bugs are either unpopular or already in the list.)
I just highlight the first email address in the list and start counting with each press of the down-arrow key.
Nominating bug #195280 (Removal of MNG/JNG support). It has 1 vote, 52 cc, no dupes. Votes opposing this bug are accumulating in bug #18574, currently 286 (there were 240 this morning before it was mentioned on slashdot).
bug 8589 has 60 cc:'s.
Adding bug 204374 - GDI Resources are used till the UI/website displays faulty 57 votes. This bug is a 1.4 BLOCKER.
Been awaiting the time to add this one... Bug 72493 - support threaded, sorted view 34 votes, 51 CCs, 13 dups
Nominating Bug 107883 - Feature request: Remove from server after x days (POP) This feature is needed by anyone who retrieves their mail from more than one location. It would allow mail to stay on the POP server for x days and then be automatically deleted by Mozilla mail, hopefully preventing the mailbox from overflowing.
Adding Bug 193638 - corrupt or lost pref.js / startup configuration error 0 votes, 39 CCs, 52 dups
Nominating bug #204520, MNG imgmng library takes up too much disk space. 31 votes, 59 cc, no dupes.
Nominate: bug #124750 36 dups, 28 Votes, 58 CC's
Added. You could've done this yourself.
0 CCs, 0 Votes, 0 Dupes...
What about 0 CCs, 0 Votes, 0 Dupes...? As you can see, most of us, reading through the comments of a bug, don't see what else you changed at the same time.
Someone added bug 219805 even though it had 0 CC's, 0 votes, and 0 duplicates.
Nominating bug #171082: 47 votes, 52 CCs, 3 Dupes.
bug 171082 is a Firebird bug. If we're tracking Firebird bugs with this as well, there's probably a whole bunch. Particularly as Firebird bugs tend to get more votes, because users get 100 votes for Firebird bugs rather than just 10.
Bug 88810 - Remove code that unnecessarily focuses/raises windows 35 votes, 52 CCs, 2 dups
Another long-standing bug finally qualifies! Bug 162134 - [OSX] (Java, Real, QuickTime) XPCOM plug-ins draw on wrong tabs and leave detritus during scroll 10 votes, 51 CCs, 35 dups
Nominated by votes: bug 75866 - Viewing message for very short time shouldn't mark it as read bug 91498 - New mail notification alert/beep even when message filtered to Trash Folder bug 120398 - ability to specify 'projection' CSS2 media bug 189289 - No new mail notification (biff) when junk mail (spam) arrives
Bug #48570 "Allow votes against a particular enhancement request" has 61 votes, 24 CC, 4 dupes.
But that's about Bugzilla, not the Mozilla client software as this bug is.
nominating bug 122698 35 votes, 51 CCs, 41 duplicates
Added comment 68 and comment 70 bugs and I think the Supreme court of bug 163993 will allow for this loose interpretation of "Mozilla Community" to mean anything within the bug database for Mozilla.org at least until similiar tracking bugs for every component are made (unless such tracking bugs already exist).
Addind more than 50 votes: 10713 - Implement CSS2/3 text-shadow property 108455 - Mozilla mail doesn't open URLs in system default browser 122445 - Spoof prevention: Warn if username/password in link (url) looks like a hostname 131106 - Make 'default browser' shouldn't steal image file associations from image programs 131456 - Memory use does not go down after closing tabs 217004 - sometimes table renderes wrong depending on time the script needs Firebird: 172817 - allow external source viewer/editor 210043 - Context menu "copy image" (not URL) to paste into image editing software 211023 - Firebird needs bookmark sort fix from bug 205378 222157 - View Source: Save as, Find and Find Again don't work
Please do not add/remove new dependencies to this bug. It causes spam. You can use queries or maintain it as links on a webpage.
You can turn it off in prefs if you don't want to get mail when a dependency is added.
Re: comment 73 Does this mean someone's going to kill this bug and move the content to an external site? Re: comment 74 Or take yourself off the CC list, depending on whether you want to stop watching this bug or stop watching dependency changes.
Killing this bug and having the list (with email updates) kept somewhere else (maybe a mozillazine forum thread would be suitable?) isn't a bad idea. Any volunteers? :) You can turn off email about dependency changes, but not in a narrow way - you have to turn off notifications for "all other changes" IIRC. And being cc'd on this bug isn't the issue - the problem is that the dependency/blocker status is two-way - people watching any of the bugs on the list also get notifications.
Until someone takes care of duplicating this list off bugzilla, instead of complaining, just remove your CC. Thanks.
Michael: Ahhh, sorry I missed that. I guess I'd have to agree then that we shouldn't add any more dependencies, but comments in the bug should be fine, right?
bug 10713: Implement CSS2/3 text-shadow property An old one. Better than 70 votes.
Nominating bug 135079 - on multiple/dual/secondary monitor setup, highlighting/hover on items broken It has 50 dupes.
50 dupes means it should be added. Adding.
Nominating bug 90198 - Fixed background makes scrolling painfully slow 65 CC's, 31 votes
nominating bug 101190 - window.open() in onclick, click anchor with new window target, etc. while page is loading fail if popups are blocked 52 votes, 34 dupes
Nominating bug 102132 - Ability to move content areas from tabs into windows (Link/delink tabs) 62 CCs, 30 votes
Nominating bug 135137 - Profile data cannot be shared by multiple running instances. 66 CCs, 26 votes
Nominating bug 154892 - Splitting Absolutely positioned frames not implemented - Missing second page of content when printing or print previewing this site It just passed the 50 CCs mark. It also has 41 dupes, and 26 votes, and it was mentioned many times lately as an annoying bug that should be fixed asap, ideally before Firefox 1.0 ships.
Nominating Bug 9458 to implement inline-block in layout. 52 votes - 45 CC's
Note that bug 84128 is now at 58 votes, 81 CC's, and climbing, no longer on the border...
Nominating bug #257197 which has 52 cc's, 10 votes, no dupes.
Bug 243324 has 114 votes
You can email me when you want a bug added. You don't need to comment in the bug.
added: bug 151249 - 69 votes, 53 cc's bug 203927 - 66 votes bug 197813 - 66 votes bug 121540 - 52 votes, 50 cc's
Adding bug 171349 (no taskbar or window icon under Windows 98/Me), 96 votes, more than 30 duplicates.
when a bug is fixed, shouldn't we remove it from the dependancy list? it would trim it down a bit
(In reply to comment #99) > when a bug is fixed, shouldn't we remove it from the dependancy list? it would > trim it down a bit Nope -- they should remain on the list to retain the history of this bug's progress.
I agree, but the number is growing and growing. And in the future it'll be hard to know exactly what left to be done unless we pay attention. Could we use an alternative? I suggest when we create another "bug" as a processed bug holder. When a bug, say 4302, is closed, it's trimmed from this bug's dependency tree and re-injected as a dependence buy in that bug holder. And in order to keep track, that bug could depend on this bug, or the other way round. There's a hitch in this suggestion: if a bug is reopened, it has to be trimmed from that bug and re-injected in this bug again.
(In reply to comment #101) I meant "I suggest we create another ......" > Could we use an alternative? I suggest when we create another "bug" as a > processed bug holder. When a bug, say 4302, is closed, it's trimmed from this
There is no need for trimming! If you want a trimmed version, just see https://bugzilla.mozilla.org/showdependencytree.cgi?id=163993&maxdepth=1&hide_resolved=1
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b2) Gecko/20050417 Firefox/1.0+ Bug 163993 depends on: 289480 (77 CC:, 51 Votes.)
Adding bug 154892 (Missing second page of content when printing) - 59 votes, around 43 dupes, and 84 CCs.
Adding bug 255255 (after searching bookmarks, the results are not editable) - 69 votes.
Adding bug 252371 (incremental find/search in page does not find/highlight text in textarea/form/text entry boxes) - 145 votes, 67 CCs. Adding bug 231062 (Provide Firefox MSI package) - 69 votes, and also 69 CCs.
Adding bug 283730 ("Save As" dialog tries to overwrite link/shortcut (.lnk) file instead of opening the directory/folder) -- 87 votes.
Adding remaining bugs with over 50 dupes (from https://bugzilla.mozilla.org/duplicates.cgi) The bugs and the number of dupes to them (as of now) are listed below. Bug 58917 - 50 Bug 245392 - 50 Bug 83376 - 53 Bug 22964 - 54 Bug 21296 - 54 Bug 193749 - 59 Bug 180672 - 60 Bug 180309 - 61 Bug 205893 - 62 Bug 247833 - 77 Bug 245418 - 83 Bug 228968 - 90 All of the bugs with 50 or more duplicates (as of now) should now be listed as blocking this bug.
Adding dependencies on remaining bugs with 50 or more votes (as of now.) The bug IDs and the amount of votes are listed below. Bug 2212 - 50 Bug 3013 - 58 Bug 10097 - 51 Bug 11034 - 102 Bug 11040 - 54 Bug 11055 - 56 Bug 11076 - 51 Bug 13595 - 71 Bug 17048 - 186 Bug 18722 - 51 Bug 18764 - 94 Bug 20304 - 52 Bug 20417 - 52 Bug 22689 - 64 Bug 23394 - 78 Bug 30057 - 53 Bug 36351 - 61 Bug 40867 - 55 Bug 41524 - 79 Bug 45715 - 73 Bug 52746 - 81 Bug 55057 - 64 Bug 58308 - 61 Bug 58612 - 136 Bug 64401 - 64 Bug 70132 - 55 Bug 75138 - 61 Bug 80142 - 65 Bug 83633 - 81 Bug 88870 - 63 Bug 91037 - 60 Bug 95067 - 72 Bug 98304 - 67 Bug 98971 - 61 Bug 105843 - 51 Bug 114656 - 100 Bug 116692 - 64 Bug 121948 - 60 Bug 121969 - 51 Bug 122659 - 113 Bug 123315 - 81 Bug 132035 - 59 Bug 134260 - 53 Bug 138198 - 122 Bug 144496 - 59 Bug 157004 - 75 Bug 163993 - 52 Bug 172818 - 62 Bug 172962 - 88 Bug 173762 - 64 Bug 175787 - 54 Bug 179656 - 105 Bug 186136 - 52 Bug 188938 - 235 Bug 201307 - 96 Bug 202615 - 76 Bug 204519 - 58 Bug 205011 - 137 Bug 208314 - 68 Bug 211628 - 51 Bug 216537 - 53 Bug 217199 - 64 Bug 218142 - 53 Bug 218223 - 51 Bug 222653 - 64 Bug 229686 - 92 Bug 230401 - 58 Bug 230870 - 105 Bug 231048 - 50 Bug 232272 - 52 Bug 232638 - 59 Bug 238137 - 57 Bug 241438 - 91 Bug 245163 - 52 Bug 247884 - 107 Bug 250309 - 96 Bug 255637 - 83 Bug 257859 - 61 Bug 258062 - 106 Bug 258285 - 53 Bug 270012 - 106 Bug 271815 - 82 Bug 274784 - 96 "Dependency Loop Detected You can't make a bug blocked or dependent on itself." - Bah, oh well! Right, all bugs with at least 50 votes, and all bugs with at least 50 dupes included. Without direct SQL access, I can't search for CCs, so they can just be added when they are stumbled upon.
I think at this point this has long outlived what usefulness it once had, and the recent mass change has pushed it past the breaking point. Marking INVALID, please don't make more changes to this bug. So sayeth #developers, amen.
As the person who created this bug, I don't think it has outlived its usefulness at all. The whole point of this bug was to have out in the open a list of bugs that are most important to the people who use the product, and where it is easy to see how many of these important bugs remain unfixed for long periods of time. If the developers don't like this bug being so long, perhaps they can schedule bug fixes based on what's important to the community rather than their own personal pet projects and desires. If that were to happen, this bug wouldn't be very long. This bug is so large and unwieldy because the important bugs are not being fixed, not because of some flaw in this bug.
I'm not looking or intending to start a debate here, and I certainly intend for this to be the last comment I add here, but I don't want to leave the response hanging there. What you're describing sounds like advocacy tracking bug. That doesn't have a place in Bugzilla. If we're looking at doing _anything_ based on votes, queries are better anyway, instead of scraping a list of deps. This bug is useful for random people interested in watching a large set of highly-voted bugs, but adds nothing to the management of any of the projects it touches. It also has the negative effect of intermittent bursts of spam, and gives the impression that bugs on this list should automatically gain higher priority because 50 people clicked a couple links. Bugs should always be rated on their merits, and not just on the attention of a small group of people.
Anyone who uses Bugzilla quickly becomes aware that bugs are not fixed according to their importance with users. At least we agree on that. I know it is, and has been, the position of mozilla.org to keep any advocacy that conflicts with their goals out of public view as much as possible. It looks bad to have a huge list of bugs that many users are interested in seeing fixed being ignored for years. It looks even worse when you can click on any bug in that list and read the blatant, egotistical attitude frequently taken by drivers and others when refusing to fix bugs because of petty personal vendettas and for other lame excuses. As far as spam, there are email preferences if you do not want to receive bug spam. However, I am sympathetic to the spam complaint. It would be just as effective to list all of these bugs in a comment to this bug. That way you can still see the list and see which are fixed, and which are not.
Bug 915 Bug 2212 Bug 2920 Bug 3013 Bug 3247 Bug 4302 Bug 4821 Bug 6211 Bug 7251 Bug 8415 Bug 8589 Bug 9101 Bug 9458 Bug 9942 Bug 10097 Bug 10713 Bug 11033 Bug 11034 Bug 11035 Bug 11040 Bug 11055 Bug 11056 Bug 11076 Bug 11459 Bug 12286 Bug 12916 Bug 13595 Bug 15144 Bug 16360 Bug 16409 Bug 16489 Bug 17048 Bug 17483 Bug 17917 Bug 18004 Bug 18266 Bug 18574 Bug 18722 Bug 18729 Bug 18764 Bug 18808 Bug 19118 Bug 19437 Bug 20304 Bug 20417 Bug 20618 Bug 21296 Bug 21762 Bug 22056 Bug 22274 Bug 22687 Bug 22689 Bug 22775 Bug 22964 Bug 23394 Bug 23508 Bug 23679 Bug 24867 Bug 25537 Bug 28327 Bug 28586 Bug 30057 Bug 30431 Bug 32157 Bug 32218 Bug 33339 Bug 33576 Bug 33732 Bug 36351 Bug 36557 Bug 36810 Bug 36816 Bug 36836 Bug 38486 Bug 38488 Bug 38966 Bug 40867 Bug 40873 Bug 41524 Bug 41924 Bug 43015 Bug 43278 Bug 44863 Bug 45375 Bug 45715 Bug 46845 Bug 47108 Bug 47475 Bug 47838 Bug 48570 Bug 49141 Bug 49543 Bug 50255 Bug 50504 Bug 51683 Bug 52746 Bug 52821 Bug 53486 Bug 54542 Bug 55057 Bug 55583 Bug 55690 Bug 56052 Bug 56219 Bug 56301 Bug 56418 Bug 57342 Bug 57724 Bug 57805 Bug 58308 Bug 58339 Bug 58612 Bug 58724 Bug 58917 Bug 58937 Bug 60861 Bug 60981 Bug 62429 Bug 64401 Bug 64945 Bug 66822 Bug 67127 Bug 69938 Bug 70030 Bug 70132 Bug 70213 Bug 71105 Bug 71668 Bug 72493 Bug 73712 Bug 74157 Bug 75138 Bug 75866 Bug 75915 Bug 76831 Bug 78104 Bug 78414 Bug 78510 Bug 79889 Bug 80142 Bug 81446 Bug 82534 Bug 83376 Bug 83663 Bug 83754 Bug 84128 Bug 86193 Bug 86405 Bug 87987 Bug 88810 Bug 88870 Bug 90198 Bug 90337 Bug 91037 Bug 91498 Bug 91662 Bug 92033 Bug 94035 Bug 95067 Bug 97283 Bug 97284 Bug 97806 Bug 98304 Bug 98546 Bug 98971 Bug 101190 Bug 102132 Bug 103720 Bug 103843 Bug 104532 Bug 104778 Bug 105547 Bug 105843 Bug 105885 Bug 107883 Bug 108455 Bug 108973 Bug 113007 Bug 113574 Bug 114656 Bug 116692 Bug 116832 Bug 117895 Bug 119964 Bug 120327 Bug 120398 Bug 121084 Bug 121540 Bug 121948 Bug 121969 Bug 122092 Bug 122411 Bug 122445 Bug 122659 Bug 122698 Bug 123315 Bug 124029 Bug 124150 Bug 124750 Bug 124958 Bug 126224 Bug 130331 Bug 131106 Bug 131456 Bug 132035 Bug 133567 Bug 134260 Bug 135017 Bug 135079 Bug 135137 Bug 135331 Bug 137006 Bug 138198 Bug 143687 Bug 144027 Bug 144496 Bug 145579 Bug 146340 Bug 147670 Bug 148098 Bug 148399 Bug 151249 Bug 153815 Bug 154699 Bug 154892 Bug 157004 Bug 159494 Bug 162134 Bug 162593 Bug 167663 Bug 168905 Bug 169777 Bug 170006 Bug 171082 Bug 171349 Bug 171441 Bug 172817 Bug 172818 Bug 172962 Bug 173762 Bug 175787 Bug 179656 Bug 180309 Bug 180672 Bug 186136 Bug 188938 Bug 189289 Bug 193638 Bug 193749 Bug 195280 Bug 195600 Bug 197813 Bug 201307 Bug 202615 Bug 203927 Bug 204374 Bug 204519 Bug 204520 Bug 205011 Bug 205893 Bug 208314 Bug 210043 Bug 210910 Bug 211023 Bug 211628 Bug 215243 Bug 216537 Bug 217004 Bug 217199 Bug 218142 Bug 218223 Bug 219936 Bug 220900 Bug 222157 Bug 222653 Bug 227241 Bug 228968 Bug 229686 Bug 230401 Bug 230870 Bug 231048 Bug 231062 Bug 231393 Bug 232272 Bug 232638 Bug 238137 Bug 241438 Bug 243324 Bug 245163 Bug 245392 Bug 245418 Bug 247833 Bug 247884 Bug 250309 Bug 252371 Bug 255255 Bug 255637 Bug 257197 Bug 257859 Bug 258062 Bug 258285 Bug 270012 Bug 271815 Bug 274784 Bug 283730 Bug 289480
IMHO this bug was useful and it was useful to have all those high-visibility bug in the dependencies filed. I used to be on the CC list of this bug for a specific purpose - I enjoyed getting emails telling me some high-visibility bug was fixed. If that meant that an often-requested feature was implemented, then I might go and see if this is something I might be interested in too. Yes, there are queries, but for me the point of this bug was in getting those emails _without_ having to visit Bugzilla web site. I agree with comment #117 - if you think this is spam, use email preferences and email filtering on your end, but do not insist on getting rid of emails that other people find useful.
They are going to ignore you. It's an old boys club. If your view doesn't match theirs, they don't want to hear about it. Not only that, but they don't want you using *their* Bugzilla for purposes they don't find useful. It's a hopeless cause. Just use the half-assed browser and email client until someone with a better agenda comes along.
This is supposed to be an "open" community isn't it? If a few people want to track a few bugs, what does it matter to anyone outside of those few people? Mike Connor, I'm sure you're a reasonable guy.... you may want to rethink this, all you are doing by closing this bug is **** off a lot of people, and drive more people AWAY from Mozilla development.
Just give it up, they wont listen, I mean look at that whole MNG fiasco.
(In reply to comment #115) ... perhaps they can schedule > bug fixes based on what's important to the community rather than their own > personal pet projects and desires. If that were to happen, this bug wouldn't be > very long. > > This bug is so large and unwieldy because the important bugs are not being > fixed, not because of some flaw in this bug. (In reply to comment #116) ... Bugs should always be rated on their merits, and not > just on the attention of a small group of people. Kinda funny juxtaposition of those two posts. I guess keeping this invalid is OK as long as someone tracks this somewhere. Maybe on a post in the forums updated daily like Peter's posts.
(In reply to comment #119) > I agree with comment #117 - if you think this is spam, use email preferences > and email filtering on your end, but do not insist on getting rid of emails > that other people find useful. Bugzilla is first and foremost a tool to help the Mozilla _developers_ do their work. It is pretty much irrelevant how useful features here are to end users - only how they affect the efficiency of developers. Any developer even reasonably active has a stunningly large volume of daily email to read. Changes in dependecies are usually really useful information for these developers, alerting them to related bugs that might help them find out who else is working on a problem, or what's related, or suggest fixes, or find out that something that needed to be done before they could do something else has now indeed be done, so that they can go and implement further fixes - definitely not something they ever want to filter out. What the latest mass change to this bug did was to spam pretty much every single developer out there with a few to a few dozen notices that a bug they are tracking in had gotten a dependency. Unfortunately bugzilla does not yet include the summary of these dependencies, so that means that the mass change caused each of these developers to manually go and waste time first reading the email, then manually looking up the bug, wasting at least a few seconds scanning around to see what it was about, and then delete or filter away or labeling the email. Depending on how they sort their email, they then read a lot of other email before coming to the next dependency change for the same bug (would they remember the six digit bug number as being a non-relevant one? I doubt it...) and have to go through the entire process again. Time is really precious for these people, and I would imagine that this bug has wasted _a lot_ of time for all of them. Don't whine that the combined group of active developers has finally taken action on it.
Thank you all for the spam I'm getting since yesterday, including 30+ messages saying: > What |Removed |Added > ---------------------------------------------------------------------------- > OtherBugsDependingO|163993 | > nThis| | This comment is my humble way of saying how grateful I am. This bug has never created 1/10 of the joy am am feeling now knowing that many bugzilla bugs remember me.
(In reply to comment #124) > the summary of these dependencies, so that means that the mass change caused > each of these developers to manually go and waste time first reading the email, > then manually looking up the bug, wasting at least a few seconds scanning around This is correct. I just did this, and I agree that it's a waste of time.
I may build an application that queries every bug in this list on a daily basis in order to duplicate the functionality that was had in this bug. If I do so, I will notify everyone in this bug so they can choose to sign up for that list. I fully expect the Mozilla developers to attempt to halt this as well, but thank God for open proxies.
That's a great idea. The intention here was never to stifle discussion/openness, it was about moving it out of our project management application. The spam and advocacy comments that are becoming so commonplace are making Bugzilla increasingly less useful. Putting up a community site that tracks changes to bugs like this is not something I want to discourage at all. We want open discussion and feedback, as long as its going places like the MZ forums where it belongs. If it helps, one option would be to do something similar to how the mozbots work (subscribing an email and ccing the bugs directly, or watching certain accounts). That would get all of the changes in a readily parseable format, if you were so inclined. If you're focused on stats/statuses, you can do some really neat things with the query formats available (CSV, feeds (except those seem broken on bmo, pending the next Bugzilla version bump). There's some existing bugzilla tracker setups, iirc, you might want to look around and see what's worth reusing.
(In reply to comment #124) > (In reply to comment #119) > > I agree with comment #117 - if you think this is spam, use email preferences > > and email filtering on your end, but do not insist on getting rid of emails > > that other people find useful. > > Bugzilla is first and foremost a tool to help the Mozilla _developers_ do their > work. It is pretty much irrelevant how useful features here are to end users - > only how they affect the efficiency of developers. Agree, developers take greatest priority. But there is no one or no group(s) in the middle? There are no secondary groups, between end users and developers, who are *actively* helping and working the cause? Most certainly the answer is YES. Terminating the bug is a quick fix. But shouldn't this 'incident' highlight the need for changes or new set of functionality and not just focus on the extremes of one (or more) group - however important that group may be? [many great Sander comments deleted] > Unfortunately bugzilla does not yet include the summary of these dependencies, bug 97956 - which has gotten no love (and similar bug 125888) I'm inclined to agree queries may well be the answer. But what queries is mconnor speaking of? I understand vote queries. But how does one create a query for duplicates? And get updates mailed when the "list" changes? Is it via https://bugzilla.mozilla.org/duplicates.cgi If there is discussion of these issues somewhere, please post the location. With respect to all and sorry for the spammage.
(In reply to comment #128) > The spam and advocacy comments that are becoming so commonplace > are making Bugzilla increasingly less useful. When other avenues of expression are ineffective, people try elsewhere. If you want people to stay in the newsgroups or forums, those forums have to be effective. If they are not effective, people will move on and escalate until it is effective.
CCing myself to be informed. Jerry, you may (as well) post diffs to the list (which was useful!) right here -- and hope the devs oppose only the idea of not-development-related dependencies.
(In reply to comment #118) > Bug ... > ... > ... Awesome fix! I just voted for this bug today. (also, it looks like someone still needs to add a comment which describes what "queries" are -- and would it be useful to have a MozillaZine thread about this issue?) Since this bug isn't the correct solution for community frustration, and apparently no one cares how many votes a bug gets, what would be a good way for the community to express what it feels is important?
(In reply to comment #132) > (also, it looks like someone > still needs to add a comment > which describes what "queries" > are -- and would it be useful > to have a MozillaZine thread > about this issue?) "Queries" are what you do when you fill out the forms which you get by clicking on any one of the various "Search" links on this page. Logging in to Bugzilla (with username and password) also leads you to the query (or Search) page, where you have a choice between "simple" and "advanced" search. Best regards, Tony.
"Use queries instead" wrongly implies that Bugzilla can search for "(Votes > 49) OR (CC Count > 49) OR (Duplicate Count > 49)". Bugzilla cannot. [It can search either for (Votes > 49), or for (Duplicate Count > 30) using https://bugzilla.mozilla.org/duplicates.cgi.] Those who'd like Bugzilla to do such searches may wish to advocate enhancements like: bug #62718 (Should have a way to search by number of CC:) bug #204209 (Duplicates should be stored in main bugs table)
If the "queries" don't work, then this bug is the best we've got.