Updated Checkin Requirements for Seamonkey
Ben Goodger
tinderbox view for most people. We do have other products though, and as
some of those products are moving closer towards 1.0 we are becoming
more interested in protecting them from bustage, and that's either build
bustage or less visible bustage that's usually caused by API changes.
At this time, we want to make sure that the following builds are
observed in addition to the Seamonkey one:
- Firebird http://tinderbox.mozilla.org/showbuilds.cgi?tree=Phoenix
- Thunderbird (tinderbox pending)
- Camino http://tinderbox.mozilla.org/showbuilds.cgi?tree=Camino
We are now requiring that you consider these products when making API
changes in core components. If you make changes that adversely affect
these products, you will be required to rectify them.
Code for these products lives in:
mozilla/browser (Firebird)
mozilla/toolkit (Firebird + Thunderbird shared)
mozilla/mail (Thunderbird)
mozilla/camino (Camino)
So please expand your searches when looking for code use examples to
update when interfaces change. The best lxr link for seaching these
directories is http://lxr.mozilla.org/mozilla/
These modules are all open, and require only the review set out in their
respective review policies, which is generally module owner/peer review.
--
Ben Goodger, for Firebird
Scott MacGregor, for Thunderbird
Mike Pinkerton, for Camino
L. David Baron
> So please expand your searches when looking for code use examples to
> update when interfaces change. The best lxr link for seaching these
> directories is http://lxr.mozilla.org/mozilla/
I think a better solution here would be to make
http://lxr.mozilla.org/seamonkey/ include these directories. It updates
more often and searches faster, since it doesn't include lots of
unrelated stuff. It would also remind people to include them.
-David
--
L. David Baron <URL: http://dbaron.org/ >
Benjamin Smedberg
> Over the years the Seamonkey tinderbox page has become the default
> tinderbox view for most people. We do have other products though, and as
> some of those products are moving closer towards 1.0 we are becoming
> Ben Goodger, for Firebird
> Scott MacGregor, for Thunderbird
> Mike Pinkerton, for Camino
Since I have been doing a lot of the API gunk for the GRE, this affects
me more profoundly than most. Could this policy be clarified and posted
officially? I expect to run into these sort of situations again in the
near future (global history, embed-locale, embed-content, chrome
registry interfaces).
I have concerns specifically about camino because its build process is
not testable from non-mac platforms. Am I allowed to break the camino
build process as long as I can point out how to fix the problem? Since
that build process is not makefile-driven, I can't even make educated
guesses about how to patch it. Is advance warning to pinkerton enough?
What is the minimum necessary pre-checkin test? Keeping a sea/fb/tb
objdir build for each of my source trees is impossible in terms of disk
space, although I try to keep at least a sea/fb objdir now. And keeping
a camino objdir is impossible.
What about minimo?
While we're at it, I would like to re-advocate Chris Seawood's old plan
to separate the embedding build process from the application build
process. If the old plan of moving CVS directories around was too
ambitious, we can still design a separate set of core makefiles such
that the GRE is build first to a predefined location, and then
applications are layered on top of that, using the existing directory
structure with only minor changes.
At the point where firebird hits 0.9 or 1.0, we're probably gonna want
to keep a stable branch of gecko for long-term stability, while making
some significant (and perhaps backwards-incompatible) changes in
preparation for the fabled mozilla 2.x. This is only practical if the
build process is separated to a degree much greater than currently.
--BDS
Boris Zbarsky
> We are now requiring that you consider these products when making API
> changes in core components.
This would be made significantly easier if the relevant apps would
provide some information on what code they've forked (that way when the
corresponding SeaMonkey files are changed the forked versions could be
changed too)....
> So please expand your searches when looking for code use examples to
> update when interfaces change. The best lxr link for seaching these
> directories is http://lxr.mozilla.org/mozilla/
This updates so rarely as to be nearly useless, especially when merging
to a recent checkin before checking in yourself. I second dbaron's
suggestion to make the default lxr search more useful (it should search
nspr too, for example) instead.
-Boris
Brendan Eich
> I have concerns specifically about camino because its build process is
> not testable from non-mac platforms. Am I allowed to break the camino
> build process as long as I can point out how to fix the problem? Since
> that build process is not makefile-driven, I can't even make educated
> guesses about how to patch it. Is advance warning to pinkerton enough?
There was convincing talk of letting people VNC into Mozilla Foundation
Mac build machines and do tests builds. Cc'ing bryner.
> What is the minimum necessary pre-checkin test? Keeping a sea/fb/tb
> objdir build for each of my source trees is impossible in terms of disk
> space, although I try to keep at least a sea/fb objdir now.
I don't like rebuilding the same .o either, but until we fix that (see
below), I'm curious: why are you short on disk space? Disk is absurdly
cheap. Maybe we can help set you up with a crazy-chofmann type deal.
> What about minimo?
It's not included in the new-apps-shalt-not-be-busted policy, but it's
an up-and-coming port. Keep an eye on it -- you in particular are one
of the people who has to worry about it (you knew the job was dangerous
when you took it).
> While we're at it, I would like to re-advocate Chris Seawood's old plan
> to separate the embedding build process from the application build
> process. If the old plan of moving CVS directories around was too
> ambitious,
It was; also, it subordinated source directory hierarchy to the build
system. Clearly unnecessary and overkill in light of:
> we can still design a separate set of core makefiles such
> that the GRE is build first to a predefined location, and then
> applications are layered on top of that, using the existing directory
> structure with only minor changes.
That was exactly what super-reviewers counterproposed, but I guess cls
departed for greener pastures. I miss his good work, but we can carry
on, and this is the right path. Do you have the energy to spearhead it?
I don't want to sign anyone else up, but maybe leaf can help.
> At the point where firebird hits 0.9 or 1.0, we're probably gonna want
> to keep a stable branch of gecko for long-term stability, while making
> some significant (and perhaps backwards-incompatible) changes in
> preparation for the fabled mozilla 2.x. This is only practical if the
> build process is separated to a degree much greater than currently.
Yes, that's what I'm thinking too, although 2.x may be a bit later than
Firebird 1.0. 2.0 is not yet scheduled, let alone specified fully!
/be
Boris Zbarsky
> I don't like rebuilding the same .o either, but until we fix that (see
> below), I'm curious: why are you short on disk space? Disk is absurdly
> cheap.
I'm actually in a similar situation (which could be remedied in my case
if I had an extra $100 to spend on a disk), as are a number of people
using laptops (where disk upgrades are a lot less trivial). Three
separate debug trees (seamonkey/fb/tb) run about 6GB or so; if you
happen to have multiple trees, that easily jumps up to 20+GB just for
mozilla trees.
More importantly, it currently takes me close to all night to rebuild
the trees I already have after I do a CVS update. If I had to build
three separate copies of everything in all those trees (which is what
would have to happen while FB and TB are not using the same core libs
as SeaMonkey or even each other, dammit), there simply wouldn't be
enough hours in the day for me to be able to cvs update with any sort of
frequency.
Of course, having tb and fb actually build off the same core as
seamonkey would be a huge step toward actually making all this tractable.
Not to mention the extra time required to pull tb and fb and the fact
that there is no simple "one command and forget" way to pull and build
all the relevant files (seamonkey, tb, fb). Adding that would be nice
for testing treewide api change patches of the sort we're worried about.
-Boris
Brian Ryner
>> What is the minimum necessary pre-checkin test? Keeping a sea/fb/tb
>> objdir build for each of my source trees is impossible in terms of
>> disk space, although I try to keep at least a sea/fb objdir now.
>
>
> I don't like rebuilding the same .o either, but until we fix that (see
> below), I'm curious: why are you short on disk space? Disk is absurdly
> cheap. Maybe we can help set you up with a crazy-chofmann type deal.
>
>
I think there's some amount of discretion and common sense that can be
applied in figuring out what to test before checking in. I'd feel silly
saying that every change has to be tested in 4 applications. I don't
and I doubt anyone else does either. What's important is that you
understand the scope of the change being made and what sort of impact it
_could_ have on various applications, then test as needed.
--
-Brian Ryner
bry...@brianryner.com
L. David Baron
> Brendan Eich wrote:
> >There was convincing talk of letting people VNC into Mozilla Foundation
> >Mac build machines and do tests builds. Cc'ing bryner.
>
> SSH.
> http://www.trekweb.com/~jasonb/articles/vnc_ssh.shtml
There's no way to VNC (from outside our office or the colo) to any of
the Mozilla build machines other than tunneling it over ssh.
Gervase Markham
> There was convincing talk of letting people VNC into Mozilla Foundation
> Mac build machines and do tests builds. Cc'ing bryner.
The VNC protocol alone is pretty insecure; we may want to tunnel it over
SSH.
http://www.trekweb.com/~jasonb/articles/vnc_ssh.shtml
Gerv
Brendan Eich
> Brendan Eich wrote:
>
>> Benjamin Smedberg wrote:
>>
>>> I have concerns specifically about camino because its build process
>>> is not testable from non-mac platforms. Am I allowed to break the
>>> camino build process as long as I can point out how to fix the
>>> problem? Since that build process is not makefile-driven, I can't
>>> even make educated guesses about how to patch it. Is advance warning
>>> to pinkerton enough?
>>
>> There was convincing talk of letting people VNC into Mozilla
>> Foundation Mac build machines and do tests builds. Cc'ing bryner.
>
> Augh! Timesharing build/test time on OSX between 10 people would be
> bad enough, how many people are working on shared components? We're
> going to need more macs, i think.
We could use more of lots of things. I think bsmedberg is first, and
this is a special deal, not something we throw open to everyone who
needs to test on Mac. We'd like to, but lunches ain't free.
>> I don't like rebuilding the same .o either, but until we fix that
>> (see below), I'm curious: why are you short on disk space? Disk is
>> absurdly cheap. Maybe we can help set you up with a crazy-chofmann
>> type deal.
>
> Does crazy-chofmann give disk to everyone with cvs-write access?
ONE DAY ONLY, THIS SUPER-SATURDAY! COME ON DOWN, BRING THE WIFE AND KIDS!!!
>> That was exactly what super-reviewers counterproposed, but I guess
>> cls departed for greener pastures. I miss his good work, but we can
>> carry on, and this is the right path. Do you have the energy to
>> spearhead it? I don't want to sign anyone else up, but maybe leaf can
>> help.
>
> I might be able to help, but not while other sysadminly things are
> burning (cvs over ssh, talkback, enough build machines to support all
> our products/branches).
Noted. Any other volunteers, please step up. Obvious good practice
would not rebuild the same Gecko .o for each of N Gecko-based apps
(ifdefs and such hard cases to the contrary notwithstanding). We want
our build system to move toward this obvious good practice. Who will help?
/be
leaf nunes
> Benjamin Smedberg wrote:
>
>> I have concerns specifically about camino because its build process is
>> not testable from non-mac platforms. Am I allowed to break the camino
>> build process as long as I can point out how to fix the problem? Since
>> that build process is not makefile-driven, I can't even make educated
>> guesses about how to patch it. Is advance warning to pinkerton enough?
>
>
> There was convincing talk of letting people VNC into Mozilla Foundation
> Mac build machines and do tests builds. Cc'ing bryner.
>
Augh! Timesharing build/test time on OSX between 10 people would be bad
enough, how many people are working on shared components? We're going to
need more macs, i think.
>
>> What is the minimum necessary pre-checkin test? Keeping a sea/fb/tb
>> objdir build for each of my source trees is impossible in terms of
>> disk space, although I try to keep at least a sea/fb objdir now.
>
>
> I don't like rebuilding the same .o either, but until we fix that (see
> below), I'm curious: why are you short on disk space? Disk is absurdly
> cheap. Maybe we can help set you up with a crazy-chofmann type deal.
>
Does crazy-chofmann give disk to everyone with cvs-write access?
>
>> we can still design a separate set of core makefiles such that the GRE
>> is build first to a predefined location, and then applications are
>> layered on top of that, using the existing directory structure with
>> only minor changes.
>
>
> That was exactly what super-reviewers counterproposed, but I guess cls
> departed for greener pastures. I miss his good work, but we can carry
> on, and this is the right path. Do you have the energy to spearhead it?
> I don't want to sign anyone else up, but maybe leaf can help.
>
I might be able to help, but not while other sysadminly things are
Christopher Seawood
> Benjamin Smedberg wrote:
>> we can still design a separate set of core makefiles such that the GRE
>> is build first to a predefined location, and then applications are
>> layered on top of that, using the existing directory structure with
>> only minor changes.
>
>
> That was exactly what super-reviewers counterproposed, but I guess cls
> departed for greener pastures. I miss his good work, but we can carry
> on, and this is the right path. Do you have the energy to spearhead it?
> I don't want to sign anyone else up, but maybe leaf can help.
I'm not dead yet. I felt like going for a walk.
I really wish I had those emails (gone with the netscape.com account) as
I don't recall a clear counter-proposal being presented though the
original proposal was amended to include the concerns of some
super-reviewers.
In any case, it should be noted that what's being proposed now has been
worked upon in one form or another since at least 2000. The
resurrection of REQUIRES (bug 59454), the addition of tiers to the
toplevel Makefile (bug 107302), the proposed gre.mk (bug 201149) and
numerous bugs in between have all been steps towards that common goal.
However, we've reached a point where the next step of changes needed to
further the goal are no longer merely a build system concern. IMO, that
was one of the key reasons that both proposals have stagnated this long.
Since such a change would affect almost every developer and the
development of multiple products, we would need module owner buy-in at
least on par with what we just saw from Goodger, MacGregor & Pinkerton
with the appropriate backing from mozilla.org. To my knowledge, that
level of support wasn't in place when the proposals were last being
seriously discussed. If the support is in place now, then state that
and let's move along.
- cls
Brendan Eich
> To my knowledge, that level of support wasn't in place when the
> proposals were last being seriously discussed. If the support is in
> place now, then state that and let's move along.
Didn't I just do that?
I would like leaf's buy-in, along with SRs (I'm cc'ing them so they can
catch up on this thread via news). If anyone dissents from the idea
that we should change the build system so that you can
- pull one of a set of CVS modules (a module for A U {Gecko}, for all A
in PowerSet(Apps)?),
- build e.g. Gecko, Firebird, and SeaMonkey within that one cvs
workarea, and
- not have to rebuild all the common files that contain no product ifdefs,
then please speak fast. Who wouldn't want this?
This is a pretty general goal. We probably will argue over the
specifics in the weeks ahead. Any contention there is tactical or
operational, so please don't take another walk ;-). I think we agree on
at least the high few bits of the strategy word.
/be
leaf
I'm going to be adding the firefox (formerly firebird, formerly phoenix)
modules, as well as thunderbird and any other gecko-based
applications to the module currently called "Seamonkey", but i'm going
to rename it to mozilla-geckoapps. IIRC, nspr is already included in
this LXR module, and if it isn't, i will add it.
leaf nunes
I'm going to be adding the firefox (formerly firebird, formerly phoenix)
Benjamin D. Smedberg
> I'm going to be adding the firefox (formerly firebird, formerly phoenix)
> modules, as well as thunderbird and any other gecko-based applications
> to the module currently called "Seamonkey", but i'm going to rename it
> to mozilla-geckoapps. IIRC, nspr is already included in this LXR
> module, and if it isn't, i will add it.
Do you mean "SeamonkeyAll"? Don't add NSPR, it's shipped from the
NSPR_CLIENT branch and so you can't pull it the same way. TB/FB sounds
OK, although as a long-term solution I think it's not viable.
--BDS
Benjamin D. Smedberg
> Do you mean "SeamonkeyAll"? Don't add NSPR, it's shipped from the
Ignore that, I thought we were talking about CVS modules, not LXR.
You're not going to change the http://lxr.mozilla.org/seamonkey/ URI,
are you? I wouldn't suggest that; many many people have bookmark
keywords and other stuff pointing the the current URI.
--BDS
Gervase Markham
> I'm going to be adding the firefox (formerly firebird, formerly phoenix)
> modules, as well as thunderbird and any other gecko-based applications
> to the module currently called "Seamonkey", but i'm going to rename it
> to mozilla-geckoapps. IIRC, nspr is already included in this LXR
> module, and if it isn't, i will add it.
Can we please have a nicer name than mozilla-geckoapps? How about
something generic like "Common" (as in 'commonly-used') or "Mainstream"?
Gerv
leaf nunes
I would *prefer* to change the actual URI. I will try and keep the old
one working with an alias or redirect.
leaf
I would *prefer* to change the actual URI. I will try and keep the old
leaf nunes
How about mozilla-apps?
Common implies "code shared between several things", which would make
sense for NSPR, gecko, and maybe libpr0n.
Gervase Markham
> How about mozilla-apps?
>
> Common implies "code shared between several things", which would make
> sense for NSPR, gecko, and maybe libpr0n.
Well, to match the other ones in style, it would be MozillaApps - but
it's definitely better :-)
Gerv
leaf nunes
MozillaApps it is, then. Going once... (i will do this tomorrow morning
if i don't hear any further objections).
Daniel Kirsch
> I would *prefer* to change the actual URI. I will try and keep the old
> one working with an alias or redirect.
What about this newsgroup? Will there be a new one too?
netscape.public.mozilla.mozillaapps?
netscape.public.mozilla.apps?
Daniel
Steffen Wilberg
Tomorrow morning was 4 months ago. ;-)
Or is /mozilla updated more often, despite lxr.m.o still says "updated
nightly"? [BTW, it should be "entire", not "entre"]
Even more helpful right now would be an option to search the
AVIARY_1_0_20040515_BRANCH. Firefox 1.0 and Thunderbird 1.0 are planned
to ship from that branch, which won't happen until late summer or so.
Please let me know if I can assist in any manner.
Steffen
Christian Biesinger
> Or is /mozilla updated more often, despite lxr.m.o still says "updated
> nightly"? [BTW, it should be "entire", not "entre"]
The firefox and thunderbird files seem to be part of lxr's SeaMonkey module
these days...
Steffen Wilberg
obvious. ;-)
I thought it was going to be "MozillaApps", with the old "SeaMonkey"
linking to that?
But thanks, Biesi!
Frank Wein
> I'm going to be adding the firefox (formerly firebird, formerly phoenix)
> modules, as well as thunderbird and any other gecko-based applications
> to the module currently called "Seamonkey", but i'm going to rename it
> to mozilla-geckoapps. IIRC, nspr is already included in this LXR
> module, and if it isn't, i will add it.
While you're at it, could also take a look at
http://bugzilla.mozilla.org/show_bug.cgi?id=221309 and see if you can do
this, too?
Frank
Frank Wein
oh heh, just saw that your posting was like 4 month ago...