In case you didn't notice already, Bug #335540 landed on the 1.8 branch today making DM depend on mozstorage. This means projects building on the 1.8 branch (thunderbird, camino, seamonkey, etc) that aren't configured to build with mozstorage are going to go red.
I'm band-aiding the Thunderbird builds, but I think we should decide one of the following:
1) add MZ_STRAGE ifdefs around the dom changes so you can still build without depending on MZ_STRAGE
2) Set MZ_STRAGE=1 for everyone and not on a per product basis since gecko will no longer build without it.
I'm in favor of option 1. Will projects like minimo want or be able to take mozstorage? will everyone want it anyway in which case option 2 might be best.
-Scott
dev-planning mailing list
dev-planning (AT) lists (DOT) mozilla.org

Scott MacGregor wrote:
In case you didn't notice already, Bug #335540 landed on the 1.8
branch today making DM depend on mozstorage.
Bug 337208 was filed to deal with this issue.
dev-planning mailing list
dev-planning (AT) lists (DOT) mozilla.org

Scott MacGregor wrote:
1) add MZ_STRAGE ifdefs around the dom changes so you can still build
without depending on MZ_STRAGE

2) Set MZ_STRAGE=1 for everyone and not on a per product basis since
gecko will no longer build without it.

I'm in favor of option 1. Will projects like minimo want or be able to
take mozstorage? will everyone want it anyway in which case option 2
might be best.

I think that minimo will want mozstorage since it'll become part of our
platform just like XMLHttpRequest has. It seems to make less sense for
things like thunderbird though which doesn't really have the concept of
browsing and where storage seems to add very little value.

/ Jonas

dev-planning mailing list
dev-planning (AT) lists (DOT) mozilla.org

Jonas Sicking wrote:

I think that minimo will want mozstorage since it'll become part of our
platform just like XMLHttpRequest has. It seems to make less sense for
things like thunderbird though which doesn't really have the concept of
browsing and where storage seems to add very little value.

storage is not a small hit for minimo. I agree that minimo should support
the offline-storage API if possible: using devices in offline mode seems a
pretty common need. But sqlite is going to cause performance problems on
flash memory storage due to the way it does block writes.

I'm less concerned about tbird/minimo/other desktop apps: we should have one
platform for the desktop (which is one of the reasons we're pushing the
common XULRunner base for all the desktop apps).

dev-planning mailing list
dev-planning (AT) lists (DOT) mozilla.org

Scott MacGregor schrieb:
1) add MZ_STRAGE ifdefs around the dom changes so you can still build
without depending on MZ_STRAGE

2) Set MZ_STRAGE=1 for everyone and not on a per product basis since
gecko will no longer build without it.

For Camino, SeaMonkey, etc. I don't care which one of the poaths is
taken, but the current situation (changing a said-to-be-stable-on-branch
interface and breaking the whole world besides Firefox and Sunbird) is
completely unacceptable on a branch like 1.8 that was said to have a
stable Gecko.

IMH, this stuff needs to be backend out from the branch until the
situation is fixed in default builds of all our applications - and
probably even until the interface stability on branch is given as well,
as I don't think it's a good idea to e.g. ship an alpha with the changed
interface.

Checking this in with such a breakage of tree and branch rules is
actually very bad habit and should be very much discouraged - and, as I
said, backend out until the issues are fixed in a new patch.

Robert Kaiser

dev-planning mailing list
dev-planning (AT) lists (DOT) mozilla.org

5/9/06, Robert Kaiser <kairo (AT) kairo (DOT) atwrote:
For Camino, SeaMonkey, etc. I don't care which one of the poaths is
taken, but the current situation (changing a said-to-be-stable-on-branch
interface and breaking the whole world besides Firefox and Sunbird) is
completely unacceptable on a branch like 1.8 that was said to have a
stable

Are you not able to add the config flag to the SeaMonkey build and get
it fixed? Why not do that and make your tree green? (And add
dom_storage.xpt to the installer manifest.)

