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)

task
Not set
normal

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
Assignee: create-and-change → marcia
Component: Creating/Changing Bugs → Bugzilla: Keywords & Components
Product: Bugzilla → mozilla.org
QA Contact: default-qa → timeless
Version: unspecified → other
beltzner/mconnor/dietrich: What do you want to do about these two components?
OS: Windows XP → All
Hardware: PC → All
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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
(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?
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
> > Failing that, I suppose we should just merge them, keeping the "Bookmarks &
> > History" name.
> 
> That can be done... Everybody else ok with that?

+1
Depends on: 461546
i also vote for having "toolkit/Places" and "Firefox/Bookmarks & History" (with Firefox/places bugs merged to Firefox/bookmarks & history)
(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?
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
This has been done.
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
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?
Argh, I overlooked that.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
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
Any news here? what's blocking doing this?
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
justdave: ping? :-)

Gerv
(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.
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.
OK, I've set this going. Might take a little while :-)

Gerv
In future, maybe RESOLVED bugs could have changes like this done quietly and produce bugspam for open bugs? Just a thought...
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.
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.
(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.
(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. :(
>> 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.
Assignee: marcia → gerv
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 ago15 years ago
Resolution: --- → FIXED
(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.
(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...
FWIW, in Thunderbird 3 i got absolutely no problems, i just set a filter on body, about 3900 mails were put in the trashcan.
Gerv, if i create a new Firefox bug i still see both Places and Bookmarks & history, while the first should have been removed.
Same for changing the product/component => Reopen.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
The component Firefox/Places has now been deleted. Sorry about that.

Gerv
Status: REOPENED → RESOLVED
Closed: 15 years ago15 years ago
Resolution: --- → FIXED
woooo, verified.
Status: RESOLVED → VERIFIED
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.