Bon Echo Project Status: remaining "to-do" items
beltzner
Just a reminder that there are no more Bon Echo planning meetings, as
the project has now moved into its maintenance phase of lifecycle
planning. Watch this space for announcements on MOZILLA_1_8_BRANCH
release planning for the Firefox 2.0.0.* security and stability
releases.
There are two outstanding to-do items left from the Bon Echo project
which are currently being driven by yours truly:
1. Determine if 1.5.0.8+ users should be offered an upgrade to 2.0 or
2.0.0.1 based on the release schedule for the 2.0.0.1 release and the
nature of fixes included.
2. Finalize and announce NPOTB policy for the branch.
I hope to have these remaining issues resolved by the end of today or
tomorrow, and will use this thread to track them.
cheers,
mike
(ps: it's been a fantastic experience working on this release with the
entire community, and proving that it can be done in a very public and
distributed fashion.)
--
/ mike beltzner / phenomenologist / mozilla corporation /
Jay Patel
> All,
>
> Just a reminder that there are no more Bon Echo planning meetings, as
> the project has now moved into its maintenance phase of lifecycle
> planning. Watch this space for announcements on MOZILLA_1_8_BRANCH
> release planning for the Firefox 2.0.0.* security and stability
> releases.
regular 2.0.0.x releases (and 1.5.0.x for a while longer too) going
forward...so we hope to work together with the community to continue to
ship solid and secure Firefox releases.
>
> There are two outstanding to-do items left from the Bon Echo project
> which are currently being driven by yours truly:
>
> 1. Determine if 1.5.0.8+ users should be offered an upgrade to 2.0 or
> 2.0.0.1 based on the release schedule for the 2.0.0.1 release and the
> nature of fixes included.
2.0.0.1, so they can jump straight to that version. This should save
both build and qa a lot of time...and make it simple for users (just get
1 update instead of 1 update to 2.0 and then another a few days later
for 2.0.0.1).
>
> 2. Finalize and announce NPOTB policy for the branch.
land NPOTB checkin on the 1.8.1 branch... hope that was ok! ;-)
>
> I hope to have these remaining issues resolved by the end of today or
> tomorrow, and will use this thread to track them.
>
> cheers,
> mike
>
> (ps: it's been a fantastic experience working on this release with the
> entire community, and proving that it can be done in a very public and
> distributed fashion.)
getting Firefox 2.0 planned, developed, and shipped... with a little
help from their friends, of course. ;-) Thanks guys!
- Jay
Peter Weilbacher
> 2. Finalize and announce NPOTB policy for the branch.
>
> I hope to have these remaining issues resolved by the end of today or
> tomorrow, and will use this thread to track them.
Was this announced somewhere in the meantime? (Because I keep asking for
branch approval for stuff in OS/2 code and perhaps I don't need to
bother the review team with that any more...)
Peter.
Eddie
> 2. Finalize and announce NPOTB policy for the branch.
NPOTB?
A few of us in the peanut gallery were just wondering what in the world
that could be.
Oh, and, on #1: since (I read somewhere I think) Ff 1.5.0.7 users
were given the choice of either:
- upgrading to 2.0.0.0
- updating to 1.5.0.8
those who chose Not to upgrade at that time may have had good reasons.
Therefor, the next offer to upgrade should be to a newer,
More Better version: 2.0.0.1,
and also later: 2.0.0.2,
since you won't be getting caught up with bug fixes (VISTA, whatever)
until then.
Thank you,
Eddie
Mike Beltzner
> beltzner wrote:
>> 2. Finalize and announce NPOTB policy for the branch.
>
> NPOTB?
Not Part Of The Build - refers to CVS checkins affecting code that
isn't built as part of the Firefox build process, so Seamonkey-only,
XForms, OS/2 or BeOS specific code. Sorry 'bout the acronym-without-
explanation.
> Oh, and, on #1: since (I read somewhere I think) Ff 1.5.0.7 users
> were given the choice of either:
> - upgrading to 2.0.0.0
> - updating to 1.5.0.8
You read/imagined false information. We haven't published an update
to 2.0 for any users yet, and users running Firefox 1.5.0.7 or
previous will have to accept the update to 1.5.0.8 before being able
to get the update to Firefox 2.0. That's because Firefox 1.5.0.8
contains the code that understands what a "major version" update is,
and presents UI that allows users to choose between staying with
Firefox 1.5.* or upgrading to Firefox 2.0.
cheers,
mike
Mike Beltzner
> Was this announced somewhere in the meantime? (Because I keep
> asking for
> branch approval for stuff in OS/2 code and perhaps I don't need to
> bother the review team with that any more...)
Earlier in this thread Jay said that he and dveditz declared the
branch open to NPOTB again, so go ahead. I'll try to assemble a
DevNews post on these issues today or early next week.
cheers,
mike
Aaron Reed
Interesting...so what happens if you have 1.5.x-only extensions and you
upgrade to 2.0? Is there some kind of warning or are you updated and
then these extensions stop working?
--Aaron
Mike Beltzner
> Interesting...so what happens if you have 1.5.x-only extensions and
> you upgrade to 2.0? Is there some kind of warning or are you
> updated and then these extensions stop working?
This was all discussed in Bon Echo project meetings (see notes at
http://wiki.mozilla.org/Firefox2/StatusMeetings), but for the sake of
completeness, if there are compatibility updates to those extensions
available then users aren't warned, and instead those updates are
applied as users upgrade to Firefox 2.0. If no compatibility updates
exist, then users are warned at the point that the upgrade to 2.0 is
offered.
cheers,
mike
Pavel Cvrcek
> 1. Determine if 1.5.0.8+ users should be offered an upgrade to 2.0 or
> 2.0.0.1 based on the release schedule for the 2.0.0.1 release and the
> nature of fixes included.
Any news about this? Will offer update for 1.5.0.8(9) to 2.0 or 2.0.0.1?
--
Regards,
Pavel Cvrcek
Eddie
> > NPOTB?
>
> Not Part Of The Build - refers to CVS checkins affecting code that
> isn't built as part of the Firefox build process, so Seamonkey-only,
> XForms, OS/2 or BeOS specific code. Sorry 'bout the acronym-without-
> explanation.
Never would have guessed. Thank you. I run SeaMonkey 1.1 nightlies, and
love it.
> > Oh, and, on #1: since (I read somewhere I think) Ff 1.5.0.7 users
> > were given the choice of either:
> > - upgrading to 2.0.0.0
> > - updating to 1.5.0.8
>
> You read/imagined false information. We haven't published an update
> to 2.0 for any users yet,
It's my memory, or understanding, of that info that was false, not the
info itself. Sorry. Thanks for clarifying.
> and users running Firefox 1.5.0.7 or
> previous will have to accept the update to 1.5.0.8 before being able
> to get the update to Firefox 2.0. That's because Firefox 1.5.0.8
> contains the code that understands what a "major version" update is,
> and presents UI that allows users to choose between staying with
> Firefox 1.5.* or upgrading to Firefox 2.0.
Ok, so that usability "feature" of choosing between Upgrade or Update
is what was implemented, but not used, in 1.5.0.8. Got it. Sounds good.
I still say, wait 'till 2.0.0.1 to use it the first time, since it's
been this long since 2.0.0.0 and 2.0.0.1 is relatively soon. Also, the
knowledgable impatient already have 2.0.0.0. The rest might be better
off waiting for 2.0.0.1, or even 2.0.0.2, depending... Just my two
peanuts worth...
Thanks,
Eddie
Philip Chee
> On 1-Dec-06, at 12:25 PM, Eddie wrote:
>> beltzner wrote:
>>> 2. Finalize and announce NPOTB policy for the branch.
>> NPOTB?
> Not Part Of The Build - refers to CVS checkins affecting code that
> isn't built as part of the Firefox build process, so Seamonkey-only,
> XForms, OS/2 or BeOS specific code. Sorry 'bout the acronym-without-
> explanation.
I think that the SeaMonkey Council CVS checkin policy is as stringent as
Firefox if not more so. I suspect that they may not be too happy if
people are allowed to checkin SM stuff without running it past them first.
Phil
--
Philip Chee <phi...@aleytys.pc.my>, <phili...@gmail.com>
http://flashblock.mozdev.org/ http://xsidebar.mozdev.org
Guard us from the she-wolf and the wolf, and guard us from the thief,
oh Night, and so be good for us to pass.
[ ]I know and I know you know I know.
* TagZilla 0.059.1
Robert Kaiser
> On Fri, 01 Dec 2006 11:36:16 -0600, Mike Beltzner wrote:
>> Not Part Of The Build - refers to CVS checkins affecting code that
>> isn't built as part of the Firefox build process, so Seamonkey-only,
>> XForms, OS/2 or BeOS specific code. Sorry 'bout the acronym-without-
>> explanation.
>
> I think that the SeaMonkey Council CVS checkin policy is as stringent as
> Firefox if not more so. I suspect that they may not be too happy if
> people are allowed to checkin SM stuff without running it past them first.
This is not what they are saying here... It just means that doesn't need
Firefox/Thunderbird/Core drivers' approval to check in stuff in those
parts of the code - the rules of the respective module always do apply,
in our case the SeaMonkey checkin rules - which on the branch means that
every checkin of SeaMonkey-sepcific code needs Council approval.
This is not changed by beltzner declaring that NPOTB in the Firefox
world - actually, it helps us by being able to follow our own policies
only for code that only affects us.
Robert Kaiser
Philip Chee
> This is not what they are saying here... It just means that doesn't need
> Firefox/Thunderbird/Core drivers' approval to check in stuff in those
> parts of the code - the rules of the respective module always do apply,
> in our case the SeaMonkey checkin rules - which on the branch means that
> every checkin of SeaMonkey-sepcific code needs Council approval.
> This is not changed by beltzner declaring that NPOTB in the Firefox
> world - actually, it helps us by being able to follow our own policies
> only for code that only affects us.
Hmm. What about bugs in the core component or mailnews but the patch(es)
touch forked files (SeaMonkey/Firefox or SeaMonkey/Thunderbird). I think
I mentioned in #seamonkey needing SM specific flags for these cases.
Phil
--
Philip Chee <phi...@aleytys.pc.my>, <phili...@gmail.com>
http://flashblock.mozdev.org/ http://xsidebar.mozdev.org
Guard us from the she-wolf and the wolf, and guard us from the thief,
oh Night, and so be good for us to pass.
[ ]Riker to Enterprise. Beam down Troi and a six-pack.
* TagZilla 0.059.1
Robert Kaiser
> Hmm. What about bugs in the core component or mailnews but the patch(es)
> touch forked files (SeaMonkey/Firefox or SeaMonkey/Thunderbird). I think
> I mentioned in #seamonkey needing SM specific flags for these cases.
File a bug to get those falgs added in the prodaucts where you need them
and hear/see what bugzilla admins say or if they just add them :)
Any change in SeaMonkey-specific code needs to follow the SeaMonkey
policies for sure.
Robert Kaiser
Chris Ilias
> My vote is to release the update to 1.5.0.8 users after we release
> 2.0.0.1, so they can jump straight to that version.
Well, it appears this didn't happen. 1.5.0.8 users were only offered an
update to 1.5.0.9. So what's the current plan on the 1.5.x-->2.0.x
auto-update?
--
Chris Ilias
mozilla.test.multimedia moderator
Mozilla links <http://ilias.ca>
(Please do not email me tech support questions)
Mike Connor
On 20-Dec-06, at 4:33 AM, Chris Ilias wrote:
> _Jay Patel_ spoke thusly on 21/11/2006 7:24 PM:
>> My vote is to release the update to 1.5.0.8 users after we release
>> 2.0.0.1, so they can jump straight to that version.
>
> Well, it appears this didn't happen. 1.5.0.8 users were only
> offered an update to 1.5.0.9. So what's the current plan on the
> 1.5.x-->2.0.x auto-update?
Didn't happen yet, of course, and I'm sure Jay didn't mean
immediately after. The load on our network/mirrors from a security
release is massive, and a major release is going to be pushing much
bigger packages. We're planning on doing this sometime in January.
-- Mike