Reorganization of bugzilla.mozilla.org?

[old jasonb]

Is there any thinking yet on how b.m.o. will be used for filing of bugs once Firebird/Thunderbird replaces Seamonkey and the old Mail/News component?

Specifically:

1. When I have a bug with Thunderbird (I won't be using it but am using this as an example) will I be filing it under the Mail/News product, or under a newly created Thunderbird product? (There's already a bug open on whether or not such a new product should be created.)

2. When I have a bug with the browser - will it go under "Firebird" or "Browser"? (I.e. what will "Browser" be referring to after the merge - the legacy browser, or the "new" one - if the latter, Browser should be renamed to something else, like Seamonkey, and Firebird changed to Browser... Which might also explain why we still have a component named "Phoenix" - there's little point in fixing things now if it's only going to be fixed again shortly after.)

3. What happens to all of the open bugs in the current suite's products/components categories? After the switch, many will become invalid or worksforme (since they'll be irrelavent or no longer meaningful). Is it all just up to people to resolve their particular bugs, or will somebody go through everything in a general "cleanup" procedure? (Am I even "allowed" to close a Browser filed bug after the switch given that I'll no longer care about it at that point? If so, what resolution should I give it? There's no "Withdrawn" resolution... Or is it to remain open for legacy purposes?)

4. Will there be an Extensions product or component category added, such that b.m.o. can be used to file bugs with (at last some - such as mozilla.org authored) extensions?

5. What kind of preparations are going to be made for the massive influx of b.m.o. activity due to confusion / complaints / enhancement requests, etc., with people saying that Mozilla no longer does this, that, or the other thing. (This is both from the backend system side of things and a logical problem handling perspective.)

Have there been any official, or unofficial, comments with respect to any of these points, or others I haven't yet mentioned? Surely this is something that should be addressed proactively. I'd hate to think that all of these changes just "happen" and b.m.o. is throw into fire-fighting mode on the spot.

BTW: I'm bringing this up now because Asa's announcement of the 1.4 branch being cut made me realise that we're getting ever closer to the merge (which sounds a bit too much like Survivor - but nevermind).

[WeSaySo]

3. What happens to all of the open bugs in the current suite's products/components categories? After the switch, many will become invalid or worksforme (since they'll be irrelavent or no longer meaningful). Is it all just up to people to resolve their particular bugs, or will somebody go through everything in a general "cleanup" procedure?

I've asked in several MacOS 9 bugs whether they should be closed and have gotten no response. Moz for OS 9 was dropped after 1.2.1, so it's a similar situation.

