(Cross-posting to dev-planning. Follow-ups to dev-platform.)

As we get closer to release, I'm seeing more and more core bugs
minused for "blocking1.9". Often time, this is good as we've plussed
many things that aren't nearly major enough to fix. However, many
times, these are clear regressions that simply don't affect Firefox.
As a Camino contributor in my off time, this brings up a pretty
critical question to me, personally: Are we considering Gecko 1.9 a
Firefox-only release?

Previous conversations between Damon and other Camino contributors (on
IRC a couple/few months ago) implied that we're indeed considering
Gecko 1.9 a proper Gecko release and giving other mozilla.org apps [1]
that rely on our codebase the same amount of core support they've
received in the past. I.e., not shipping with regressions that were
caused from changes made for Firefox and/or providing a clear way for
them to move forward to a new, supported way of implementing their
same features without hacking around bad changes.

However, I've seen drivers minus bugs and leave comments that counter
that idea. For example: "We certainly aren't going to block the
Firefox release on an issue that doesn't affect Firefox." [2] Fixing
such bugs later, on the actual timeline of another product's release
isn't always possible (changing major core components to fix other
products doesn't fly in point releases like 1.9.0.x given that those
changes usually can affect Firefox) and/or ends up creating huge hacks
in the codebase.

In the past, we've blocked on bugs in Gecko releases that didn't
affect Firefox but were clearly regressions from Firefox-focused
checkins. If this has changed, I think it needs to be announced
somewhere, very publicly, with a clear statement as to why we're
making that change in policy (and if it wasn't a policy, feel free to
substitute "behavior" there).

I understand our need to release Firefox RSN, but not fixing core bugs
we've caused simply because they don't affect Firefox doesn't seem
like a good thing for our developer community and only perpetuates
ideas that Mozilla doesn't care about other projects.

(At no point do I want to demean the work some developers have done to
care about regressions from their checkins that only happen in other
products. There are several developers who not only care, but go out
of their way to fix those regressions. I also am well aware of non-
Firefox bugs getting fixed in the core and approved for landing. I'm
specifically talking about regressions that have been minussed where
we've broken other products and caused regressions in our platform.)

If I'm way off base, please let me know, but this is the general
sentiment I've been getting from the bugs I watch.

-Sam

[1] http://www.mozilla.org/projects/#applications
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=382138#c30

I guess this is part of the reason KaiRo has been thinking of proposing
a Gecko 1.9.1 branch for landing bugfixes needed by SeaMonkey,
Thunderbird, Sunbird and other projects that don't have a release cycle
synchronized to Firefox's.

Phil

--
Philip Chee <phi...@aleytys.pc.my>, <philip.c...@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.
[ ]Quick! Close your mind!! Something might get in.
* TagZilla 0.066.6

Note that this would double the amount of work needed for security
releases, since at that point Firefox and the other projects would be on
different Gecko release branches.

Given the difficulty we've had with getting things fixed at all on the
1.8 branch, this is something to avoid if possible.

There's also the problem that this undercuts the "Gecko is Gecko" claim
we make.

For what it's worth, it looks to me like bug 382138 was misdiagnosed,
and then mistriaged based on this misdiagnosis.  If it doesn't make 1.9,
you probably will need a 1.9.1 for the non-Firefox apps, if it gets
fixed at all, because it's not the sort of change we should be making on
a stable branch.

-Boris

On Mar 1, 7:40 pm, Samuel Sidler <samuel.sid...@gmail.com> wrote:

Serious question: is there a Gecko 1.9 release, or are there multiple
product releases using most of the same Gecko code?

Trying to fix bugs in/for every Gecko product at once seems foolish to
me.

- Rob

All of the same Gecko code.  We're all pulling CVS.  There are no app
ifdefs in Gecko.  Gecko is Gecko.

Are you suggesting each app fork Gecko?  In the case at hand, I suspect
it wouldn't really matter unless and until the regression actually has a
fix, which (based on comments in the bug) won't be happening anytime soon.

--
Andrew Schultz
ajsch...@verizon.net
http://www.sens.buffalo.edu/~ajs42/

On Mar 2, 1:10 am, Andrew Schultz <ajsch...@verizon.net> wrote:

This response skirts my original question. Is there a Gecko 1.9
release? I am not aware of one being planned, so I am not sure which
release Sam is referring to in his message.

- Rob

Your question was really, "what did Sam mean by 'release'".  I don't
know exactly what he meant, but I got a pretty good idea from the
context ("the Gecko that's included with Firefox 3.0" would probably
suffice) and I really doubt a solid definition is needed to address the
issues he's bringing up.

--
Andrew Schultz
ajsch...@verizon.net
http://www.sens.buffalo.edu/~ajs42/

On Mar 2, 2:34 am, Andrew Schultz <ajsch...@verizon.net> wrote:

So the claim is that all Gecko bugs for Seamonkey and Thunderbird and
Camino (but not Komodo, Flock, and Songbird) must be fixed before
shipping Firefox 3? That is really stupid.

Another theory about one bug in question is that it's actually /really
bad/. That has nothing to do with project coordination, so I'm not
sure why the two issues are being conflated. If the patch shouldn't be
in the tree, take it up with the module owner and superreviewer, don't
splash project politics all over bugzilla.

Either way, I think this thread is making a big issue out of a
pedestrian problem, and I can't bring myself to care about it
anymore.

- Rob

On Mar 2, 12:01 am, sayrer <say...@gmail.com> wrote:

There are lots of platforms on top of platforms in the world; some
apps even act as platforms. Obviously, not all bugs are fixed at once.
On the other hand, Gecko has integrity as a platform beyond Firefox.
It's in the User-Agent. It has to have sane semantics and be a black
box as much as we can stand to engineer it that way, in memory-unsafe
programming languages and with time-to-market in mind, especially
Firefox market.

Making this a black/white, your way of the highway thing is false.
Obviously the bug in question arose because of Thunderbird and other
apps behaving differently. That's something to talk about, without
making false dilemmas between impossible coordination vs. Firefox uber
alles. For one thing, it's not clear to everyone what the right answer
is, so interacting with other apps' owners and peers makes sense. If
this doesn't fit in the schedule, so be it, but we're not done yet.

It should not be cut on the Procrustean bed of your (or my)
impatience. There are many hands at work in the community. The
particulars of this bug bear on XUL and its platform quality, so XUL
owners (you know who you are) need to be involved.

They're not. They are both valid issues to bring up for a 1.9
milestone.

This dodges the crucial point that module owner and reviewers are
obligated to look beyond one app when considering platform quality.

Politics is about competing ideas of the common good. Complaining
about it splashing on the bug after you've made your splash as
blocking1.9 rejecter is not playing fair. We have to argue about what
XUL menus should do in the disabled state, should they be cross-
platform. Etc. Meta-attitude against the other guy's "politics" really
doesn't help.

Maybe it's like the WK* API thing. :-/

/be

On 2008-03-02, sayrer <say...@gmail.com> wrote:
[snip]

Why do you want to exclude the others?  Would actually be good if core
bugs needed by Flock, Songbird and Komodo could be fixed too. ;)

