Security

(public)

User Story

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

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.

(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

(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?

(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.

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.

>> 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.

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

(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...