2003-05-05 - Summary of mozilla.org staff meeting
Gervase Markham
-------------------------------------------------
Present: mitchell, myk, scc, gerv, blizzard, dmose, asa, brendan,
marcia, sspitzer.
*1.3.1*
- Sitting on the staging servers still
- Change of plan from last week; now we are doing at the same time as
1.4 beta
- This is to give downloaders the option to get the most appropriate
release and not regret having downloaded 1.3.1 when 1.4b was close at
hand.
*1.4 beta*
- 5 blocking bugs left, 4 of which have patches being reviewed
- Our builds seem pretty good
- Asa hopes to have this finished up by Wednesday
*1.4 final*
- May 16th is the official branch date
- We're not terrribly concerned about hitting that exact date because
there isn't a lot of 1.5a pressure. We're make the branching call when
we're happy that we've gotten enough trunk nightly build testing on
the late-breaking 1.4 changes.
- We will probably do release candidates like we did for the 1.0
release. We'll certainly do at least one.
- Holding on the trunk as long as we can, then ship off the branch
- The longer we hold, the longer we delay the transition to Mozilla
Firebird and Mozilla Thunderbird.
*Mozilla Firebird transition*
- Potential for enormous confusion in Bugzilla and on Tinderbox
- Do we need to make the Bugzilla changes by the time we open for 1.5?
- We certainly need to make them by the time we ship 1.4 final
- We need to educate 1.4 downloaders and 1.5 nightly downloaders
- The ideal point for making the Bugzilla changes is the few days of
slowdown before the 1.4 release
- Proposed new Bugzilla Products: Core Services, Seamonkey Navigator,
Seamonkey Messenger, Mozilla Browser, Mozilla Mail, Camino, etc...
- Need custom templates for Bugzilla to make sure bugs get filed in the
right place
- Asa to write up a proposal for the short-term and long-term Bugzilla
naming plan
*Mozilla Firebird 0.6*
- A few more "Phoenix" things to rename
- Released RSN
Gerv
Chris Casciano
wrote on 5/8/03 7:08 PM:
> *Mozilla Firebird transition*
>
> - Potential for enormous confusion in Bugzilla and on Tinderbox
>
> - Do we need to make the Bugzilla changes by the time we open for 1.5?
> - We certainly need to make them by the time we ship 1.4 final
> - We need to educate 1.4 downloaders and 1.5 nightly downloaders
> - The ideal point for making the Bugzilla changes is the few days of
> slowdown before the 1.4 release
>
> - Proposed new Bugzilla Products: Core Services, Seamonkey Navigator,
> Seamonkey Messenger, Mozilla Browser, Mozilla Mail, Camino, etc...
> - Need custom templates for Bugzilla to make sure bugs get filed in the
> right place
>
> - Asa to write up a proposal for the short-term and long-term Bugzilla
> naming plan
Its good to see this transition getting some attention in terms of its
affect on Bugzilla. One of the things I'd really like to see that I've
haven't seen in the recent past is some clear documentation on how this
transition impacts already existing bugs. Not just in terms of what the new
product categories will be but some real guidelines on what the change over
means for the validity of existing bugs. The incidents in the "recent past"
I'm speaking of include:
* I'm still coming across lots of old Mac/CFM bugs that aren't reproducible
with MachO but have been left open to rot. From what I've seen there isn't
an official stance on how to close these bugs (WFM, INVALID) and its been
left up to the individual. If there is mention of a preferred stance out
there (perhaps in the newsgroups) it isn't easily visible for someone going
back now to triage these older bugs.
* I also regularly come across resolvable Camino bugs from the move from the
the trunk from the 1.0.x branch. It also caused a lot of "regressions" and
migration things without any official direction on how someone should file
them.
* On a smaller scale, there was also a feeling out period with the Camino
change away from the use of the sidebar/drawer where some direction would
have saved some confusion or at least would have been nice to reference when
closing bugs.
(not asking what to do in any of the above scenarios - I'm felt my way
through each case already.)
--
[ Chris Casciano ] [ m...@placenamehere.com ]
[ see things @ http://www.placenamehere.com ]
[ read words @ http://www.chunkysoup.net/ ]
Christian Biesinger
> - Proposed new Bugzilla Products: Core Services, Seamonkey Navigator,
Why not "Gecko" instead of "Core Services"?
Gervase Markham
Because there's more to it than just Gecko; e.g. Necko (the networking
library, for those who don't know.)
If you have other suggestions for the split, let's hear them. :-)
Gerv
Benjamin Smedberg
>
>
> Because there's more to it than just Gecko; e.g. Necko (the networking
> library, for those who don't know.)
>
> If you have other suggestions for the split, let's hear them. :-)
Why not "GRE" or "Gecko Runtime Environment"? That's what we're actually
distributing, right?
--BDS
Christopher Seawood
That brings up the interesting question of:
What exactly *are* we shipping?
Can we get that answered before we start artificially divvying up
bugzilla (and potentially the cvs tree)
- cls
Axel Hecht
Whatever we call it, toolkit as in the roadmap or GRE as in the
embedding docs, we should be clear about that and use that as bugzilla
category.
Axel
Christopher Blizzard
How do you mean?
--Chris
Christopher Seawood
Well, for starters, are there concrete plans to ship the GRE separate
from the apps which require them? If so, will the apps be forced to use
one "standard" version of the GRE or will each app be built against
their own variant of the GRE? If we're not shipping a separate GRE,
then presumably each app will bundle their own variant as they do now
which kinda defeats the purpose of providing a separate GRE.
- cls
Michael Lefevre
> Christopher Blizzard wrote:
>> Christopher Seawood wrote:
>>
>>> Benjamin Smedberg wrote:
>>>
>>>> >> Why not "Gecko" instead of "Core Services"?
>>>> >
>>>> >
>>>> > Because there's more to it than just Gecko; e.g. Necko (the
>>>> networking
>>>> > library, for those who don't know.)
>>>> >
>>>> > If you have other suggestions for the split, let's hear them. :-)
>>>>
>>>> Why not "GRE" or "Gecko Runtime Environment"? That's what we're
>>>> actually distributing, right?
>>>
>>> That brings up the interesting question of:
>>>
>>> What exactly *are* we shipping?
>>>
>>> Can we get that answered before we start artificially divvying up
>>> bugzilla (and potentially the cvs tree)
>>>
>
> Well, for starters, are there concrete plans to ship the GRE separate
> from the apps which require them? If so, will the apps be forced to use
> one "standard" version of the GRE or will each app be built against
> their own variant of the GRE? If we're not shipping a separate GRE,
> then presumably each app will bundle their own variant as they do now
> which kinda defeats the purpose of providing a separate GRE.
I was under the impression that the intention was to ship a "bundle" of
separate apps, so the nightlies would contain, in a single
zip/tarball/sea-installer as now, firebird, thunderbird, (a single) GRE,
composer, and some basic extensions (chatzilla, DOMI, etc).
given build resources, one could also have separate files containing just
Firebird+GRE, or sort out a cross-platform net installer for that purpose,
but the idea of having many manual downloads for GRE and the different
components (particularly if there were variant GREs) sounds like a
nightmare for users, QA and developers...
"hi, I'm using Firebird 2003070208 with GRE 2003063010, Thunderbird
2003070514 with GRE 2003070514 and Composer 2003070308 with one of those
GREs but I'm not sure which. I had Chatzilla installed, but I didn't
update that when I last installed Firebird. I want to install the
spellchecker, but I can't work out which build I need..."
Given the existing lack of robustness when installing builds over older
builds, we need to improve the situation, not make it worse...
--
Michael
Benjamin Smedberg
> separate apps, so the nightlies would contain, in a single
> zip/tarball/sea-installer as now, firebird, thunderbird, (a single) GRE,
> composer, and some basic extensions (chatzilla, DOMI, etc).
How nightlies are shipped is not really the most important question here:
1) is mozilla.org going to be the "official" distributor of the GRE? (I
would argue that "yes" it should) and that we should also organize FTP
mirrors similar to the GNU mirroring system.
2) if so, how are the Thunderbird/Firebird/whatever projects going to
coordinate so that they use the *same* GRE? If they do milestones at the
same time, it's easy; but it seems more likely that GRE will come to a
milestone point, and then the frontend apps will ship a little bit later
using that latest GRE milestone.
3) The current CVS tree is going to become more and more unwieldy, as it
builds multiple projects with different lifecycles, etc. Christopher
Seawood has proposed, and I heartily concur, that the GRE ought to
become its own build tree, to help logcailly and physically separate it
from the frontend applications.
We can still to ship a daily GRE and a daily Thunderbird and a daily
Firebird together...
--BDS
Christopher Seawood
> I was under the impression that the intention was to ship a "bundle" of
> separate apps, so the nightlies would contain, in a single
> zip/tarball/sea-installer as now, firebird, thunderbird, (a single) GRE,
> composer, and some basic extensions (chatzilla, DOMI, etc).
My impression was that we were shipping a "bundle of apps", not the
"apps as a bundle". The bundle of apps approach gives us the same
functionality that we currently have without unnecessarily tying a
specific version/featureset of one app component to another.
> given build resources, one could also have separate files containing just
> Firebird+GRE, or sort out a cross-platform net installer for that purpose,
> but the idea of having many manual downloads for GRE and the different
> components (particularly if there were variant GREs) sounds like a
> nightmare for users, QA and developers...
First, we don't have net installers on all platforms so we will *always*
have to support manual installs. Second, what is the point of separating
the apps if you're going to continue to build & distribute them as a
single monolithic bundle? We already have the ability to do "minimal"
installs of certain pieces.
Also, regardless of whether the apps mozilla.org ships use it, there
should be a manual download of the GRE since that's what we're
recommending to people who want to build against Gecko. We've been
saying for years that a person shouldn't have to build the entire
browser just to get Gecko. Like gtk and other toolkits, we should
provide binaries for the "standard" version of the GRE.
> "hi, I'm using Firebird 2003070208 with GRE 2003063010, Thunderbird
> 2003070514 with GRE 2003070514 and Composer 2003070308 with one of those
> GREs but I'm not sure which. I had Chatzilla installed, but I didn't
> update that when I last installed Firebird. I want to install the
> spellchecker, but I can't work out which build I need..."
By treating the GRE as a separate entity, we've basically said that
we're going to support using a different version of the GRE than the app
was built against. Besides the user issue of not being able to
determine their version number, I'm not seeing the problem. The moment
you decoupled the appsuite, you allowed for the possibility of reports
of multiple rendering engines in multiple apps. Each frontend piece
will just need to be able to report which version of the GRE it is using.
> Given the existing lack of robustness when installing builds over older
> builds, we need to improve the situation, not make it worse...
IMO, that's a separate issue. We should acknowledge that installing new
builds over older builds is fundamentally broken and move along. I
don't know of any other app of this size and with as many possible
variations that attempts to install a newer version over an older
version. Most apps that I see install themselves in a version specific
directory *beside* the older version.
- cls
James Graham
> Michael Lefevre wrote:
>
>> "hi, I'm using Firebird 2003070208 with GRE 2003063010, Thunderbird
>> 2003070514 with GRE 2003070514 and Composer 2003070308 with one of those
>> GREs but I'm not sure which. I had Chatzilla installed, but I didn't
>> update that when I last installed Firebird. I want to install the
>> spellchecker, but I can't work out which build I need..."
>
>
> By treating the GRE as a separate entity, we've basically said that
> we're going to support using a different version of the GRE than the app
> was built against. Besides the user issue of not being able to
> determine their version number, I'm not seeing the problem. The moment
> you decoupled the appsuite, you allowed for the possibility of reports
> of multiple rendering engines in multiple apps. Each frontend piece
> will just need to be able to report which version of the GRE it is using.
>
able to use one version of GRE and another version of the frontend? If
there are going to be nightly builds of Browser and Mail, I see no
reason they should work with anything other than the nightly GRE from
the same date. Afterall, as far as I understand it, these products are
distributed becase they allow testing of the backend. If you want a
different version of Mail and Browser installed, you will need different
GRE's (which of course means that the path naming schema will have to
cope with this possibility). I don't expect to be able to replace random
library files from today's build with those from a week ago, and still
have things work properly, and I don't see how that will change.
The big win comes for milestone releases, since someone can install GRE
1.6 (or whatever) and only need a single copy of that for all the gecko
apps they want to run - as long as they are based on the 1.6 branch.
Since Mozilla has the concept of stable branches, which are recommended
for embedders, that could be a big win in some situations (not to
mention you can have Composer without needing to also install mail and
browser, if that's what you want). Therefore, as far as I can see, the
downloads for any day should be:
GRE
Browser
Mail
Composer
etc.
Where Browser, Mail, Composer, etc. depend on the GRE. Of course on
platforms with installers, this could be sorted out automagically by the
installer. That would be more significant for milestone releases and
outside embeddors since the user has a good chance of already having the
correct (milestone) version of GRE installed.
This could be totally wrong. It is probably based on naiveity and
misinterpretation as much as fact.
James
John Keiser
> Christopher Seawood wrote:
>
>> Michael Lefevre wrote:
>>
>>> "hi, I'm using Firebird 2003070208 with GRE 2003063010, Thunderbird
>>> 2003070514 with GRE 2003070514 and Composer 2003070308 with one of those
>>> GREs but I'm not sure which. I had Chatzilla installed, but I didn't
>>> update that when I last installed Firebird. I want to install the
>>> spellchecker, but I can't work out which build I need..."
>>
>>
>>
>> By treating the GRE as a separate entity, we've basically said that
>> we're going to support using a different version of the GRE than the
>> app was built against. Besides the user issue of not being able to
>> determine their version number, I'm not seeing the problem. The
>> moment you decoupled the appsuite, you allowed for the possibility of
>> reports of multiple rendering engines in multiple apps. Each frontend
>> piece will just need to be able to report which version of the GRE it
>> is using.
>>
> Okay, pardon my ignorance, but where is it suggested that people will be
> able to use one version of GRE and another version of the frontend? If
> there are going to be nightly builds of Browser and Mail, I see no
> reason they should work with anything other than the nightly GRE from
> the same date.
This is a major point of freezing APIs: binary compatibility. If you
use frozen APIs then you should be ok from GRE to GRE.
Of course, right now we use more than just the frozen APIs in mailnews
and browser, but that is a bug to be fixed that causes us not to be able
to use different GREs--not an intentional design decision.
> Afterall, as far as I understand it, these products are
> distributed becase they allow testing of the backend.
And there are many products based on that same backend that are not
"testbeds," for whom this *is* important. One of the original ideas
that spawned GRE was "hey, if you had Netscape on your machine and you
wanted to download Mozilla, what if that download could just be 1-2M?"
Or for example CompuServe and Netscape could share the download time.
This stuff has real world impact for embedders, who don't want their
downloads to be any bigger than they have to be.
--John Keiser
Christopher Seawood
> Christopher Seawood wrote:
>> By treating the GRE as a separate entity, we've basically said that
>> we're going to support using a different version of the GRE than the
>> app was built against. Besides the user issue of not being able to
>> determine their version number, I'm not seeing the problem. The
>> moment you decoupled the appsuite, you allowed for the possibility of
>> reports of multiple rendering engines in multiple apps. Each frontend
>> piece will just need to be able to report which version of the GRE it
>> is using.
>>
> Okay, pardon my ignorance, but where is it suggested that people will be
> able to use one version of GRE and another version of the frontend? If
That comes from talking to some of the developers and reading
http://www.mozilla.org/projects/embedding/MRE.html . The webpage has:
"If an appropriate version of the GRE is not already installed, the user
can be prompted to download and install the GRE, or the installation
program can install a copy of the GRE that is redistributed with the
application."
There's no definition of the "appropriate version" so I could be
mistaken as I haven't heard the "official word" one way or the other.
> I don't expect to be able to replace random
> library files from today's build with those from a week ago, and still
> have things work properly, and I don't see how that will change.
A random library, no. A not-so-random set of libraries (GRE), yes. And
you wouldn't be replacing the libraries in your build, you'd be pointing
your build to a different GRE version. And, actually, the pointing
should be transparent as it's already built into the GRE detection code.
As long as there are not incompatible API changes, your build should
just work. My understanding is that the apps will request a minimal
version of the GRE that they support, not just one specific version. If
a compatible version is installed, they will use it. Otherwise, they
will install their own version. For a gratuitious established toolkit
practice comparison, we build Mozilla against gtk 1.2.10 for the nightly
builds but they should run against *any* gtk 1.2.x version because they
are binary compatible. The same should apply for the GRE.
My prediction is that your expectations will not change as long as the
GRE is bundled to a specific application or group of applications. When
the GRE is available as and treated as a standalone toolkit, I would
hope that the number of incompatible changes between the GRE versions
would diminish if only due to the negative feedback of being
incompatible from release to release.
> The big win comes for milestone releases, since someone can install GRE
> 1.6 (or whatever) and only need a single copy of that for all the gecko
> apps they want to run - as long as they are based on the 1.6 branch.
Right. The key there is that the apps are based upon the 1.6 *GRE*
release not that the GRE is based upon the 1.6 *Mozilla* release which
is currently how things are done.
> Since Mozilla has the concept of stable branches, which are recommended
> for embedders, that could be a big win in some situations (not to
> mention you can have Composer without needing to also install mail and
> browser, if that's what you want). Therefore, as far as I can see, the
> downloads for any day should be:
> GRE
> Browser
> Mail
> Composer
> etc.
So if I just want to get the fix for that nasty rendering bug that
occurs with the realplayer plugin (for example) which requires a fix to
liblayout.so & libgkplugin.so, I have to reinstall the entire bundle of
apps? Reinstalling all of the GRE would be overkill for those 2
libraries that need to be replaced but acceptible since the GRE is a
standalone entity. If I have to reinstall the entire bundle of
applications, I have to ask again, what was the point of artificially
separating them?
> Where Browser, Mail, Composer, etc. depend on the GRE. Of course on
> platforms with installers, this could be sorted out automagically by the
> installer. That would be more significant for milestone releases and
> outside embeddors since the user has a good chance of already having the
> correct (milestone) version of GRE installed.
Browser, Mail, & Compser will have to depend upon the GRE but they
shouldn't be locked into one specific version of the GRE.
- cls
James Graham
> James Graham wrote:
>
>> Okay, pardon my ignorance, but where is it suggested that people will
>> be able to use one version of GRE and another version of the frontend?
>> If there are going to be nightly builds of Browser and Mail, I see no
>> reason they should work with anything other than the nightly GRE from
>> the same date.
>
>
> This is a major point of freezing APIs: binary compatibility. If you
> use frozen APIs then you should be ok from GRE to GRE.
>
> Of course, right now we use more than just the frozen APIs in mailnews
> and browser, but that is a bug to be fixed that causes us not to be able
> to use different GREs--not an intentional design decision.
That makes sense. But if unfrozen interfaces are never to be used in
Mozilla.org products, how do you test the unfrozen interfaces before
freezing them? Am I just displaying my lack of understanding of software
development here? I can imagine each milestone only using frozen
interfaces (along with some promise that backwards compatibility will be
maintained until the major version number changes), but if nsIFoo is
joined by nsIFoo2, I would expect Browser and Mail to use the newer
interface, and so forego the oppertunity to work with an older GRE. Then
by the time of the next milestone, nsIFoo2 would be frozen and anything
that used an older GRE would still work with the new GRE, whilst
something based on the new version of GRE might not work with the older
version.
This does suggest that the GRE and browser / mail milestone releases
would still be coupled, but that makes sense if mozilla.org still
regards Browser and Mail as convenient ways of testing the backend
technologies. My naive impresssion is that it would also require longer
release cycles to make time for freezing things.
>> Afterall, as far as I understand it, these products are
>
>> distributed becase they allow testing of the backend.
>
>
> And there are many products based on that same backend that are not
> "testbeds," for whom this *is* important. One of the original ideas
> that spawned GRE was "hey, if you had Netscape on your machine and you
> wanted to download Mozilla, what if that download could just be 1-2M?"
> Or for example CompuServe and Netscape could share the download time.
> This stuff has real world impact for embedders, who don't want their
> downloads to be any bigger than they have to be.
I appreciate this, but I assume embedders use milestone releases
(currently of Mozilla, soon of GRE). So, only a single download will be
required as long as the products all have the same minimum GRE
requirement. For example Netscape and Compuserve might both work off GRE
1.6 so if you has either of these then Mozilla Browser based on 1.6
would be a 2Mb download, but if you wanted Mozilla Browser based on 1.7,
you might need a new GRE and so a bigger download. But if you obtained
GRE 1.7, it would also be picked up by the other installed products, so
they would benefit from stability fixes and so on.
However, I imagine the situation for nightly builds of Mozilla.org
products being different, if they do indeed make use of the latest
backend changes before they get frozen. Backward compatbility could be
broken at any time at any time and, since testing of the GRE is
presumably desirable, people would be encouraged to use the latest
avaliable version. So you'd get a nightly package for each of the
components (GRE backend and the various consumers). It should be
possible to just download GRE without getting the new versions of the
apps, but it should also be possible to get both. From that point of
view, it *might* make sense to ensure that the apps only worked with a
GRE newer than the one they were built against, even if that was
strictly unnecesary (of course, it might not if that helped test that
older apps didn't break with newer changes).
Am I making any sense at all now? I'm *really* sorry if I'm just showing
my ignorance.
James
david avery
this brings up a question i have had for a while, what do we plan to do
with things like SVG that are optional , but part of the GRE not an
application. since i build a SVG nightly and SVG is not in the GRE by
default are we going to have a bunch of GREs with various options enabled?
this is especially bad right now since the SVG in the tree is stale and
the main work is on a partial branch
dave
Christopher Blizzard
If SVG is part of layout (and last time I knew anything about it, it
was) it's going to have to be a build time option, not something that
can be distributed seperately.
--Chris
daa
> david avery wrote:
>
>> Christopher Seawood wrote:
>>
>>> Benjamin Smedberg wrote:
>>>
>>>> >> Why not "Gecko" instead of "Core Services"?
>>>> >
>>>> >
>>>> > Because there's more to it than just Gecko; e.g. Necko (the
>>>> networking
>>>> > library, for those who don't know.)
>>>> >
>>>> > If you have other suggestions for the split, let's hear them. :-)
>>>>
>>>> Why not "GRE" or "Gecko Runtime Environment"? That's what we're
>>>> actually distributing, right?
>>>
>>>
>>>
>>>
>>> That brings up the interesting question of:
>>>
>>> What exactly *are* we shipping?
>>>
>>> Can we get that answered before we start artificially divvying up
>>> bugzilla (and potentially the cvs tree)
>>
>>
>>
>> this brings up a question i have had for a while, what do we plan to
>> do with things like SVG that are optional , but part of the GRE not an
>> application. since i build a SVG nightly and SVG is not in the GRE by
>> default are we going to have a bunch of GREs with various options
>> enabled?
>>
>> this is especially bad right now since the SVG in the tree is stale
>> and the main work is on a partial branch
>>
>>
> was) it's going to have to be a build time option, not something that
> can be distributed seperately.
SVG is integral with content and layout, which means we have to have an
SVG and non-SVG GRE ( there are nightly SVG builds) daily
and I will be posting 1.4 release SVG builds too
same deal with MATHML
dave
Christian Biesinger
> same deal with MATHML
No, because MathML is on by default these days. So the "normal" GRE will
include it.
Michael Lefevre
> James Graham wrote:
>> Christopher Seawood wrote:
>>
>>> Michael Lefevre wrote:
>>>
>>>> "hi, I'm using Firebird 2003070208 with GRE 2003063010, Thunderbird
>>>> 2003070514 with GRE 2003070514 and Composer 2003070308 with one of those
>>>> GREs but I'm not sure which. I had Chatzilla installed, but I didn't
>>>> update that when I last installed Firebird. I want to install the
>>>> spellchecker, but I can't work out which build I need..."
>>>
>>> By treating the GRE as a separate entity, we've basically said that
>>> we're going to support using a different version of the GRE than the
>>> app was built against. Besides the user issue of not being able to
>>> determine their version number, I'm not seeing the problem. The
>>> moment you decoupled the appsuite, you allowed for the possibility of
>>> reports of multiple rendering engines in multiple apps. Each frontend
>>> piece will just need to be able to report which version of the GRE it
>>> is using.
>>>
>> Okay, pardon my ignorance, but where is it suggested that people will be
>> able to use one version of GRE and another version of the frontend? If
>> there are going to be nightly builds of Browser and Mail, I see no
>> reason they should work with anything other than the nightly GRE from
>> the same date.
>
> This is a major point of freezing APIs: binary compatibility. If you
> use frozen APIs then you should be ok from GRE to GRE.
but the APIs are not frozen at the moment, so that doesn't help with
what's going to happen immediately after the 1.4 branch...
> Of course, right now we use more than just the frozen APIs in mailnews
> and browser, but that is a bug to be fixed that causes us not to be able
> to use different GREs--not an intentional design decision.
yes, fixing that bug should certainly be the goal. but, unless it's
possible to fix that bug in a day or two, something needs to be done while
development is progressing towards that goal...
--
Michael
Darin Fisher
Christopher Seawood wrote:
I for one would love to see the GRE distributed separately (much like
GTK or other libraries). I think it would help lower the barrier to
entry for would be gecko embedders. Moreover, developers might actually
look to the GRE as a source for various smaller utilities (to
leverage, say, the URL parser). I think the GRE has a lot of compelling
functions above and beyond its primary purpose as a rendering engine.
Having the GRE readily available to developers is a crucial step that
should be a high priority.
It seems appropriate that Mozilla applications based on the GRE should
be built against the GRE and not just intertwined with it. Though it
would be nice to have a very clean separation between the GRE and the
apps in the tree, I can see that that is going to be a very painful
separation. We need to take it in steps. Perhaps the first step would
be to change the way mozilla is built such that the GRE is built first
with the rest of the applications built subsequently. Even this kind of
reshuffling is probably going to be plenty painful, but it would get us
closer to separating the GRE from the apps.
Initially (and maybe for a while), it will make good sense for the GRE
to track the milestones and release dates of the app suite. This will
provide for the same sort of integrated (and immediate) testing that
we've always had, but we'll still benefit from a separately built GRE
that can be easily extracted from the mozilla source tree.
Ultimately, it may make sense for the release cycle of the GRE to
diverge from the release cycle of the major apps embedding it. Heck, we
have some experience with this model already. The 1.0 version of the
GRE has seen plenty of separately released products (Camino + commerical
products). So, I think we know that this can work given that the trunk
of the major mozilla apps continue to track the trunk of the GRE.
As for utilizing only frozen APIs between mozilla apps and the GRE, we
know we're going to hit many bumps. There are many APIs that simply
aren't mature enough to freeze, and so we may need to live in a world
for a while in which apps limit themselves to a very narrow set of GREs.
That seems reasonable. Over time, this will get better as the set of
frozen interfaces grows.
Darin
Gervase Markham
> * I'm still coming across lots of old Mac/CFM bugs that aren't reproducible
> with MachO but have been left open to rot. From what I've seen there isn't
> an official stance on how to close these bugs (WFM, INVALID) and its been
> left up to the individual. If there is mention of a preferred stance out
> there (perhaps in the newsgroups) it isn't easily visible for someone going
> back now to triage these older bugs.
Ask n.p.m.mac; if the consensus is that no-one is attempting to keep the
Mac OS 9 build alive in any way, close them as INVALID.
> * I also regularly come across resolvable Camino bugs from the move from the
> the trunk from the 1.0.x branch. It also caused a lot of "regressions" and
> migration things without any official direction on how someone should file
> them.
I don't understand the problem. If the bug is in Camino now, leave it
open, otherwise close it.
Gerv
Chris Casciano
ge...@mozilla.org wrote on 5/16/03 7:57 AM:
As I stated in the original email these scenarios are in the past. I just
wanted to point out a few recent examples where I thought some guidance from
those that made the decisions/choices/changes up front would have eliminated
the time needed to feel things out or check with a newsgroup. A definitive
doc would also be useful to reference when closing/migrating these types of
bugs.
... and more to the point it would be nice if there was some similar doc
that bugzilla users could refer to when the upcoming changes form 1.4 ->
1.5a hit.