Seems obvious that the "claim" that Gecko release is the same as the
Firefox release is a statement of fact, given that Firefox won't allow any
changes in Gecko after Firefox is released.  That is the way it's been in
the past.  The alternative, I guess, is forking Gecko and maintaining
parallel versions until Mozilla 2 - that also sounds stupid.

The particular bug in question seems pretty pedestrian.  The crappy
attitude of Moz Corp developers isn't a pedestrian issue.  If you don't
care about other Mozilla apps, then why on earth are you in charge of
managing a Mozilla release?  Mozilla spends huge amounts of time trying to
say that it's not just about Firefox and how Mozilla benefits the
community and blah blah blah, and then people come along and go "Firefox 3
is supreme. I don't care about anyone else. Screw open source and
community - look at all our money and market share. Muahahaha!" (ok, so
maybe you didn't exactly say that, but that's how I read it)

However big the initial issue was or wasn't, you saying that you don't
care about it is an issue in itself. Please bring yourself to care about
it or go work on some other project... I think Flock are still hiring.

--
Michael

Boris Zbarsky schrieb:

Right, I'm fully without you on that I don't like deviation of core
between the applications.

The problem is larger than one bug, actually:
https://bugzilla.mozilla.org/show_bug.cgi?id=398751 is a list of things
we know for now that are core bugs that would be marked SeaMonkey
blockers if they were in the SeaMonkey realm. And the one you mention
isn't even among those.

So, as much as I dislike having two branches and know the problems with
this, I currently fear we need to go that way, making 1.9.1 a 1.9 plus
core fixes that are too risky to take for FF at the current stage, and
maybe once it's been tested enough, do a FF 3.1 based on it, with a
direct update without overlap to 3.0.x to merge back to a single branch.
This might be a way that works for all, but we need to keep tight
control over what goes into core in 1.9.1 if we want to do it that way.

Robert Kaiser

sayrer schrieb:

I think there's a XULRunner release supposed to happen some time, that
is supposed to have the same core featureset and functionality as FF3
and to be able to be used by any XUL application - including products
from TomTom and others.