The branch interfaces were fixed at 7pm Pacific yesterday, 10 hours
before you posted your message.

IMH, this stuff needs to be backend out from the branch until the
situation is fixed in default builds of all our applications

I don't think that Camino and SeaMonkey should block landing this on
the branch, especially given that it's a trivial config change (just
made by the Camino guys, in fact) to get storage built and packaged.
- and
probably even until the interface stability on branch is given as well,
as I don't think it's a good idea to e.g. ship an alpha with the changed
interface.

That's nice. As above, the interface issue is fixed. If you're still
seeing an interface difference on the branch, please reopen 337205 and
explain what you see failing!

Checking this in with such a breakage of tree and branch rules is
actually very bad habit and should be very much discouraged - and, as I
said, backend out until the issues are fixed in a new patch.

Why go backwards instead of forwards? Camino and Tbird are fine now
(or are expected to be, in the case of Camino), so why not update the
SeaMonkey config and move on?

Mike

dev-planning mailing list
dev-planning (AT) lists (DOT) mozilla.org

Mike Shaver schrieb:
Are you not able to add the config flag to the SeaMonkey build and get
it fixed? Why not do that and make your tree green? (And add
dom_storage.xpt to the installer manifest.)

For one thing, the checkin happened shortly before I went to sleep, and
I posted the message after getting up and doing some other business
stuff. As we weren't told before the checkin that this would happen, it
caught us unprepared and we took a few hours to only know a working
band-aid which is still no really suitable fix (see below).

But thanks for at least telling us about the installer manifest stuff
here, else I would still not know about needing that as well :(

The branch interfaces were fixed at 7pm Pacific yesterday, 10 hours
before you posted your message.

I didn't realize that before because of no mentioning in the bug and the
interface bug being still open. I only did see that after writing the
message when I looked into bonsai.

>IMH, this stuff needs to be backend out from the branch until the
>situation is fixed in default builds of all our applications

I don't think that Camino and SeaMonkey should block landing this on
the branch, especially given that it's a trivial config change (just
made by the Camino guys, in fact) to get storage built and packaged.

And wrongly so. Making a hard dependency of DM on storage without
making the build system know to always build storage when building DM
is just bad design. Band-aiding over it on the app side is a hack that
shouldn't be required and with applying it everywhere the core issue
will never be fixed.

>Checking this in with such a breakage of tree and branch rules is
>actually very bad habit and should be very much discouraged - and, as I
>said, backend out until the issues are fixed in a new patch.

Why go backwards instead of forwards? Camino and Tbird are fine now
(or are expected to be, in the case of Camino), so why not update the
SeaMonkey config and move on?

We probably could, but it's wrong design anyways.

Additionally, landing bigger Gecko changes on a branch that was said to
have a stable Gecko without landing on trunk before is also completely
wrong according to my understanding of the rules.

Robert Kaiser

dev-planning mailing list
dev-planning (AT) lists (DOT) mozilla.org

Mike Shaver wrote:
5/9/06, Robert Kaiser <kairo (AT) kairo (DOT) atwrote:

>Checking this in with such a breakage of tree and branch rules is
>actually very bad habit and should be very much discouraged - and, as I
>said, backend out until the issues are fixed in a new patch.

Why go backwards instead of forwards? Camino and Tbird are fine now
(or are expected to be, in the case of Camino), so why not update the
SeaMonkey config and move on?

come on now, I can't speak for any project in particular, but I can
see there are several conflicts with the general mozilla ethos that have
occured with this checkin.

If I'm wrong about these, then I apologise in advance and please do put
me right, however, these are from my observations so far:

a) It wasn't checked in on trunk first as per rules.

Hey everyone, lets do development on branch and end up with another
Aviary. Yes the trunk is closed - live with it, fix it, don't disobey
the rules that are there for everyone (and yes so what, FF alpha 2 will
be delayed another couple of days). I'd love to be checking stuff in
now, but I can't, I've no idea what ff leak problem is, so I just have
to sit and wait.

b) The trees weren't monitored for breakage.

