DOM On the 1.8 Branch Now Requires mozstorage

classic Classic list List threaded Threaded
23 messages Options
12
Reply | Threaded
Open this post in threaded view
|

DOM On the 1.8 Branch Now Requires mozstorage

Scott MacGregor
In case you didn't notice already,  Bug #335540 landed on the 1.8 branch today making DOM 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 MOZ_STORAGE ifdefs around the dom changes so you can still build without depending on MOZ_STORAGE

2) Set MOZ_STORAGE=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? Or will everyone want it anyway in which case option 2 might be best.

-Scott
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: DOM On the 1.8 Branch Now Requires mozstorage

Gavin Sharp
Scott MacGregor wrote:
> In case you didn't notice already,  Bug #335540 landed on the 1.8
> branch today making DOM depend on mozstorage.


Bug 337208 was filed to deal with this issue.
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: DOM On the 1.8 Branch Now Requires mozstorage

Jonas Sicking
In reply to this post by Scott MacGregor
Scott MacGregor wrote:
> 1) add MOZ_STORAGE ifdefs around the dom changes so you can still build
> without depending on MOZ_STORAGE
>
> 2) Set MOZ_STORAGE=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? Or 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
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: DOM On the 1.8 Branch Now Requires mozstorage

Benjamin Smedberg
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).

--BDS
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: DOM On the 1.8 Branch Now Requires mozstorage

Robert Kaiser
In reply to this post by Scott MacGregor
Scott MacGregor schrieb:
> 1) add MOZ_STORAGE ifdefs around the dom changes so you can still build
> without depending on MOZ_STORAGE
>
> 2) Set MOZ_STORAGE=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.

IMHO, 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
http://tinderbox.mozilla.org/showbuilds.cgi?tree=Mozilla1.8-SeaMonkey
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: DOM On the 1.8 Branch Now Requires mozstorage

Mike Shaver
On 5/9/06, Robert Kaiser <[hidden email]> wrote:
> 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.

> IMHO, 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
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: DOM On the 1.8 Branch Now Requires mozstorage

Robert Kaiser
In reply to this post by Robert Kaiser
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.

>> IMHO, 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 DOM on storage without
making the build system know to always build storage when building DOM
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
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: DOM On the 1.8 Branch Now Requires mozstorage

Mark Banner
In reply to this post by Robert Kaiser
Mike Shaver wrote:
> On 5/9/06, Robert Kaiser <[hidden email]> wrote:

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

Oh 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
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: DOM On the 1.8 Branch Now Requires mozstorage

Kai Engert-3
In reply to this post by Jonas Sicking
Jonas Sicking wrote:

> Scott MacGregor wrote:
>> 1) add MOZ_STORAGE ifdefs around the dom changes so you can still
>> build without depending on MOZ_STORAGE
>>
>> 2) Set MOZ_STORAGE=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? Or will everyone want it anyway in which case
>> option 2 might be best.
It seems MOZ_STORAGE was added to multiple sections in configure.in
Should we simply do the same thing for SeaMonkey and check it in to
MOZILLA_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.in 9 May 2006 07:27:23 -0000 1.1503.2.63
+++ mozilla/configure.in 9 May 2006 16:31:10 -0000
@@ -4218,20 +4218,21 @@
 
 case "$MOZ_BUILD_APP" in
 suite)
   MOZ_APP_NAME=seamonkey
   MOZ_APP_DISPLAYNAME=SeaMonkey
   MOZ_MAIL_NEWS=1
   MOZ_LDAP_XPCOM=1
   MOZ_COMPOSER=1
   MOZ_SUITE=1
   MOZ_PROFILESHARING=
+  MOZ_STORAGE=1
   MOZ_APP_VERSION=$SEAMONKEY_VERSION
   MOZ_EXTENSIONS_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(MOZ_SUITE)
   ;;
 
 browser)
   MOZ_APP_NAME=firefox
   MOZ_APP_DISPLAYNAME=BonEcho
   MOZ_XUL_APP=1
   MOZ_PHOENIX=1