And then, we are supposed to have the same core code for all our apps
like FF3, SeaMonkey 2, Thunderbird 3, Sunbird, etc. so that security
updates of that code/branch apply to all Gecko apps and we don't
knowingly leave Mozilla applications vulnerable and damage the Mozilla
image of being very secure.

Robert Kaiser

(Not reading the thread, so this may have already been said.)

 From where we are now, a solution would be:
first, release Gecko 1.9 + Firefox 3;
then, do a Gecko 1.9.1 + Firefox 3.1 + other apps.

I don't know how doable this would be, but it's how I feel.

We now have much richer test suite infrastructure than we've ever had
before; do you think it's reasonable to ask that dependent projects,
in cases where they aren't able or willing to fix the core bugs that
affect their apps themselves, contribute test cases that protect the
behaviour they need, which may not be exercised by Firefox as primary
test vehicle?  In post-facto cases we'd probably need to commit them
as TODOs with a bug to track their enabling, though in such post-facto
cases where I have module authority I'd be more tempted to back out
the offending patch and commit the test cases in support of whatever
the subsequent fix is.  It does mean that app owners need to take an
active role in helping make Gecko a better platform for their charges,
and can't rely simply on negotiating for blocking status to get
someone else to carry the costs of fixes, but I don't think the burden
is . And in some cases, as with Cocoa widgets, we would start to get
some badly-needed test coverage -- something I would imagine the
Camino folks would really shine at, given their historical expertise
in blending Gecko with Cocoa.

Is that something that non-Firefox app owners are up for?  Are there
already test cases for the various SM2-blocking bugs to let people
working on the core know when they've fixed them?  Do we have test
cases that will let Gecko folk know when they've fixed whatever is
ailing Camino or Sunbird or Komodo?