(Am I even "allowed" to close a Browser filed bug after the switch given that I'll no longer care about it at that point? If so, what resolution should I give it? There's no "Withdrawn" resolution...

If it's your bug, and you think it's no longer has any meaning with the new Mozilla products, I'd say it's a toss up btw CLOSED/INVALID and CLOSED/WONTFIX. INVALID because it'd be like if I filed a Netscape7 specific bug to Browser or WONTFIX because the bug is asking to fix something that will create a broken product. I personally lean towards CLOSED/INVALID. Would be nice to get some input from Asa or other drivers. The switch will foobar Bugzilla.

[quote="jasonb"Or is it to remain open for legacy purposes?)[/quote]
Will there be any development of Seamonkey after the disembodied projects stabilize into the trunk?

[michaell522]

Is there any thinking yet on how b.m.o. will be used for filing of bugs once Firebird/Thunderbird replaces Seamonkey and the old Mail/News component?

I've seen some "thinking" (in the newsgroups somewhere I think) which was for components to be renamed and new components to be introduced where necessary, so the existing components for seamonkey UI would stay around (the 1.4 branch will still be around and needs somewhere to track bugs, and there may possibly be folks continuing with a seamonkey build based on trunk, as a spin-off like Firebird is now), but be called "seamonkey ...", and the Phoenix product/components will be renamed. That would allow all the existing bugs and components to stay around, while hopefully directing new bugs into the right places. But that was just a suggestion, I don't think decisions have been made (or if they have, they haven't been communicated). I don't think final decisions have been made about how the code is going to be moved around and how the builds are going to work (things may or may not be split up - splitting up would mean people need several build processes to make GRE and Firebird and Thunderbird, but not splitting up means you need all the code to do anything - like you currently need the whole of Mozilla to build Firebird), and it wouldn't make sense to try and reorganise bugzilla until at least those decisions have been made.

It's probably best that nobody even attempts to deal with these issues until the changes are made to bugzilla. Remember that although they're about to cut the branch, the mozilla trunk immediately after the branch will continue to be seamonkey in the short term, until things are switched around so that the trunk builds are based on the Firebird toolkit. Although there would be no point in changing seamonkey UI on the trunk, people can still make gecko changes which will appear in the interim seamonkey trunk builds, and the firebird builds in the current structure, and those changes will carry through to the new structure.

I don't know what the timescale is for making the big switch, but I guess there may be a period while 1.4 is being finished off, where back-end stuff is done on the trunk and front-end stuff is done in the existing, separate Firebird. I think there was talk of doing another Firebird release before doing the switchover.

Until the trunk has actually switched to the Firebird/Thunderbird UIs, I think we should carry on as we do now. In terms of testing effort, they will want people to keep using the 1.4 branch for the moment, including the release candidates, to avoid a situation like 1.2 where the testing of the branch drops off and bugs slip into the release.

I'm not sure where that leaves your daily posts though - you could keep following the trunk, which would give half the story for people using Firebird builds; or you could report on the 1.4 branch, or you could report on trunk and branch, or maybe trunk + Phoenix, or even trunk + branch + phoenix? Lots of options

wow... that was long... sorry for waffling on - I don't even know what I'm talking about here, this is speculation

[old jasonb]

I've seen some "thinking" (in the newsgroups somewhere I think) which was for components to be renamed and new components to be introduced where necessary

Aha.

That would allow all the existing bugs and components to stay around, while hopefully directing new bugs into the right places.

I knew they would still exist somewhere, I was just wondering where and of what value they would be...

It's probably best that nobody even attempts to deal with these issues until the changes are made to bugzilla.

It all comes down to timing. I'm thinking that they pretty much have to make the browser mail/news switch in the suite at the very same time that the changes to b.m.o. are made. In other words, the first time we see a nightly that has the "new" face on it, b.m.o. will have been redone to support entries against it. If b.m.o. is changed either before or after the new suite is introduced, there will be a lot of confusion. So, hopefully, they'll have everything redone in the "background" (or just a list of tasks that will need to be peformed in terms of the renames) and then just flip the switch, as it were, all at once.

I'm not sure where that leaves your daily posts though

I'll keep following the trunk - or whatever it is that I download each day and use on my own computer. It's hard enough keeping track of the things I use, let alone the things I don't.

[old jasonb]

Will there be any development of Seamonkey after the disembodied projects stabilize into the trunk?

Theoretically, yes. In practice, it's not clear. We can only wait and see what kind of interest remains in the project once it's been "side tracked".

[michaell522]

It's probably best that nobody even attempts to deal with these issues until the changes are made to bugzilla.

It all comes down to timing. I'm thinking that they pretty much have to make the browser mail/news switch in the suite at the very same time that the changes to b.m.o. are made.
[..]
So, hopefully, they'll have everything redone in the "background" (or just a list of tasks that will need to be peformed in terms of the renames) and then just flip the switch, as it were, all at once.

Shifting bits of the code tree around, changing all the tinderboxes and builds to use the new setup and getting it all to work will take a while. I guess, as with setting up new branches and stuff, it won't so much be done in the background, but just by holding things up - if the process takes a couple of days, it will just mean that there are no builds and no checkins for a couple of days. Even after they've made the big changes, it might need some bug fixing before there's a build that's at all usable.

But as you say, hopefully by the time a usable build of a different kind appears, we will know what's going on, and the bugzilla bits will have been renamed...

[alanjstr]

Will there be any development of Seamonkey after the disembodied projects stabilize into the trunk?

Theoretically, yes. In practice, it's not clear. We can only wait and see what kind of interest remains in the project once it's been "side tracked".

Well, since 1.4 is the last "big release" and what Netscape (etc.) will be using for their next versions, I would expect the 1.4 tree to keep going like the 1.0 tree. For now, I would refer to bugs in the Suite as Browser and Mail/News and items for standalone as Firebird and Thunderbird. I think bugs should be moved from Browser to "Phoenix" as appropriate or have a duplicate filed under "Phoenix."

[old jasonb]

As soon as the switch-over happens, I will be re-evaluating all of my existing (open) Seamonkey Browser bugs, and resolving them as WORKSFORME / INVALID, or switching the product over to Firebird (whatever it happens to be called).