_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: DOM On the 1.8 Branch Now Requires mozstorage

Samuel Sidler-3
In reply to this post by Robert Kaiser
Mike Shaver wrote:

> On 5/9/06, Robert Kaiser <[hidden email]> wrote:
> > 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.
>
> > IMHO, 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. Otherwise, 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 OS 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
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: DOM On the 1.8 Branch Now Requires mozstorage

Robert Kaiser
In reply to this post by Jonas Sicking
Kai Engert schrieb:
> It seems MOZ_STORAGE was added to multiple sections in configure.in
> Should we simply do the same thing for SeaMonkey and check it in to
> MOZILLA_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).

https://bugzilla.mozilla.org/show_bug.cgi?id=337208 has the real fix,
and I hope bsmedberg will be able to check this in soon.

Robert Kaiser
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: DOM On the 1.8 Branch Now Requires mozstorage

Mike Shaver
In reply to this post by Mark Banner
On 5/9/06, Mark Banner <[hidden email]> wrote:

> > 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?
>
> Oh 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 backout-tweak-checkin-wait-backout-tweak-checkin
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?
http://wiki.mozilla.org/Global:1.9_Trunk_1.8_Branch_Plan#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
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: DOM On the 1.8 Branch Now Requires mozstorage

Mike Shaver
In reply to this post by Samuel Sidler-3
On 9 May 2006 10:40:49 -0700, [hidden email]
<[hidden email]> wrote:
> 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 OS 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
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: DOM On the 1.8 Branch Now Requires mozstorage

Mike Shaver
In reply to this post by Mike Shaver
On 5/9/06, Mike Shaver <[hidden email]> wrote:
> 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 MOZILLA_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
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: DOM On the 1.8 Branch Now Requires mozstorage

schrep-2
In reply to this post by Mike Shaver
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
        * Once the tree reopens we'll confirm everyone is ready and land the
mozstorage changes

Cheers,

Schrep

       


Mike Shaver wrote:

> On 5/9/06, Mike Shaver <[hidden email]> wrote:
>> 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 MOZILLA_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
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: DOM On the 1.8 Branch Now Requires mozstorage

Mike Beltzner
Just as a point of clarification, and since it was confusing me until Vlad set me straight, the feature is really DOMStorage (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  
-----Original Message-----
From: Michael Schroepfer <[hidden email]>
Date: Tue, 09 May 2006 12:26:21
To:[hidden email]
Cc:[hidden email]
Subject: Re: DOM On 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
        * Once the tree reopens we'll confirm everyone is ready and land the
mozstorage changes

Cheers,

Schrep

       


Mike Shaver wrote:

> On 5/9/06, Mike Shaver <[hidden email]> wrote:
>> 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 MOZILLA_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
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning

_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: DOM On the 1.8 Branch Now Requires mozstorage

Robert Kaiser
In reply to this post by schrep-2
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
https://bugzilla.mozilla.org/show_bug.cgi?id=337208 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
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: DOM On the 1.8 Branch Now Requires mozstorage

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

One 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
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: DOM On the 1.8 Branch Now Requires mozstorage

Boris Zbarsky
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
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: DOM On the 1.8 Branch Now Requires mozstorage

Andrew Schultz-2
In reply to this post by Mark Banner
Mike Shaver wrote:
> 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".

It would seem reasonable to me that as a bustage fix a patch like one in
bug 337208 could have been committed last night.  I can't think of any
reason it wasn't.  It certainly would have been more reasonable than
saying "hey every app in the tree, change your config!" considering

a) You assumed the build system was configured like that already -- DOM
was made dependent on storage on purpose.
b) You break it, you fix it.
c) It would not have involved changing every apps config only to back
out those changes once the real fix was in.

One of the advantages to being in the tree is supposed to be that when
someone breaks you, they fix it.

--
Andrew Schultz
[hidden email]
http://www.sens.buffalo.edu/~ajs42/
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
12