Mozilla 2 repository migration dirlist - mozilla.dev.platform

Message from discussion Mozilla 2 repository migration dirlist

brendan@mozilla.org

View profile

More options Apr 2 2007, 3:31 pm

Newsgroups: mozilla.dev.platform

From: "bren...@mozilla.org" <bren...@mozilla.org>

Date: 2 Apr 2007 12:31:03 -0700

Local: Mon, Apr 2 2007 3:31 pm

Subject: Re: Mozilla 2 repository migration dirlist

  Forward
  | Print
  | View thread
  | Show original
  | Report this message
  | Find messages by this author
  

On Mar 30, 4:48 pm, Boris Zbarsky <bzbar...@mit.edu> wrote:

> bren...@mozilla.org wrote:
> > A lower tier means breaking changes should be avoided, but they're
> > allowed. Turning a tier-2 or lower tinderbox red does not close the
> > tree.

> That's currently false, depending on what you mean by "tier-2".

Sorry for the abuse of "tier" to mean something other than tinderbox
platform tier.

> As the Firefox
> tinderbox says: "All checkins must not break SeaMonkey or Thunderbird on the
> tier 1 platforms."

Yeah, that's the group of projects -- Firefox, SeaMonkey and
Thunderbird -- that I meant to distinguish from "tier-2" projects. For
Mozilla 2, I'm saying that we make the equivalent initial group be
Firefox and XULRunner.

> Absolutely. I do think, however that after the initial phase of the project,
> once the APIs stabilize somewhat, we should be able to get to a point where we
> have a policy similar to the current one.

I agree so long as the XULRunner-based app is well-owned. There will
be more than one such app, some commercial and not all open source. We
won't just "not care" about all but the designated turn-it-red-close-
the-tree one, but we need an exemplar and it needs to be all open
source.

> As I see it, the relevant features of
> that policy are:

> 1) Core API changes involve an lxr search and fixing of consumers where easy or
> filing of bugs where difficult.

> 2) Sending certain non-Firefox tinderboxen (e.g. Thunderbird) red by a core
> API-change checkin is not acceptable.

> Note that I agree that we can't maintain that state of things during the entire
> Mozilla 2 effort. I do think that we should get Mozilla 2 to a state where we
> can do that for our main apps (Firefox and Thunderbird at least). Given how
> little of the code in our other apps (editor being a major exception) is C++,
> that should be sufficient to prevent serious issues for other apps as well.

I agree in principle, and I hope Thunderbird is XULRunner-based in the
right time frame, but no one has signed up for that. I'm not, and I
don't think my lack of serving that lunch should delay Mozilla 2
initial repository population or early bottom-up development, so....

> I think the question is whether Mozilla 2 will at some point get to a state
> where it's desirable to keep those apps (or some subset of them) working all the
> time. I claim yes.

It depends on the number and kind of APIs.

I used to be a kernel hacker. We kept thousands of apps working across
major kernel rearchitecture at SGI, but not "all at once". "All at
once" is different from "all the time." I'm using "at once" to connote
the continuous integration of tinderboxes, and the turn-it-red-close-
the-tree rule.

If you have a hundred API entry points (think Unix kernel of old;
several hundred now, I'm sure, plus device driver APIs, and later
virtual filesystem APIs), the subset of apps you try not to break can
be large, but it won't be tested fully except over long pre-release
cycles. So not "all at once". Any kernel change that does not mess
with standard header files will not cause compile-time errors for
apps, so no red tree worries.

With thousands of APIs with shared memory data structures, C++ types,
etc., scattered (and this is a bug!) across the source tree, it's a
different story. Not only won't you get test significant test
coverage, you'll find that different API consumers disagree on the
meaning of a given API. Hashing this out takes time and some amount of
back-and-forth, what I've called "API negotiation". It may involve
proving and fixing a bug in the API consumer, API producer, or both.
It's a significant challenge.

For Mozilla 2, we want fewer, better defined embedding and app-support
APIs. I mean fewer than all the ones exported from currently buildable
DLLs/DSOs here, not just the ones marked @status FROZEN or otherwise
"public". We also want better programming languages, which include JS2
and XBL2. These are "APIs" in the best sense, and they enable APIs at
higher levels of discourse, with better compatibility provision
(forward and backward).

Ok, fine aspirations, you say. What does this mean? I'm not going to
promise the moon, but I think we can get to a better condition for all
XUL apps, however hosted, in the Mozilla 2 milestone. But not if we
make the subset too big, too soon. And it's way too soon to be adding
to the proposed Firefox + XULRunner group for the Mozilla 2
repository, which is the topic of this post.

> We _want_ trunk Thunderbird users to be using a trunk core
> so we don't suddenly have to revisit editor changes months later when
> Thunderbird finally switches to a "beta" core. That sort of thing. Again, I
> agree that doing that in the short term is undesirable.

Great, I think we still agree.

> Put another way: if we have a core component, we need an app that actually
> exercises that component and is being used if we're going to test it in a
> serious way. Long-term, that is. If we have no such apps, we should reconsider
> the existence of that component, perhaps. ;)

Not "perhaps", *definitely* and as a matter of regularly enforced
policy. We've always tried to reduce attack surface, and for Mozilla 2
we will move out deadwood even more aggressively. Gopher's on the
chopping block!

> > Hosting does not guarantee no-API-breaks, but
> > it can beget code entanglements, and it does harm first-pull

> With MOZ_CO_PROJECT that's not actually true.

By "that's not true" you mean just the last point, "first-pull"
approachability.

But I claim the cvs.mozilla.org repository size and (related)
organization *does* harm approachability, and there's lots of messy
human-based evidence for this.

One competing example is webkit.org. Now, I don't think webkit.org
should be our model, since the only truly significant app that uses it
(sorry, Nokia) is Safari, which is closed source, and I believe Apple
gets its way with webkit.org if Safari needs it, more than Firefox
rightly rules the Gecko roost. So I can't evaluate how well webkit.org
serves multiple apps, except to note that it's being embedded by Adobe
and other companines and individuals than Nokia.

Webkit is certainly a smaller unit than our minimal back-end module-
set, not only more approachable but with fewer and "flatter" APIs. We
should definitely compete with it at the right layer of our onion.

But (back on topic) I want our hosted-as-Mozilla-2 onion to be smaller
than today's cvs.m.o, even if it's not as small as webkit.org. It
should build Firefox and XULRunner along with the embeddable Gecko.

I agree we may end up with another XUL app hosted in the new
repository, but I do not agree that we must host a second XUL app. It
may be better that way, but it may not. We'll have to find out after
some amount of Mozilla 2 work has been done, and before that, I don't
want to pre-judge it. Thunderbird, if it switches to XULRunner and has
a community to carry it in the Mozilla 2 repository, is certainly a
candidate. But note all the "Ifs" in that sentence. We cannot hold up
Mozilla 2 or the Firefox/XULRunner future on those contingencies.

/be

Forward