From what I can tell, Scott had to pick up the Thunderbird breakage a
couple of hours later, Camino & SeaMonkey are also having to pick up
their breakages.

c) Trees haven't been fixed.

Normally, If a developer breaks a tree that isn't their own, they fix
it. That hasn't happened here, or even help been offered from what I can
tell.

d) Projects weren't informed (as far as I can tell)

Such a dependency that is being introduced in a core part of the
project, on a branch that is meant to be relatively stable without
notifying all projects is just wrong.

This says to me that FF follows the rules most of the time, but does
what it wants on special occasions, but everyone else still have to obey
the rules FF makes up. This is a community where we should be working
together not against each other.

Mark Banner

dev-planning mailing list
dev-planning (AT) lists (DOT) mozilla.org

Jonas Sicking wrote:
Scott MacGregor wrote:
>1) add MZ_STRAGE ifdefs around the dom changes so you can still
>build without depending on MZ_STRAGE
>>
>2) Set MZ_STRAGE=1 for everyone and not on a per product basis
>since gecko will no longer build without it.
>>
>I'm in favor of option 1. Will projects like minimo want or be able
>to take mozstorage? will everyone want it anyway in which case
>option 2 might be best.

It seems MZ_STRAGE was added to multiple sections in configure.in
Should we simply do the same thing for SeaMonkey and check it in to
MZILLA_1_8_BRANCH?
The attached patch fixes building SeaMonkey for me.

Kai

Index: mozilla/configure.in

RCS file: /cvsroot/mozilla/configure.in,v
retrieving revision 1.1503.2.63
diff -u -1 -0 -r1.1503.2.63 configure.in
mozilla/configure.in9 May 2006 07:27:23 -00001.1503.2.63
mozilla/configure.in9 May 2006 16:31:10 -0000
@@ -4218,20 +4218,21 @@

case "$MZ_BUILD_APP" in
suite)
MZ_APP_NAME=seamonkey
MZ_APP_DISPLAYNAME=SeaMonkey
MZ_MAIL_NEWS=1
MZ_LDAP_XPCM=1
MZ_CMPSER=1
MZ_SUITE=1
MZ_PRFILESHARING=
+ MZ_STRAGE=1
MZ_APP_VERSIN=$SEAMNKEY_VERSIN
MZ_EXTENSINS_DEFAULT=" cookie wallet content-packs xml-rpc xmlextras help p3p pref transformiix venkman inspector irc universalchardet typeaheadfind webservices spellcheck gnomevfs auth sroaming permissions reporter"
AC_DEFINE(MZ_SUITE)
;;

browser)
MZ_APP_NAME=firefox
MZ_APP_DISPLAYNAME=BonEcho
MZ_XUL_APP=1
MZ_PHENIX=1

dev-planning mailing list
dev-planning (AT) lists (DOT) mozilla.org

Kai Engert schrieb:
It seems MZ_STRAGE was added to multiple sections in configure.in
Should we simply do the same thing for SeaMonkey and check it in to
MZILLA_1_8_BRANCH?
The attached patch fixes building SeaMonkey for me.

It's just the wrong thing to do as it is a workaround for the real
problem (even if it corrects the builds for the moment).

has the real fix,
and I hope bsmedberg will be able to check this in soon.

Robert Kaiser

dev-planning mailing list
dev-planning (AT) lists (DOT) mozilla.org

Mike Shaver wrote:
5/9/06, Robert Kaiser <kairo (AT) kairo (DOT) atwrote:
For Camino, SeaMonkey, etc. I don't care which one of the poaths is
taken, but the current situation (changing a said-to-be-stable-on-branch
interface and breaking the whole world besides Firefox and Sunbird) is
completely unacceptable on a branch like 1.8 that was said to have a
stable

Are you not able to add the config flag to the SeaMonkey build and get
it fixed? Why not do that and make your tree green? (And add
dom_storage.xpt to the installer manifest.)

The branch interfaces were fixed at 7pm Pacific yesterday, 10 hours
before you posted your message.