I agree with Rob in this narrow way at least: the bug in question is
just a crappy bug, which shouldn't have been "fixed" the way it was,
and I think it's a (happily rare) failing of reviewership and
stewardship that we're in some danger of shipping it in that state.
As someone who's often a reviewer and steward, I feel bad that we got
here as well, and I'll do what I can to make things right.  Hard cases
make strange bedfellows, or something, but I don't think that this
outlier ("what we did works for Firefox[*], module owner doesn't want
to make a better change, we're not yet ready to make it an
ownership-confidence issue") is or should be taken as a trend for
Firefox-driver decisions.

[*] Except where it doesn't, by breaking reasonable cross-platform
assumptions for extension authors.  This thing has enough strikes to
end a few innings by itself, I think.

We shouldn't block Firefox for things that don't affect Firefox, as a
tautology, but Gecko's effect on Firefox is deeper than as a shared
library to which it links, and if we're saying that we can't take
incompatible fixes on the maintenance branch -- sound policy, in
general! -- then we need to look a few moves ahead when locking out
fixes until the next feature release cycle.  Firefox benefits from
Gecko's role as a shared technology, and we should try to avoid taking
unnecessary regressions in sister products.  I don't know how many of
the SM2 bugs are "it would be good if this capability were more
general" rather than regressions in the 1.8->1.9 cycle, but the latter
should be triaged very differently, by my lights.

I'll say again, though: all apps, Firefox included, should be helping
Gecko help them by ladling on the test cases, and we should be
requiring tests for anything of significance that hits our trunk.
We're paying the cost every day for not having tests on key areas of
code, and the price only goes up as we get farther into the release.

I'm out of commas and synthetic em dashes now so I guess I'm done!

Mike

On Mar 2, 4:42 am, "bren...@mozilla.org" <bren...@mozilla.org> wrote:

On Mar 2, 8:23 am, Michael Lefevre <news+07.nos...@michaellefevre.com>
wrote:

Good question. I'm interested in managing a Firefox release, but not a
Mozilla release.

So I think I'll make myself not a 1.9-driver anymore.

...

- Rob

Mike Shaver schrieb:

Why should this be of any help when those who contribute patches have a
hard enough time getting them into core that forking the code tends to
sound better than improving the common platform?

I'm saying this as someone who is coordinating a in-CVS product that
tries very hard not to fork stuff, but from our experiences I easily see
why products maintained outside CVS tend to not fight for inclusion of
their improvements into core code but just keep them in their forked
repository.

Robert Kaiser

I'm not sure what that has to do with shaver's proposal.  I'll be honest: if
there were better test coverage of docshell and session history, it would be a
lot easier to accept patches for them (a point that I know is being a problem
right now).  More tests directly translates into a much easier review and more
module owner confidence.  Tests attached to a bug with no patch directly
translates into it being easier to fix the bug for someone else.

Just to put this in perspective, for the typical docshell bug that I fix and
write regression tests for writing the tests takes somewhere between 75% and 95%
of the total time I spend.

-Boris

That seems perfectly reasonable to me, for what it's worth.  I'd be very much in
favor of it, as a Core developer.  I can't speak for any of the non-Firefox
project owners, of course.

-Boris

I think this is the wrong question to ask, because "Gecko 1.9" is not a static
thing.  The right question is: "is there a single Gecko branch that is used for
all the product releases of the various products, or are here multiple Gecko
branches, one per product, with changes being ported between them on a piecemeal
basis?"

Historically, we have aimed to have a single release branch of the core code.
Part of the reasoning for this was the "Gecko is Gecko" idea (which has its own
reasons, both philosophical and practical).  But another important part of the
reasoning is that maintaining multiple release branches is a waste of time.
It's particularly a waste of time if whoever is doing the porting could better
spend the time contributing to Core development.  Put another way, Neil
Rashbrool and I, say, would much rather be fixing branch security bugs than
porting branch security bug fixes from the Firefox branch to the Seamonkey
branch.  We'd much rather fix the bug once rather than fix it on the Seamonkey
branch and then have to port to the Firefox branch (assuming we have to, of
course.  Then again, would we even need to backport to the Firefox branch?  Or
just let someone who cares about Firefox handle it, somehow?  The whole thing is
a recipe for inefficiency and bad feelings, in my opinion, and would hurt the
Firefox release branch, as well as the others.  From the point of view of a
Firefox driver this hurt should be weighed against the pain of fixing the bugs
that could cause this situation before ship.  I can even understand that after
said weighing a decision would be made to ship without fixing such a bug, but
what I find unacceptable is refusing to actually do said weighing.

Note that no one is saying that all Gecko bugs that affect non-Firefox apps need
to be fixed by the time Firefox 3 ships.  In particular, if a bug can be fixed
in a point release, it makes all the sense in the world to do so, since the
other apps will ship later than Firefox.  But for bugs that wouldn't be able to
go into a point release, I think we should have very very strong reasons if
we're not going to fix them.

If we do plan to do a Firefox 3.1 off Gecko 1.9.1, which will be allowed to
break compat to some extent, then we can push off some bugs to this.  Last I
heard, brendan was strongly opposed to this.

-Boris

On Mar 2, 5:23 am, Michael Lefevre <news+07.nos...@michaellefevre.com>
wrote:

Hey, knock that off. Collective blame is never justified for so
individual a set of actors and so fluid a situation. Mano, who
objected strenuously in the bug, is a "Moz Corp developer". So am I.

Why don't you stick to the substance of the argument, instead of
generalizing from Rob -- or attack Rob if you must, but cut the anti-
corporate groupthink.

/be

On Mar 2, 6:48 am, "Mike Shaver" <mike.sha...@gmail.com> wrote:

Mano thinks that pedestrian bug will break a bunch of add-ons. This is
not just an SM2 or Flock issue, it's a Firefox 3 question. It needs to
be answered before the bug can be blocking1.9-, with comity, clean
hands, and composure.

Drivers make the wrong call on blocking negations sometimes, but
instead of reconsidering the technical facts, this bug blew up into
something pretty ugly. Obviously there is a political (as in, what's
good for the _polis_, the common engine that's shared among apps, and
more important, the project that's made up of people sharing the code)
problem. Let's have it out, here, but in the mean time that bug needs
technical work and a blocking1.9 reconsideration.

/be

On Mar 2, 9:56 am, Boris Zbarsky <bzbar...@mit.edu> wrote:

That's right, and that is exactly what we've done in the past.

We don't break web or platform API (not just nsIFoo but also XUL and
XBL) compatibility if we can help it on a minor (1.9.1) release. That
includes unfrozen APIs, wherefore the nsIBar_MOZILLA_1_8_BRANCH
interfaces. We burned plugin vendors badly in the past by doing
otherwise, so this is (again) not mindless "religion" or philosophy.

I'm in favor for 3.1 -- your pronoun "this" is confusing me. Do you
mean compatibility changes in a minor release? Those are still trouble
as far as I am concerned, based on long experience.

/be

I think these are important points. However, there's several things I
think that are also worth consideration:

a) Where non-Firefox apps don't have developers experience in certain
areas it is potentially harder for them to get bugs fixed by core
developers because the focus will have shifted to the next release.
b) If xulrunner was being shipped as a true platform, then these bugs
should be fixed anyway, as any potential xulrunner app might run across
them. This is probably something that needs to be thought more about for
Moz2, but I think worth bringing up here.
c) Is it always clear if a bug will need changes that will break compat
to fix them?

Standard8

"this" was referring to a Gecko 1.9.1 with feature additions to the core (e.g.
adding new CSS selectors).

-Boris

Not always, no.  But most of the time, I think it is.

-Boris