Closed
Bug 451915
Opened 16 years ago
Closed 15 years ago
Merge components "Bookmarks & History" and "Places" for Firefox
Categories
(bugzilla.mozilla.org :: Administration, task)
bugzilla.mozilla.org
Administration
Tracking
()
VERIFIED
FIXED
People
(Reporter: paul, Assigned: gerv)
References
Details
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.1) Gecko/2008070208 Firefox/3.0.1 Build Identifier: Similar bugs are filed into one or the other component, causing complexity in searching for bugs in those areas, and probably increases duplicate bug creation. These components should be merged, or their descriptions should more readily differentiate them: perhaps Bookmarks & History for Firefox 2 and below, and Places for Firefox and above. Currently they are both being used for new bugs in Firefox 3. Reproducible: Always
Updated•16 years ago
|
Assignee: create-and-change → marcia
Component: Creating/Changing Bugs → Bugzilla: Keywords & Components
Product: Bugzilla → mozilla.org
QA Contact: default-qa → timeless
Version: unspecified → other
Comment 1•16 years ago
|
||
beltzner/mconnor/dietrich: What do you want to do about these two components?
OS: Windows XP → All
Hardware: PC → All
Comment 2•16 years ago
|
||
Can we "deprecate" Bookmarks & History, so that the bugs still exist, but the component doesn't show up when trying to file a new bug? That way we can triage Bookmarks & History at our leisure and move bugs to Firefox:Places as needed. Failing that, I suppose we should just merge them, keeping the "Bookmarks & History" name.
Updated•16 years ago
|
Status: UNCONFIRMED → NEW
Ever confirmed: true
Comment 3•16 years ago
|
||
(In reply to comment #2) > Can we "deprecate" Bookmarks & History, so that the bugs still exist, but the > component doesn't show up when trying to file a new bug? That way we can triage > Bookmarks & History at our leisure and move bugs to Firefox:Places as needed. Only products support "deprecation" in the sense of no new bugs. :( > Failing that, I suppose we should just merge them, keeping the "Bookmarks & > History" name. That can be done... Everybody else ok with that?
Assignee | ||
Comment 4•16 years ago
|
||
Another option would be to create an "App Graveyard" product, to go along with "Core Graveyard", and move it into there. That would achieve the goal of "no new bugs" and keep it out of search and so on, while allowing you to triage bugs over into Places at your leisure. That's no more work than any other option. We'd be happy to do that. Gerv
Comment 5•16 years ago
|
||
> > Failing that, I suppose we should just merge them, keeping the "Bookmarks &
> > History" name.
>
> That can be done... Everybody else ok with that?
+1
Comment 6•16 years ago
|
||
i also vote for having "toolkit/Places" and "Firefox/Bookmarks & History" (with Firefox/places bugs merged to Firefox/bookmarks & history)
Comment 7•16 years ago
|
||
(In reply to comment #3) > > Failing that, I suppose we should just merge them, keeping the "Bookmarks & > > History" name. > > That can be done... Everybody else ok with that? Marcia or Reed, we have concurrence from the Places folks on this. When can we have this done?
Assignee | ||
Comment 8•15 years ago
|
||
This has been added to this list: https://wiki.mozilla.org/BMO_Reorg_Phase_2 Implementation of the list is tracked in bug 461546. Gerv
Comment 9•15 years ago
|
||
This has been done.
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Comment 10•15 years ago
|
||
For Firefox i still see both Places and Bookmarks & History. Was not request to merge all Firefox/Places bugs into Firefox/Bookmarks & History and remove Firefox/Places?
Comment 11•15 years ago
|
||
Argh, I overlooked that.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Updated•15 years ago
|
Summary: When entering a new bug for Firefox, both "Bookmarks & History" and "Places" appear in the component list. → Merge components "Bookmarks & History" and "Places" for Firefox
Comment 13•15 years ago
|
||
Any news here? what's blocking doing this?
Assignee | ||
Comment 14•15 years ago
|
||
There are currently 4348 bugs in the Places component; moving them all to "Bookmarks and History" using the GUI would be spamalicious. justdave: is there any way to do this spam-free? Gerv
Assignee | ||
Comment 15•15 years ago
|
||
justdave: ping? :-) Gerv
Comment 16•15 years ago
|
||
(In reply to comment #14) > There are currently 4348 bugs in the Places component; moving them all to > "Bookmarks and History" using the GUI would be spamalicious. > > justdave: is there any way to do this spam-free? Can't make everyone happy. When we do it without spamming people I get complaints that they weren't emailed about it, and when we spam people, people complain about the spam. I'd go with using the GUI and put some unique string in it that people can filter on if they want to nuke it all in one shot.
Comment 17•15 years ago
|
||
why someone should complain to not being notified about a movement from a component to an equivalent one... I could understand if we would be making a component dead or some hard change, but we are simply merging 2 equivalent categories.
Assignee | ||
Comment 18•15 years ago
|
||
OK, I've set this going. Might take a little while :-) Gerv
Comment 19•15 years ago
|
||
In future, maybe RESOLVED bugs could have changes like this done quietly and produce bugspam for open bugs? Just a thought...
Comment 20•15 years ago
|
||
This is drowning me in bug spam. Next time this kind of mass change is performed, how about filing a bug in the relevant component a few days before hand to let people watching it know it's going to happen? I would have stopped watching... Adding a comment with a unique string actually generates *more* bugmail (some people have bugmail disabled for component changes but enabled for comments), and doesn't really make things easier to filter unless your mail client can't filter based on headers. It also doesn't help in Gmail's case, because you can only search for and operate on threads, and I don't want to filter entire threads because then I'd miss non-spam bugmail from the bugs that this touched.
Comment 21•15 years ago
|
||
Further that task got the highest priority over all other bug activity. I haven't got any other bug mail for hours. Now those get sent but with a completely wrong time.
Comment 22•15 years ago
|
||
(In reply to comment #21) > haven't got any other bug mail for hours. Now those get sent but with a > completely wrong time. Wrong how? Looks ok to me.
Comment 23•15 years ago
|
||
(In reply to comment #20) > Adding a comment with a unique string actually generates *more* bugmail (some > people have bugmail disabled for component changes but enabled for comments), > and doesn't really make things easier to filter unless your mail client can't > filter based on headers. Indeed, comments for mass bugspam are generally frowned upon, especially long ones such as what you used. :(
Comment 24•15 years ago
|
||
>> haven't got any other bug mail for hours. Now those get sent but with a >> completely wrong time. > Wrong how? Looks ok to me. Last night bugspam for non-related bugs were delayed by several hours. I mean looking at the actual bug I could see comments being added but bugspam was behind by about 5-7 comments or several hours. At that time I thought that Gmail was just being cranky.
Updated•15 years ago
|
Assignee: marcia → gerv
Assignee | ||
Comment 25•15 years ago
|
||
Gavin: sorry :-( The idea was to do it when America was asleep so that many people could just come in, run a filter, and be done with it, but it took so long that I assume you came into work while it was still running. Gerv
Status: REOPENED → RESOLVED
Closed: 15 years ago → 15 years ago
Resolution: --- → FIXED
Comment 26•15 years ago
|
||
(In reply to comment #24) > >> haven't got any other bug mail for hours. Now those get sent but with a > >> completely wrong time. > > > Wrong how? Looks ok to me. The date header of the email is not correctly set. It has the datetime when the mail has been sent but not the datetime when the comment has been made. Dave, is that something we could improve? > Last night bugspam for non-related bugs were delayed by several hours. I mean > looking at the actual bug I could see comments being added but bugspam was > behind by about 5-7 comments or several hours. At that time I thought that > Gmail was just being cranky. As what I have heard from Frederic this is just Gmail. If a huge amount of messages arrive they block incoming mail.
Comment 27•15 years ago
|
||
(In reply to comment #25) > Gavin: sorry :-( The idea was to do it when America was asleep so that many > people could just come in, run a filter, and be done with it, but it took so > long that I assume you came into work while it was still running. Doesn't really matter when it was done, it would have buried me either way :) I'm still trying to recover...
Comment 28•15 years ago
|
||
FWIW, in Thunderbird 3 i got absolutely no problems, i just set a filter on body, about 3900 mails were put in the trashcan.
Comment 29•15 years ago
|
||
Gerv, if i create a new Firefox bug i still see both Places and Bookmarks & history, while the first should have been removed.
Comment 30•15 years ago
|
||
Same for changing the product/component => Reopen.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Assignee | ||
Comment 31•15 years ago
|
||
The component Firefox/Places has now been deleted. Sorry about that. Gerv
Status: REOPENED → RESOLVED
Closed: 15 years ago → 15 years ago
Resolution: --- → FIXED
Updated•13 years ago
|
Component: Bugzilla: Keywords & Components → Administration
Product: mozilla.org → bugzilla.mozilla.org
You need to log in
before you can comment on or make changes to this bug.
Description
•