IMH, this stuff needs to be backend out from the branch until the
situation is fixed in default builds of all our applications

I don't think that Camino and SeaMonkey should block landing this on
the branch, especially given that it's a trivial config change (just
made by the Camino guys, in fact) to get storage built and packaged.

The only reason the Camino fix made it in, is that Asaf was around late
at night (for us) and was willing to make this change. , it
would have been red well into the morning.

Don't ever base a "quick fix" from Camino as proof that it's a trivial
config change. There were three changes needed to get the fix in for
Camino, including project changes. Given the fact that changing the
project requires XCode 1.5 (or, I believe 2.0, which no one uses) and
that XCode 1.5 requires Mac S X 10.3, it was a miracle that we got
that fix in last night.
- and
probably even until the interface stability on branch is given as well,
as I don't think it's a good idea to e.g. ship an alpha with the changed
interface.

That's nice. As above, the interface issue is fixed. If you're still
seeing an interface difference on the branch, please reopen 337205 and
explain what you see failing!

Checking this in with such a breakage of tree and branch rules is
actually very bad habit and should be very much discouraged - and, as I
said, backend out until the issues are fixed in a new patch.

Why go backwards instead of forwards? Camino and Tbird are fine now
(or are expected to be, in the case of Camino), so why not update the
SeaMonkey config and move on?

Why not? Because it's not going backwards. Tree rules have always said
that changes like this should land on the trunk first and then, after
testing, land on the branch. Given that the trunk was closed, when did
this happen?

And, might I add, wasn't the branch even closed for a Bon Echo a2
freeze? I missed exactly when that happened, but I *swear* it was
before these changes landed. If nothing else, I remember reading that
the branch and trunk were closed for perf regressions. Did this checkin
honor that?

I echo exactly what Mark Banner said above. This is completely
unacceptable. It's happened in the past and something needs to be done
to ensure it doesn't happen in the future.

Samuel Sidler

dev-planning mailing list
dev-planning (AT) lists (DOT) mozilla.org

9 May 2006 10:40:49 -0700, samuel.sidler (AT) gmail (DOT) com
<samuel.sidler (AT) gmail (DOT) comwrote:
Don't ever base a "quick fix" from Camino as proof that it's a trivial
config change. There were three changes needed to get the fix in for
Camino, including project changes. Given the fact that changing the
project requires XCode 1.5 (or, I believe 2.0, which no one uses) and
that XCode 1.5 requires Mac S X 10.3, it was a miracle that we got
that fix in last night.

I'm not basing the triviality of the config change on Camino being
able to make a quick fix, I'm basing it on the fact that it's a one
line change (as it was for Tbird), which has been visible in bonsai
and the tinderbox display for many hours.

(If developers can't work because fixing their build requires a rare
tool or config, I think you're talking about a pretty special case,
and not one which should guide general behaviour, but maybe I'm not
understanding.)

And, might I add, wasn't the branch even closed for a Bon Echo a2
freeze? I missed exactly when that happened, but I *swear* it was
before these changes landed. If nothing else, I remember reading that
the branch and trunk were closed for perf regressions. Did this checkin
honor that?

This checkin was explicitly requested by the people driving the a2
release, in order to get it into a2 for testing by web authors,
feedback to the spec authors, etc. Thanks for the concern, though.
:)

Mike

dev-planning mailing list
dev-planning (AT) lists (DOT) mozilla.org

