What does God need with a starship?
There is currently an interesting discussion1 going on right now in mozilla.dev.platform which asks a seemingly simple—but if the number of responses are any indication, actually difficult—question: “Is ‘Gecko’ 1.9 only Firefox?”
It’s definitely required reading if you hack on anything built on the Mozilla platform that isn’t Firefox.
To be honest, I find it a little surprising that others find it surprising that the answer is anything but “Yes.”
There are a lot of principles discussed in the newsgroup posting, but in practice, ever since I was involved with Firefox releases, it is Firefox—not Thunderbird, not SeaMonkey, not Calendar, and not (arguably most appropriately) XULRunner— that has driven Gecko releases. The best determining factor of Gecko releases, i.e. when the Gecko platform version is bumped, was originally standardized as part of the Firefox release process, and is now codified by the release automation.2
I fully admit that I am interpreting the question from the (possibly too narrow) standpoint that I’m mostly familiar with: the Firefox release process. It is entirely possible that the triage process is different.3 But it has the benefit of being entirely devoid of a process4 with lots of human input and interaction which necessarily implies non-deterministic outcomes.
But the answer to “When is Gecko released?” is pretty binary. Since there are no separate XULRunner releases, just look at when the Gecko versions are bumped: for quite some time, it’s been at Firefox release time.
Immaterial of how we want to do things or would like to do them in a utopian world, that’s what the code in CVS does today, right now. It would seem the requirements and triage process mimic the code, namely in that Firefox drives the process.
Almost ten months ago now, it was stated pretty clearly that “XULRunner improvements should benefit a range of other applications but the focus of Mozilla employees will be on browsing.” There was a lot of discussion about what the material impact of the policy statement would be, including my own two cents on the matter.
I may be misunderstanding the posit of the original question posed in the newsgroup, but it would seem that this is an concrete, identifiable example of a question directly arises from a policy of having a singular product and its release schedule drive the development of the platform.
If this isn’t the outcome developers on Mozilla’s non-Firefox projects expected, then it may be time to ask “where was the disconnect between what was said and what was heard?”
For me, the discussion raises some meta-questions that, to my mind, are not only more important than “Is ‘Gecko’ 1.9 only Firefox?” but whose answers also turn out to be more relevant than just what happens in the next N months, as lots of people work really hard to get an awesome Firefox 3.0 out the door:
- Is there going to be a separate XULRunner 1.9.0 release before or during5 the Firefox 3.0 release time frame? If so, how are triage decisions for that release (being) made? Does the process include stakeholders for projects that aren’t-Firefox?
- (I admit that this may be a totally stupid question on my part, but it’s totally unclear to me:) who is the final determiner of the answer to the above question? There’s a lot of really good discussion going on in the newsgroups, but who makes the final call?
Everyone tells me drivers@ and staff@ are “gone,” and have been for quite some time. Does this mean the Firefox 3 release drivers6 will decide what a “Gecko 1.9″ is? The Steering Committee? A vote of everyone who’s posted more than five times in mozilla.dev.planning? - If that answer is the Firefox 3 release drivers or the Steering Committee, as an open source project, is it relevant to ask if any of the lessons learned in previous days—when the Mozilla Project was largely dependent on a single company, i.e. AOL/Netscape, for engineering work—are applicable?7
Distinct from any discussion of the questions above, I stand ready, as I did ten months ago, to help in any way that I can. Like most people, I use and adore Firefox and agree with the argument that its Mozilla Corporation’s best lever to move the (Open) Web forward.
But I also use and love Thunderbird. I have used9, and relied upon Calendar. And I believe that the XULRunner platform is the best lever the Mozilla Project has to future-proof against whatever develops on the Internet10, as well as provide a compelling answer to proprietary rich Internet application platforms from you-know-who.
Probably the most useful answer is the one to the question: tell me, an engineer with admittedly limited experience with the Mozilla build system, Tinderbox, and the Mozilla release process, how I can help the answer to the original question be a demonstrable, unequivocal “No.”
_______________________
1 Which was brought to my attention by a Rumbling Thunder post
2 rhelmer implemented the first version; I added the respin logic
3 Although, blocking1.9-flag triage was what prompted the question originally, so who knows
4 Which Brendan aptly describes as “fluid”
5 “after Firefox” is a possibility to, but arguably of limited utility
6 Is this a complete/up-to-date list? A couple of blocking1.9 flags have been set by people absent from the list.
7 The question is posed merely by the fact that those two groups are made up of entirely8 Mozilla Corporation employees. I’m not implying any judgment regarding people who work on those groups; I’m merely pattern matching their relational structure to the Project from previous eras.
8 or nearly entirely; the FFx3 drivers list has one non-MoCo-er on it, that I can find anyway
9 and with the number of meetings I’m now responsible for, need to set up again
10 Who knows what we’ll all be using in ten years. Gopher could make a comeback!
Yeah, sorry — your interpretation from the tail of the dog (release process) looking head-ward is too narrow
. Narrow-tailed dog, hmm.
From the head of the dog back, the platform gets lots of attention from many consumers, some of whom can even patch it. But bugs and tests help too.
The rational self-interest of even Firefox-focused hackers, if not every last person involved, motivates this. We can’t be sure what add-on might depend on a bug-fix. We don’t necessarily understand all bugs fully, even if some seem like dodged bullets to Firefox testers at first.
And we don’t know what next month might bring in the way of new use-cases for add-ons and web sites, new test coverage that makes a bug that was minused into a retrospective showstopper.
So we have always treated, and we will continue to treat, platform bugs seriously even if they don’t bite Firefox. But if their fix truly is not needed according to a careful technical analysis, then it can await the next dot release, when other apps are usually more ready anyway.
Lining up these dependencies is non-trivial, but it can’t be improved by forking or fighting. So, for example, we really need more careful analysis of the Cocoa-widget bug that started this latest debate.
/be
@Brendan
From my reading of your comment and of the thread, I agree with you and others that Firefox is served by paying attention to core bugs that may not even obvious-affect Firefox, and that we would do well to avoid the tragedy of the commons.
My point about Firefox driving Gecko releases was that there was some question in the thread of what constitutes a “Gecko release,” and as I noted, immaterial of drivers’ decisions, which may not be consistently applied, and what we’d like to do in principle, there is a very concrete, binary answer to that question: today, in code, the only factor determining a Gecko release is Firefox.
There are no provisions for separate XULRunner releases, and releases, when they are done, are not conducted separately (more on this in a sec). There is no separate triage/release process where [stakeholders who are concerned about] XR bugs are considered.
The issue is futher muddied when it’s unclear who, if anyon, is responsible for making Gecko-focused blocking/release decisions, especially when there are engineers making decisions who are “not interested in a Mozilla release.”
So, I think many people are just asking for clarity between statements of intent and behavior, that’s all. Surely you’d agree that it’s reasonable to be somewhat confused?
Having said that…
Hopefully there is bandwidth available and if there isn’t bandwidth to release these packages within a timely manner after Firefox ships—a problem I’m intimately familiar with—a way will be found to allow the community to fill the void and produce those releases on a timely schedule.
In the end, I think the confusion and concern stems from the fact that a lot of people care about the platform and about XULRunner; we want to help “set the platform up for success” any way we can.
preed: I’m glad you found bug 415180 — that is going to be fixed well, I’m pretty sure.
Please don’t pluralize carelessly. Sayrer may have made a statement I won’t support, but this isn’t the first time we’ve had a dialectic crisis over, e.g., “product” vs. “platform” or “FE” vs. “BE” issues. Ben Goodger in the past, like Rob now, was crucial to moving the needle in various ways that no one else could have, yet also harsh on parts of the community and code that he viewed as impediments.
We can afford to include divergent views of what matters, but in the end, you are right that we cannot be “only Firefox”.
To make the platform other than that means more than last-minute triage-time special-pleading for bugs that don’t matter to Firefox (let’s stipulate that this Cocoa bug is not such a bug).
Triage-rescue dramas are a tragedy of the commons type of scenario we should strive to avoid with more work at the front side of the release process.
I’ll have more to say elsewhere on the whole “drivers” question (who, how, what the rules are). Nothing earth-shaking, and it won’t prevent disagreement about triaged blockers.
/be
+1 for your post title.
@Preed
>I see mfinkle has asked over
> in bug 415180 about bandwidth
> on the Build Team to create
> 3.0b4 XR builds.
I don’t think that this alone solves the problem of patches that regress products besides Firefox landing in the core Gecko code. It does not decouple the Gecko releases from Firefox either, but at least we’ll be shipping XulRunner and the Gecko SDK along with Firefox releases as a matter of course.
Also, this will not happen for b4 (see comments #1 and #2), but should happen in time for the first RC (that was the upper limit discussed in the meeting notes in comment #1). The goal is to have it just be part of the standard release automation from now on.
@Brendan:
that is going to be fixed well, I’m pretty sure.
I hope so. That would go a long way to address the concern, and would help illustrate that “Gecko 1.9″ != “Firefox.”
There seems to be some confusion on this point. As I noted in mfinkle’s blog, the worst of the possible scenarios is radio silence regarding the question about whether or not the bandwidth exists to make these deliverables part of the release.
If the answer is “yes,” then great. If the answer is “no,” then what’s the plan to leverage the community to help out?
Rhelmer notes in a comment that the answer is no, so again: who’s making the final call? Rhelmer? Joduinn? Fx3 drivers? Someone else?
Discussing this in my blog is fun, sure, but it’d be good to get the answer into the proper channels.
Please don’t pluralize carelessly.
This is extremely good advice, especially in such a heated discussion. A reminder is always useful.
Having said that, I didn’t pluralize entirely carelessly; sayrer may have spoken out of turn, but I know that his viewpoint is not isolated, and I would not have pluralized had I lacked this knowledge.
I also know that there are a lot of engineers who do a lot of work to benefit the Community, and who do consider “Mozilla” to be more than “Firefox,” and take that into account when making decisions.
I look forward to some clarification on the drivers/staff issue. I fully admit that I may be the only one in the dark here.
@rhelmer:
I agree that XR builds do not, alone, solve that problem. But in some sense, it’s hard to get an idea of the scope of the problem when there aren’t builds (and Tinderboxen) for developers to look at. I’m getting the impression this is SeamonkeyPorts all over again.
Really, it’s a values judgment: is the Mozilla Project willing to say “Your patch doesn’t affect Firefox, but it does affect other projects; it won’t be checked in until that issue is addressed?” That’s the fundamental question.
Also, this will not happen for b4
You or joduinn should make that extremely clear in bug 415180.
Comment #1 states “Having these builds sometime around b4 or even rc1 was ok,” and we’re at b4. Answering the question posed in comment #2 here doesn’t seem particularly official, even if I could use the extra traffic from people trying to find the answer.
I want to be extremely clear on this point: I, of all people, am very sympathetic to constrained Mozilla Build team bandwidth. That’s not the concern.
The concern is the lack of a clear “yes/no” answer in the bug. It sets the project/initiative up for failure, because there is no definitive answer, and so no one works on a plan to mitigate the effect of a(n understandable) “no bandwidth” condition.
Bugs get dropped on the floor all the time—yours truly is one of the worst offenders—but I don’t think it’s too much to ask to have a documented, definitive answer.
Not sure what the confusion is, it says that the goal is to get it in by the first RC.
Would’ve been great to get it in before b4, but nobody got to it (mobile and moz2, which are set up, were in the queue first, as were a bunch of fx beta4 bugs).
Agreed that sometimes priorities change, but I don’t think there’s any intention of dropping it on the floor.
I don’t really see the point the talking about it; either it’ll happen on time (I think so) or it won’t. Not sure what kind of “mitigation plan” you had in mind; seems like you’re thinking of something specific, why not just come out and say it?
Mangled my last paragraph nicely :/ Meant to say “I don’t see the point to talking about it”, as opposed to actually doing something about it.
In that vein, I took the bug and am working on it. Re-reading my comment, I don’t think I was very clear. I meant that this is not necessarily top priority, but it’s something we should be doing.
We should strive to do things in the timeframe we set out, but sometimes things change and it takes longer than expected; I’m not sure what kind of mitigation would be necessary, given that we don’t do any kind of regular xulrunner releases right now.
Regarding is “Is ‘Gecko’ 1.9 only Firefox?” and bug 415180, as a mere user I wish the question could be rephrased as
”Can Firefox3 run other XULRunner apps?”
, taking advantage of the `firefox.exe -app pathtomyXulAppApplication.ini` command-line switch.
I love the idea of downloading small rich internet apps that “run off” Firefox. I’m not so crazy about another multi-MB heavyweight executable install that repackages much of the underlying code.
I understand why developers are afraid of being tied to diverging interests, but IMO an ecosystem of lightweight XUL packages that run off Firefox 3 is compelling and exciting. I hope it happens. (Maybe it’ll happen first in Linux distros that can build and repackage FF and other Gecko apps.) Anyway, regards and thanks!
preed: what was the question? If it’s “whether or not the bandwidth exists to make [XULRunner 1.9] part of the release” then you’ve heard a consistent answer several times here.
If you meant something else by “these deliverables” please specify.
Again this does not mean any particular bug gets fixed. It just means we deliver matched XULRunner 1.9 and Firefox 3 based on its private XULRunner.
As for not pluralizing carelessly, name these others or leave them out. Lots of people have various opinions — so what?
You’re being too vague here, and not only on this point.
/be
@skierpage:
Firefox 3 can be the runtime for any XUL-based application, just like XULRunner. “firefox -app application.ini” is available today. In fact, that is how Prism is launched when using the Prism extension for Firefox.
@Brendan:
There were multiple facets to my question:
There were claims that this would happen, but in comment 2, mfinkle asked a question of whether or not there would be bandwidth for this, and did not get a concrete answer to what should have been a five minute (if that) question to ask and get answered.
The answer was not clear until rhelmer took the bug and started moving on it. I would assume that means “Yes.” (I say “assume” because my last few months, I was administratively hassled on a few occasions for working on pet (community) projects in my free time, so I don’t make assume anymore that someone taking a bug and working on it equates to “this will get finished.” I ask now.)
This is still an open question to me; there were some number of wheels squeaking here, so was the grease that was applied for this release, or for all future releases?
This may seem like I’m getting caught up in semantics, but the one bug tracking the issue did not have a clear answer from anyone on the build team, and it’s unclear to me whether an answer from, say, rhelmer or cf or bhearsum, would have been considered “official.”
What I’m wanting to avoid is a pattern where straightforward questions get asked, and instead of providing clear answers, the question gets ignored.
Presumably, this is done, so there is no record of an answer in the bug, and it can later be claimed “Well, we didn’t commit to that anywhere; see the bug?”
If the answer to the bandwidth question is “No, the build team has no time to do this,” then interested parties in the Community could step up and figure out how to help out (and if no one does, then I guess none of us thought it was important enough to do anything more than whine about), thus avoiding (I used the word “mitigating” earlier, which might have been a bad choice) the failed outcome of “no XR packages for this major release.”
I would like to think the Mozilla Project has not turned into some big corporate behemoth like, oh, say Oracle, where you have to play these sorts of evasive games because we’re all afraid of giving an unpopular/unexpected answer to tough questions.
This behavior should be frowned upon severely, because it effectively amounts to jerking the Community around, and in the end, it’s frustrating, it’s childish, and it doesn’t help anyone achieve anything or solve the real problems/issues.
(I would be more understanding about this if it were the first time it had happened. Same exact thing happened with Thunderbird 1.5 major update. I could dig up more instances if you want… TBMU just comes to mind because it the freshest instance.)
Again this does not mean any particular bug gets fixed. It just means we deliver matched XULRunner 1.9 and Firefox 3 based on its private XULRunner.
I think more could be done, but it’s a great start, and I’ll take it over… y’know… nothing.
I think it’s difficult to have this discussion when you don’t have the same infra around a product that, say, Fx does (Tinderboxen, standard releases, etc.; XR has some of these, but not all).
name these others or leave them out. Lots of people have various opinions — so what?
This is not a witch hunt; I don’t need to “name names” to make the claim that “more than sayrer holds opinion X about the platform.” If nothing else, one can look at collective decisions that optimize for Firefox over other projects, and figure out that it’s “not just one guy.”
And I only brought it up because you chastised me for carelessly pluralizing. I was not carelessly doing so; I was consciously and accurately doing so.
You’re being too vague here, and not only on this point.
Yah, sometimes I do that. Too much scotch when I blog, I guess.
Have I clarified everything? If not, call me on it, and I’ll attempt to remedy.
@rhelmer
As I noted, “mitigation” was a poor word choice. I thought it was clear that I was referring to having the community help by producing builds or some such; it wasn’t a completely thought out proposal, because there’s no point to thinking much about it if there’s bandwidth to do the builds.
Maybe that wasn’t clear, and if not, that’s my bad.
You’re pretty much tearing up that bug, so you++. It’s great to see that kind of enthusiasm, and I, for one, appreciate it.
If I can help out with reviews or even hacking on small bits of code as necessary, ping me on IRC. Happy to do so.
XR is shared by the Community; the Community should be willing to help, too.
And I am.
@skierpage
I agree that firefox -app is very cool; but it doesn’t fit the model of everyone’s XR usage.
I have heard of a couple of intranet apps put together by larger banks/corporations that are build on XR. I’m sure they would love to have blessed builds from MoCo (blessed, not “full support contract with provisions to sue”) to develop and deploy their applications on.
(The Flickr photo uploader is another such app; they may, for whatever reason, not want or be able to have their app be a bunch of “lightweight XUL packages.”)
Don’t get me wrong; I think making such packages would be great, and building it right into Firefox is even cooler, but for some usecases, that’s not what people need.
@mfinkle
Thanks for answering a question I had no clue what the answer was.
Your pluralizing was about sayrer’s “1.9 is Firefox 3 and nothing but”, and you respond (again vaguely) by citing unnamed others who agree “Firefox comes first”.
Those are two different claims. I don’t know anyone who agreed with sayrer’s statement.
“Firefox comes first” is necessity, and you’re right that lots of people agree with it. We can argue it elsewhere, but I hope we don’t have to. It’s not a blanket reason to starve everything else, and it’s not the same as “1.9 is Firefox 3 and nothing but”.
“Firefox comes first” is definitely a reason to avoid distractions such as XULRunner equality, or disastrous “purity parity” such as “Firefox can’t ship until Thunderbird (or another XUL app) is ready too.”
These are not straw men, obviously. You are making the first case (I think — you need to be more aggressive and less passive :-/), and others have made the second (particularly in connection with Thunderbird).
Hope this helps clear things up.
/be