5/9/06, Mike Shaver <mike.shaver (AT) gmail (DOT) comwrote:
Mistakes were made here, and I definitely made some of them. But I
certainly had no malice in my heart towards any other projects when I
made recommendations for the courses we took (or even the ones that we
didn't take), and accusations of such things are not likely to make it
easier to co-operate on making these things better in the future.

I want to elaborate on this further.

I advocated (strongly, which I'm sure is no surprise) that we push to
get the session storage work into MZILLA_1_8_BRANCH to ship in 1.8a2,
once it was pushed back into the Firefox2/Gecko1.8.1 agenda. I wanted
us to get it in front of web developers with time to get their
feedback, help find strange interactions and performance issues, and
cycle back with the WHATWG on spec tuning, and I believed (still do)
that we would get much better results if we had it in a2 than if we
had to wait for b1. I pushed people (Neil and jst) to implement and
review on a tight cycle, and advocated landing on the branch first
when we saw that there was a crash on the trunk (only) and the trunk
was locked down for perf/leaks, so I certainly need to shoulder some
blame for where we are today. I still stand by my goal there, and if
we'd made _one_ little config fix ahead of time I think I would be the
target of much less scorn today :), but with influence has to come
responsibility, and this is what it tastes like when your predictions
don't line up with reality.

I did not do it with the intent of screwing other projects, and I am
genuinely sorry that it had the negative impact there that it did. I
am frustrated with what I percieved as a knee-jerk demand for a
backout for reasons of "purity", when it seemed that a configuration
change would get the other projects back into the game without
sacrificing the feature or reducing the amount of time we have to get
feedback from web developers.

We're going to revisit that decision, in light of last night's churn
and some bugs found since, and I hope that everyone here believes me
when I say that I will try to have better foresight of the effects on
other sub-projects when I push for things that I think are important
to the project. I think I did almost all of the right things, given
the information I had and what I wanted for the project, so don't
expect me to change my stripes all that much, but I'll remember this
thread for a fair while when I'm reviewing and advocating major
changes!

Mike

dev-planning mailing list
dev-planning (AT) lists (DOT) mozilla.org

Howdy,

Some mistakes were made here - but Shaver and everyone were really
trying hard to do the right thing here. No malice intended, certainly
no desire to diverge trunk and branch. Folks have been pushing to fix
leak/Ts regressions and the goal of getting mozstorage was to get it in
front of web authors as fast as possible.

I'll take responsibility for pushing people hard to land stuff in time
for a2. We were moving too fast and didn't do everything as carefully
as we should have - I should have tried to help keep things under control.

It critical that we keep things clean and in-sync for all Mozilla
projects and follow tree closure rules. In that light we are going to
do the following to remedy this:

* Back the mozstorage stuff out of the trunk and 1.8 branch
* Work to get the right configure setup for all projects for a
re-landing of mozstorage
* Continue to fight the remaining Ts regressions. If they can't be
solved (next day or so) we'll look to back out/turn off the offending
feature until it can be solved so we can get the tree re-opened
* the tree reopens we'll confirm everyone is ready and land the
mozstorage changes

Cheers,

Schrep

Mike Shaver wrote:
5/9/06, Mike Shaver <mike.shaver (AT) gmail (DOT) comwrote:
>Mistakes were made here, and I definitely made some of them. But I
>certainly had no malice in my heart towards any other projects when I
>made recommendations for the courses we took (or even the ones that we
>didn't take), and accusations of such things are not likely to make it
>easier to co-operate on making these things better in the future.

I want to elaborate on this further.

I advocated (strongly, which I'm sure is no surprise) that we push to
get the session storage work into MZILLA_1_8_BRANCH to ship in 1.8a2,
once it was pushed back into the Firefox2/Gecko1.8.1 agenda. I wanted
us to get it in front of web developers with time to get their
feedback, help find strange interactions and performance issues, and
cycle back with the WHATWG on spec tuning, and I believed (still do)
that we would get much better results if we had it in a2 than if we
had to wait for b1. I pushed people (Neil and jst) to implement and
review on a tight cycle, and advocated landing on the branch first
when we saw that there was a crash on the trunk (only) and the trunk
was locked down for perf/leaks, so I certainly need to shoulder some
blame for where we are today. I still stand by my goal there, and if
we'd made _one_ little config fix ahead of time I think I would be the
target of much less scorn today :), but with influence has to come
responsibility, and this is what it tastes like when your predictions
don't line up with reality.

I did not do it with the intent of screwing other projects, and I am
genuinely sorry that it had the negative impact there that it did. I
am frustrated with what I percieved as a knee-jerk demand for a
backout for reasons of "purity", when it seemed that a configuration
change would get the other projects back into the game without
sacrificing the feature or reducing the amount of time we have to get
feedback from web developers.

We're going to revisit that decision, in light of last night's churn
and some bugs found since, and I hope that everyone here believes me
when I say that I will try to have better foresight of the effects on
other sub-projects when I push for things that I think are important
to the project. I think I did almost all of the right things, given
the information I had and what I wanted for the project, so don't
expect me to change my stripes all that much, but I'll remember this
thread for a fair while when I'm reviewing and advocating major
changes!

Mike

dev-planning mailing list
dev-planning (AT) lists (DOT) mozilla.org

Just as a point of clarification, and since it was confusing me until Vlad set me straight, the feature is really DMStorage (which is the WHATWG spec'd thing), not mozStorage (which is the Mozilla/sqlite implementation). We should be careful to draw this distinction when talking to web developers and the test community.

cheers,
mike
Message
From: Michael Schroepfer <schrep (AT) mozilla (DOT) com>
Date: Tue, 09 May 2006 12:26:21
To:dev-planning (AT) lists (DOT) mozilla.org
Cc:dev-planning (AT) lists (DOT) mozilla.org
Subject: Re: DM the 1.8 Branch Now Requires mozstorage

Howdy,

Some mistakes were made here - but Shaver and everyone were really
trying hard to do the right thing here. No malice intended, certainly
no desire to diverge trunk and branch. Folks have been pushing to fix
leak/Ts regressions and the goal of getting mozstorage was to get it in
front of web authors as fast as possible.

I'll take responsibility for pushing people hard to land stuff in time
for a2. We were moving too fast and didn't do everything as carefully
as we should have - I should have tried to help keep things under control.

It critical that we keep things clean and in-sync for all Mozilla
projects and follow tree closure rules. In that light we are going to
do the following to remedy this:

* Back the mozstorage stuff out of the trunk and 1.8 branch
* Work to get the right configure setup for all projects for a
re-landing of mozstorage
* Continue to fight the remaining Ts regressions. If they can't be
solved (next day or so) we'll look to back out/turn off the offending
feature until it can be solved so we can get the tree re-opened
* the tree reopens we'll confirm everyone is ready and land the
mozstorage changes

Cheers,

Schrep

Mike Shaver wrote:
5/9/06, Mike Shaver <mike.shaver (AT) gmail (DOT) comwrote:

>Mistakes were made here, and I definitely made some of them. But I
>certainly had no malice in my heart towards any other projects when I
>made recommendations for the courses we took (or even the ones that we
>didn't take), and accusations of such things are not likely to make it
>easier to co-operate on making these things better in the future.


I want to elaborate on this further.

I advocated (strongly, which I'm sure is no surprise) that we push to
get the session storage work into MZILLA_1_8_BRANCH to ship in 1.8a2,
once it was pushed back into the Firefox2/Gecko1.8.1 agenda. I wanted
us to get it in front of web developers with time to get their
feedback, help find strange interactions and performance issues, and
cycle back with the WHATWG on spec tuning, and I believed (still do)
that we would get much better results if we had it in a2 than if we
had to wait for b1. I pushed people (Neil and jst) to implement and
review on a tight cycle, and advocated landing on the branch first
when we saw that there was a crash on the trunk (only) and the trunk
was locked down for perf/leaks, so I certainly need to shoulder some
blame for where we are today. I still stand by my goal there, and if
we'd made _one_ little config fix ahead of time I think I would be the
target of much less scorn today :), but with influence has to come
responsibility, and this is what it tastes like when your predictions
don't line up with reality.

I did not do it with the intent of screwing other projects, and I am
genuinely sorry that it had the negative impact there that it did. I
am frustrated with what I percieved as a knee-jerk demand for a
backout for reasons of "purity", when it seemed that a configuration
change would get the other projects back into the game without
sacrificing the feature or reducing the amount of time we have to get
feedback from web developers.

We're going to revisit that decision, in light of last night's churn
and some bugs found since, and I hope that everyone here believes me
when I say that I will try to have better foresight of the effects on
other sub-projects when I push for things that I think are important
to the project. I think I did almost all of the right things, given
the information I had and what I wanted for the project, so don't
expect me to change my stripes all that much, but I'll remember this
thread for a fair while when I'm reviewing and advocating major
changes!

Mike

dev-planning mailing list
dev-planning (AT) lists (DOT) mozilla.org

dev-planning mailing list
dev-planning (AT) lists (DOT) mozilla.org

5/9/06, Mark Banner <bugzilla (AT) nospam (DOT) standard8.demon.co.ukwrote:
Why go backwards instead of forwards? Camino and Tbird are fine now
(or are expected to be, in the case of Camino), so why not update the
SeaMonkey config and move on?

come on now, I can't speak for any project in particular, but I can
see there are several conflicts with the general mozilla ethos that have
occured with this checkin.

If I'm wrong about these, then I apologise in advance and please do put
me right, however, these are from my observations so far:

a) It wasn't checked in on trunk first as per rules.

Hey everyone, lets do development on branch and end up with another
Aviary. Yes the trunk is closed - live with it, fix it, don't disobey
the rules that are there for everyone (and yes so what, FF alpha 2 will
be delayed another couple of days). I'd love to be checking stuff in
now, but I can't, I've no idea what ff leak problem is, so I just have
to sit and wait.

Nobody is proposing that there be a long-term divergence from the
trunk, so your Aviary strawman isn't especially relevant. There were
significant discussions of everything that went into branch ahead of
trunk (and a _lot_ of things go into branch and trunk together,
courtesy of cross-commit), and many of those discussions resulted in
checkins being held out for sheriff approval on the trunk.

People working on the storage patch (vlad, jst, Neil) were looking at
tbird bustage at 14:36 Pacific, during its very first red cycle, so I
know that at least the Tbird tree were being monitored. (Which is the
other mandatory one, as per the holy tree rules!) That some of the
tinderboxes in question take 90+ minutes to cycle makes for long fix
cycles, and I have a hard time disagreeing with the approach of
getting Firefox green first, and then seeing if Tbird needs other
fixes.

Similarly, the issues with balsa's leak-test cycling.

(Also: bring on the common-XULRunner future!)

We're trying to be very conservative about "a few days later", because
we've all seen products ship a quarter late by slipping a day at a
time. Maybe we (I) were too conservative about that, and we should
slip longer, but the
cycle makes for very slow progress relative to the desired pace of a
release endgame.

And people were working on the leaks, on branch and trunk both, hard
and long. In some cases the same people who are being maligned for
not caring about them, or "cheating".

d) Projects weren't informed (as far as I can tell)

Such a dependency that is being introduced in a core part of the
project, on a branch that is meant to be relatively stable without
notifying all projects is just wrong.

Gecko was already to have a dependency on storage from the original
Places plan, which is why at least I didn't see the dependency-change
issue as we prepared to land this code. Mea maxima culpa.

This says to me that FF follows the rules most of the time, but does
what it wants on special occasions, but everyone else still have to obey
the rules FF makes up.

FF doesn't make rules, it's a piece of software. People make rules,
and judgements, and tradeoffs, and even mistakes. Projecting malice
onto software or ill-defined groups is at best hurtfully cathartic.

_Who_ (what people) "made up" the rules?
#Proposed_Solution
was discussed and refined by many people, and driven to that state by
Brendan. The tree rules ("don't break Fx, Tb; please mind SM, Camino,
Ports, XULRunner, Sunbird, the gap") have evolved to their current
state quite incrementally and not by some "FF" fiat.

But even then, in "special occasions", rules will be broken through
application of human judgement, and should be. Economic decisions in
favour of Firefox are not something that I think to be shameful,
either, and I don't think these costs to other projects were
unbearable, though they were certainly not pleasant, and I think we
should work to minimize them. (But we should not work to minimize
them "at all costs", or any such utopian rigidity. That thinking
dooms us to excess conservativism and stagnation, especially where
different projects and products can move at different speeds.)

This is a community where we should be working
together not against each other.

I agree, and I don't think that demanding a backout instead of making
a config change, while the project's premier app is in the endgame of
a milestone release, is "working together".

Mistakes were made here, and I definitely made some of them. But I
certainly had no malice in my heart towards any other projects when I
made recommendations for the courses we took (or even the ones that we
didn't take), and accusations of such things are not likely to make it
easier to co-operate on making these things better in the future.

To be clear, I don't say "and move on" to mean "stop discussing how we
should configure the core", but "use that fast path to get SM back to
green on the branch so developers of SM-1.8.1 aren't blocked".

Mike

dev-planning mailing list
dev-planning (AT) lists (DOT) mozilla.org

Michael Schroepfer schrieb:
I'll take responsibility for pushing people hard to land stuff in time
for a2. We were moving too fast and didn't do everything as carefully
as we should have - I should have tried to help keep things under control.

Schrep, Shaver - I know you were just trying to get the best possible
result, but it once again has been proven that rushing in major changes
before a planned release leads to problems because people tend to be
less cautious in that rush (this time that led to the unintended
interface change and all those breakages, which all had to be fixed
afterwards - not counting eventual regressions which are usual after big
changes, as we all know).

Benjamin seems to work on the correct fix for the breakage in
so I think once that
has landed, we are safe on the bustage side.

Giving people a heads-up here and/or in .platform that a major platform
change is landing would at least make other project aware that something
could impact them, and that would save us some annoyances.

Robert Kaiser

dev-planning mailing list
dev-planning (AT) lists (DOT) mozilla.org

Jonas Sicking wrote:
We have talked on and off about that we need to have some place where we
announce major (or minor) changes to the platform.
m.d.platform?
-Boris
dev-planning mailing list
dev-planning (AT) lists (DOT) mozilla.org

Robert Kaiser wrote:
Giving people a heads-up here and/or in .platform that a major platform
change is landing would at least make other project aware that something
could impact them, and that would save us some annoyances.

We have talked on and off about that we need to have some place where we
announce major (or minor) changes to the platform.

example I ran into the other day was that we now have the ability to
turn nsIURI objects un-mutable. Another example that I have wanted to
spread the word on is changes to nsIContent and nsINode that have been
and are being made.

/ Jonas

dev-planning mailing list
dev-planning (AT) lists (DOT) mozilla.org

Boris Zbarsky wrote:
Jonas Sicking wrote:

>We have talked on and off about that we need to have some place where
>we announce major (or minor) changes to the platform.

m.d.platform?

I was thinking about that too. Do people think that is good enough?

I could imagine that it might be a bit too high traffic since a fair
amount of planning and Q&A is going on in here.

But at the same time it's a bad idea to have too many information
channels, especially if you have to follow them all to stay updated.

Maybe we should just encourage people to start posting here when they
have new features or capabilities in the works that they think could be
interesting to other people and see how it works out.

/ Jonas

dev-planning mailing list
dev-planning (AT) lists (DOT) mozilla.org

Mike Shaver wrote:
We're going to revisit that decision, in light of last night's churn
and some bugs found since, and I hope that everyone here believes me
when I say that I will try to have better foresight of the effects on
other sub-projects when I push for things that I think are important
to the project. I think I did almost all of the right things, given
the information I had and what I wanted for the project, so don't
expect me to change my stripes all that much, but I'll remember this
thread for a fair while when I'm reviewing and advocating major
changes!

Thanks Mike for your honest responses, I appreciate them.

I think the thing I'd like to see most to come out of this is better
communication between projects for new features and changes of
dependencies. Although they may have been mentioned in wiki at the
design stage, I think I agree with the idea of a post to this group as
well would help projects and others know the changes before they happen.

Mark Banner

dev-planning mailing list
dev-planning (AT) lists (DOT) mozilla.org