1.9 trunk / 1.8 branch, or Firefox 2 / 3, tree management plan

classic Classic list List threaded Threaded
32 messages Options
12
Reply | Threaded
Open this post in threaded view
|

1.9 trunk / 1.8 branch, or Firefox 2 / 3, tree management plan

Brendan Eich
The proposed plan for handling the trunk and branch over the next year
is at http://wiki.mozilla.org/Global:1.9_Trunk_1.8_Branch_Plan.  There's
a FAQ at the bottom:
http://wiki.mozilla.org/index.php?title=Global:1.9_Trunk_1.8_Branch_Plan#A_Dialog.2C_or_FAQ.


I've set followup-to: mozilla.builds to try to get the benefit of a
single newsgroup with good signal to noise, but if people reply-all and
cross-post, it won't be the end of the world.

Comments welcome.

/be
_______________________________________________
mozilla-builds mailing list
[hidden email]
http://mail.mozilla.org/listinfo/mozilla-builds
Reply | Threaded
Open this post in threaded view
|

Re: 1.9 trunk / 1.8 branch, or Firefox 2 / 3, tree management plan

Justin Wood (Callek)
Brendan Eich wrote:

> The proposed plan for handling the trunk and branch over the next year
> is at http://wiki.mozilla.org/Global:1.9_Trunk_1.8_Branch_Plan.  There's
> a FAQ at the bottom:
> http://wiki.mozilla.org/index.php?title=Global:1.9_Trunk_1.8_Branch_Plan#A_Dialog.2C_or_FAQ.
>
>
> I've set followup-to: mozilla.builds to try to get the benefit of a
> single newsgroup with good signal to noise, but if people reply-all and
> cross-post, it won't be the end of the world.
>
> Comments welcome.
>
> /be

Thanks for the heads up, this addresses all my initial concerns after
reading the blog entry about FF2 being off 1.8 branch.

~Justin Wood (Callek)
_______________________________________________
mozilla-builds mailing list
[hidden email]
http://mail.mozilla.org/listinfo/mozilla-builds
Reply | Threaded
Open this post in threaded view
|

Re: 1.9 trunk / 1.8 branch, or Firefox 2 / 3, tree management plan

Robert Kaiser
In reply to this post by Brendan Eich
Brendan Eich schrieb:
> The proposed plan for handling the trunk and branch over the next year
> is at http://wiki.mozilla.org/Global:1.9_Trunk_1.8_Branch_Plan.  There's
> a FAQ at the bottom:
> http://wiki.mozilla.org/index.php?title=Global:1.9_Trunk_1.8_Branch_Plan#A_Dialog.2C_or_FAQ.

Two questions:
1) What's the tag for the 1.8.0.x branch?
2) Could stuff like SeaMonkey 1.0 (Beta + Final) get released from
1.8.0.x branch (with security releases coming off there later as well,
if needed) with still having SeaMonkey Council do approvals on
SeaMonkey-only code?

Robert Kaiser
_______________________________________________
mozilla-builds mailing list
[hidden email]
http://mail.mozilla.org/listinfo/mozilla-builds
Reply | Threaded
Open this post in threaded view
|

Re: 1.9 trunk / 1.8 branch, or Firefox 2 / 3, tree management plan

Brendan Eich
Robert Kaiser wrote:

> Brendan Eich schrieb:
>
>> The proposed plan for handling the trunk and branch over the next year
>> is at http://wiki.mozilla.org/Global:1.9_Trunk_1.8_Branch_Plan.  
>> There's a FAQ at the bottom:
>> http://wiki.mozilla.org/index.php?title=Global:1.9_Trunk_1.8_Branch_Plan#A_Dialog.2C_or_FAQ.
>
>
>
> Two questions:
> 1) What's the tag for the 1.8.0.x branch?


MOZILLA_1_8_0_BRANCH, of course (our major branches have a rationalized
name scheme that is over seven years old).  Nag/reminder: don't touch
this branch without approval.


> 2) Could stuff like SeaMonkey 1.0 (Beta + Final) get released from
> 1.8.0.x branch (with security releases coming off there later as well,
> if needed) with still having SeaMonkey Council do approvals on
> SeaMonkey-only code?


Mail drivers.  I'm ok with it so long as SeaMonkey-only is well-defined.
  There should be no new free lunches expected from Chase or other build
folks, however.

/be
_______________________________________________
mozilla-builds mailing list
[hidden email]
http://mail.mozilla.org/listinfo/mozilla-builds
Reply | Threaded
Open this post in threaded view
|

Re: 1.9 trunk / 1.8 branch, or Firefox 2 / 3, tree management plan

Brendan Eich
In reply to this post by Brendan Eich
Peter Weilbacher wrote:

> On Tue, 13 Dec 2005 02:04:19 UTC, Brendan Eich wrote:
>
>
>>The proposed plan for handling the trunk and branch over the next year
>>is at http://wiki.mozilla.org/Global:1.9_Trunk_1.8_Branch_Plan.  There's
>>a FAQ at the bottom:
>>http://wiki.mozilla.org/index.php?title=Global:1.9_Trunk_1.8_Branch_Plan#A_Dialog.2C_or_FAQ.
>
>
> Thanks, that makes a lot of sense to me.
>
> Two questions from me, too:
> 1. What do I do if I want a patch to land in 1.8 but it is not a
> crash/leak/dataloss kind of problem. Will there be an approval 1.8.1
> flag for attachments soon?

There should be, if not already, but:

> 1.a Or should I continue to abuse the blocking1.8.1 flag of the bug?


That's no abuse.  You need to get the *bug approved* before you should
ask for *patch approval* (but you may patch before either step!  Having
a patch in hand is a big plus for getting approval).


> 1.b Is there a Bugzilla/Webtool way to ensure that a bug that is not
> urgent enough for 1.8.0.1 doesn't get forgotten until 1.8.0.1 is out? Or
> do I have to keep my own todo list for this?


Anything approved for 1.8.0.1 should be approved for 1.8.1 too, unless
it is some kind of short term hack-fix.  In the past we've managed this
by request both approvals in the common case.  If that's too onerous,
I'd be surprised.  It gives the queryability you seek.


> 2. "We will extend CVS commitinfo and bonsai to automate synchronization
> of files between trunk and the 1.8 branch"
> Hmm, I can't really say that I understand this sentence. Will CVS
> commits within e.g. xpfe and browser automatically applied to 1.8 if
> checked into trunk and vice versa?


Only to those xpfe directories used by Firefox or Thunderbird.  We need
to sort out the details of this auto-sync'ing, so wait a few days and I
will have more to say.

/be
_______________________________________________
mozilla-builds mailing list
[hidden email]
http://mail.mozilla.org/listinfo/mozilla-builds
Reply | Threaded
Open this post in threaded view
|

Re: 1.9 trunk / 1.8 branch, or Firefox 2 / 3, tree management plan

Justin Wood (Callek)
Brendan Eich wrote:

> Peter Weilbacher wrote:
>> 2. "We will extend CVS commitinfo and bonsai to automate synchronization
>> of files between trunk and the 1.8 branch"
>> Hmm, I can't really say that I understand this sentence. Will CVS
>> commits within e.g. xpfe and browser automatically applied to 1.8 if
>> checked into trunk and vice versa?
>
>
> Only to those xpfe directories used by Firefox or Thunderbird.  We need
> to sort out the details of this auto-sync'ing, so wait a few days and I
> will have more to say.


SeaMonkey Council may want/desire the syncing as well, though I am
unsure how much work that entails, or if they would actually even want
it. ;-)

~Justin Wood (Callek)
_______________________________________________
mozilla-builds mailing list
[hidden email]
http://mail.mozilla.org/listinfo/mozilla-builds
Reply | Threaded
Open this post in threaded view
|

Re: 1.9 trunk / 1.8 branch, or Firefox 2 / 3, tree management plan

Brendan Eich-2
In reply to this post by Brendan Eich
Brendan Eich wrote:
> The proposed plan for handling the trunk and branch over the next year
> is at http://wiki.mozilla.org/Global:1.9_Trunk_1.8_Branch_Plan.


http://wiki.mozilla.org/Global:1.9_Trunk_1.8_Branch_Plan has been
updated to include a branching diagram:
http://wiki.mozilla.org/Global:1.9_Trunk_1.8_Branch_Plan#Branching_Diagram.

Myk is working on the CVS tooling, based on past work from shaver and
others.  More next week, when we know more.

/be
_______________________________________________
mozilla-builds mailing list
[hidden email]
http://mail.mozilla.org/listinfo/mozilla-builds
Reply | Threaded
Open this post in threaded view
|

Re: 1.9 trunk / 1.8 branch, or Firefox 2 / 3, tree management plan

Boris Zbarsky
In reply to this post by Brendan Eich
Brendan Eich wrote:
> The proposed plan for handling the trunk and branch over the next year
> is at http://wiki.mozilla.org/Global:1.9_Trunk_1.8_Branch_Plan.  There's
> a FAQ at the bottom:
> http://wiki.mozilla.org/index.php?title=Global:1.9_Trunk_1.8_Branch_Plan#A_Dialog.2C_or_FAQ.

I thought the plan was to make no changes (additions only) to core APIs
based on the pain we've felt in the past.  That plan seems to have
changed, somehow.  What happened?

-Boris
_______________________________________________
mozilla-builds mailing list
[hidden email]
http://mail.mozilla.org/listinfo/mozilla-builds
Reply | Threaded
Open this post in threaded view
|

Re: 1.9 trunk / 1.8 branch, or Firefox 2 / 3, tree management plan

Axel Hecht
In reply to this post by Brendan Eich
Regarding the approvals, I recall something like a feature-based
approval scheme for the 1.8 branch, is that still valid, or are we
sticking to a patch-based approval scheme?

I'm still blurry about how to cope with the branches on the l10n side.
I'm tempted to drop the trunk alltogether for the time being. I'm not
sure when it should kick back in, though, probably before a fx3 alpha.
But that doesn't appear on the roadmap at all. I'm afraid I need way
more details for a reliable planning.

Is the calendar file on steelgryphon for fx2 somewhat reliable, at least
in terms of the listed events? Then I'd bother whacking up some
l10n-specific deadlines for it.

Axel

Brendan Eich wrote:

> The proposed plan for handling the trunk and branch over the next year
> is at http://wiki.mozilla.org/Global:1.9_Trunk_1.8_Branch_Plan.  There's
> a FAQ at the bottom:
> http://wiki.mozilla.org/index.php?title=Global:1.9_Trunk_1.8_Branch_Plan#A_Dialog.2C_or_FAQ.
>
>
> I've set followup-to: mozilla.builds to try to get the benefit of a
> single newsgroup with good signal to noise, but if people reply-all and
> cross-post, it won't be the end of the world.
>
> Comments welcome.
>
> /be
_______________________________________________
mozilla-builds mailing list
[hidden email]
http://mail.mozilla.org/listinfo/mozilla-builds
Reply | Threaded
Open this post in threaded view
|

Re: 1.9 trunk / 1.8 branch, or Firefox 2 / 3, tree management plan

Benjamin Smedberg
Axel Hecht wrote:

> I'm still blurry about how to cope with the branches on the l10n side.
> I'm tempted to drop the trunk alltogether for the time being. I'm not
> sure when it should kick back in, though, probably before a fx3 alpha.
> But that doesn't appear on the roadmap at all. I'm afraid I need way
> more details for a reliable planning.

Why would we drop the trunk l10n? The build machinery is already there, why
not let localizers keep up to date if they wish? It would be nice for me as
we work on xulrunner+firefox to keep l10n repackaging up to date rather than
wait forever and discover problems at the last minute.

There has been unfortunate talk of taking new features on the 1.8.0 branch
that impact l10n, but I don't think that's a good idea: if we leave the l10n
1.8.0 (ff1.5) release tag static we can get localizers to focus on 1.8 and
trunk.

--BDS
_______________________________________________
mozilla-builds mailing list
[hidden email]
http://mail.mozilla.org/listinfo/mozilla-builds
Reply | Threaded
Open this post in threaded view
|

Re: 1.9 trunk / 1.8 branch, or Firefox 2 / 3, tree management plan

Axel Hecht
Benjamin Smedberg wrote:

> Axel Hecht wrote:
>
>> I'm still blurry about how to cope with the branches on the l10n side.
>> I'm tempted to drop the trunk alltogether for the time being. I'm not
>> sure when it should kick back in, though, probably before a fx3 alpha.
>> But that doesn't appear on the roadmap at all. I'm afraid I need way
>> more details for a reliable planning.
>
> Why would we drop the trunk l10n? The build machinery is already there,
> why not let localizers keep up to date if they wish? It would be nice
> for me as we work on xulrunner+firefox to keep l10n repackaging up to
> date rather than wait forever and discover problems at the last minute.

Right now, we don't have any builds for anything but the 1.8 branch.
Putting a branch into a "do whatever you whish" leaves that branch
(calling trunk a branch here for simplicity) in a completely unmanaged
state. I'm not eager to find out how to get it back to managed.
My biggest concern, though, is that quite a few localizers don't handle
branches and tree rules well. I'd rather kill an open branch than to
hunt down back-outs and post-landing-approvals on a daily basis.

> There has been unfortunate talk of taking new features on the 1.8.0
> branch that impact l10n, but I don't think that's a good idea: if we
> leave the l10n 1.8.0 (ff1.5) release tag static we can get localizers to
> focus on 1.8 and trunk.

Is there more than the "funny" search plugin removal UI there? If so, I
haven't heard about it, which is evil.

Note that we may have to open up the 1.8.0 branch to specific locales
for the more severe cases of bad localizations. It's not clear that we
can push back all of these for half a year. This is supposed to be
controlled and only sparse, but still.

Anyway, I don't think that setting up a branch for 40 locales is the
right thing to test one architecture cycle. I'm all fine if you try to
find one or two localizations that want to help out with tracking
fx+xulrunner, but opening this up to 40 seems to be distracting and
confusing only.

Axel
_______________________________________________
mozilla-builds mailing list
[hidden email]
http://mail.mozilla.org/listinfo/mozilla-builds
Reply | Threaded
Open this post in threaded view
|

Re: 1.9 trunk / 1.8 branch, or Firefox 2 / 3, tree management plan

Benjamin Smedberg
Axel Hecht wrote:

> Right now, we don't have any builds for anything but the 1.8 branch.
> Putting a branch into a "do whatever you whish" leaves that branch
> (calling trunk a branch here for simplicity) in a completely unmanaged
> state. I'm not eager to find out how to get it back to managed.

What's wrong with unmanaged? We don't require approval for trunk checkins,
so why don't we just allow localizers to continue daily localization of the
trunk if they want, and not if they don't? I don't understand how continued
trunk l10n could *hurt* anyone.

> Anyway, I don't think that setting up a branch for 40 locales is the
> right thing to test one architecture cycle. I'm all fine if you try to
> find one or two localizations that want to help out with tracking
> fx+xulrunner, but opening this up to 40 seems to be distracting and
> confusing only.

"open up"? The trunk has been open for months; *closing* it would be a
change. Chase turned off the trunk tinderboxen so that the branch boxes
would cycle faster when we were in the middle of the 1.5 release, but those
can (and should) be turned back on with the flip of a switch.

--BDS
_______________________________________________
mozilla-builds mailing list
[hidden email]
http://mail.mozilla.org/listinfo/mozilla-builds
Reply | Threaded
Open this post in threaded view
|

Re: 1.9 trunk / 1.8 branch, or Firefox 2 / 3, tree management plan

Brendan Eich
In reply to this post by Boris Zbarsky
Boris Zbarsky wrote:

> Brendan Eich wrote:
>
>> The proposed plan for handling the trunk and branch over the next year
>> is at http://wiki.mozilla.org/Global:1.9_Trunk_1.8_Branch_Plan.  
>> There's a FAQ at the bottom:
>> http://wiki.mozilla.org/index.php?title=Global:1.9_Trunk_1.8_Branch_Plan#A_Dialog.2C_or_FAQ.
>
>
>
> I thought the plan was to make no changes (additions only) to core APIs
> based on the pain we've felt in the past.  That plan seems to have
> changed, somehow.  What happened?


Bookmarks and history non-frozen APIs are candidates for breakage, given
the wins of the Places work.  The benefits outweigh the costs and I
think someone said some of the old APIs are too painful to emulate on
the new back end.

I'm not sure what interfaces will actually be broken, though.  Cc'ing
darin, who may be able to direct us to an updated wiki page or a better
venue than n.p.m.builds.

/be
_______________________________________________
mozilla-builds mailing list
[hidden email]
http://mail.mozilla.org/listinfo/mozilla-builds
Reply | Threaded
Open this post in threaded view
|

Re: 1.9 trunk / 1.8 branch, or Firefox 2 / 3, tree management plan

Brett Wilson
To clarify interface compatability for Places in 2.0:

Places will not support RDF, so RDF interfaces to bookmarks and history
will break. We considered writing an RDF wrapper, but it would be
difficult, have terrible performance, and little payoff. There seems to
be an overall trend of decreasing reliance on RDF anyway.

History APIs will be the same (except for RDF), with the addition of a
huge number of new ones.

Bookmark APIs will break, and there hasn't been much effort on
compatibility. The underlying model for bookmarks is changing to more
of a tagging approach where URLs are assigned to one or more folders
rather than having individual independent bookmarks, making
backwards-compatibility non-trivial. Changing over to use the new
bookmarks API should be straightforward.

There will be several new services with no compatabilioty issues.

_______________________________________________
mozilla-builds mailing list
[hidden email]
http://mail.mozilla.org/listinfo/mozilla-builds
Reply | Threaded
Open this post in threaded view
|

Re: 1.9 trunk / 1.8 branch, or Firefox 2 / 3, tree management plan

Boris Zbarsky
In reply to this post by Brendan Eich
Brendan Eich wrote:
> Bookmarks and history non-frozen APIs are candidates for breakage, given
> the wins of the Places work.  The benefits outweigh the costs and I
> think someone said some of the old APIs are too painful to emulate on
> the new back end.


Does "old APIs" here mean the frozen ones?  Because we MUST continue to
support them.  That's what it means for them to be frozen and all.

> I'm not sure what interfaces will actually be broken, though.

I've seen at least one patch floating around that changes the current
global history API in an incompatible manner (changes signature of a
method early in the vtable).  I haven't had time to look into whether
such a change is really needed yet, but I think we should be very
conservative about taking such changes on branch.

Then again, this is primarily an issue for embeddors, and I guess our
story for embeddors is to use the 1.8.0.x branch?

-Boris
_______________________________________________
mozilla-builds mailing list
[hidden email]
http://mail.mozilla.org/listinfo/mozilla-builds
Reply | Threaded
Open this post in threaded view
|

Re: 1.9 trunk / 1.8 branch, or Firefox 2 / 3, tree management plan

Boris Zbarsky
In reply to this post by Brett Wilson
[hidden email] wrote:
> Bookmark APIs will break

Does that include the XPCOM apis that core calls (and embeddors
implement)?  If so, I'm not incredibly happy about breaking them (though
see comments on 1.8.x vs 1.8.0.x in my previous post).

Frankly, I think that designing our core XPCOM apis (to be used by all
bookmark and history implementations built on top of Gecko) around the
particular bookmark and history setup we're doing for Firefox 2.0 is
short-sighted and dangerous.  If we feel that the bookmarks and history
impls are not getting enough information from the back end (which seems
to be the issue here), then we should try to get a list of relevant
information that should be passed on (this step is more or less
independent of the Places arch itself, though Places may suggest some
things that should be in the list), then design the APIs around that
(that is, see which information can't be gotten via existing APIs and
write new APIs to provide it).  Then do Places on top of the new API.

Designing the API around Places and only Places mostly means that if we
have a better idea a year or two down the line we'll need to make _more_
API changes.  And if some embeddor has a better idea, they simply won't
be able to implement it.

Again, I'm viewing all this from a Gecko standpoint.  I don't know
enough about the other end of bookmark and history APIs (the ones the
Firefox bookmark and history impls expose to the Firefox UI and Firefox
extensions) to comment on them intelligently.  But I do want a sane API
for Gecko talking to the bookmark and history impls.  At the moment,
that API consists of:

   nsICharsetResolver (on the bookmarks service)
   nsIGlobalHistory (FROZEN; very basic)
   nsIGlobalHistory2 (allows us to work with minor things like non-ASCII
                      URIs, notify history about redirects, handle page
                      titles, and store Gecko-specific per-URI flags).

The fact that this last is not frozen is highly unfortunate (see bug
234636).  I'd almost rather we froze it and put new stuff in
nsIGlobalHistory3, but I'd need to look up the specific changes we're
making to say for sure.

-Boris


-Boris
_______________________________________________
mozilla-builds mailing list
[hidden email]
http://mail.mozilla.org/listinfo/mozilla-builds
Reply | Threaded
Open this post in threaded view
|

Re: 1.9 trunk / 1.8 branch, or Firefox 2 / 3, tree management plan

Brett Wilson
In reply to this post by Boris Zbarsky
The only things that will definitely be broken by places at this point
are RDF (which is not an interface and therefore not frozen) and the
bookmarks service (which appears to be unfrozen).

_______________________________________________
mozilla-builds mailing list
[hidden email]
http://mail.mozilla.org/listinfo/mozilla-builds
Reply | Threaded
Open this post in threaded view
|

Re: 1.9 trunk / 1.8 branch, or Firefox 2 / 3, tree management plan

Benjamin Smedberg
In reply to this post by Boris Zbarsky
Boris Zbarsky wrote:
> [hidden email] wrote:
>> Bookmark APIs will break
>
> Does that include the XPCOM apis that core calls (and embeddors
> implement)?  If so, I'm not incredibly happy about breaking them (though
> see comments on 1.8.x vs 1.8.0.x in my previous post).

 From my discussions with Brett, the places work will not alter
nsIGlobalHistory2 on the branch.

Gecko doesn't deal with bookmarks at all, so we're "safe" there.
(nsICharsetResolver is or could be unchanged, from what I can tell.) In
fact, I don't think that places uses "nsIBookmarksService" at all, so we can
safely claim that we're not changing that API, we're just stopping
implementing it.

> Frankly, I think that designing our core XPCOM apis (to be used by all
> bookmark and history implementations built on top of Gecko) around the

History and bookmarks are different in this case: history is called by gecko
and therefore requires intense cooperation between gecko and the embedder,
while bookmarks doesn't.

>   nsIGlobalHistory2 (allows us to work with minor things like non-ASCII
>                      URIs, notify history about redirects, handle page
>                      titles, and store Gecko-specific per-URI flags).
>
> The fact that this last is not frozen is highly unfortunate (see bug
> 234636).  I'd almost rather we froze it and put new stuff in
> nsIGlobalHistory3, but I'd need to look up the specific changes we're
> making to say for sure.

There have already been changes to nsIGlobalHistory2 on the trunk after 1.8
branched. I don't like it either, because I wanted to freeze it for 1.7, but
that ship has sailed.

--BDS
_______________________________________________
mozilla-builds mailing list
[hidden email]
http://mail.mozilla.org/listinfo/mozilla-builds
Reply | Threaded
Open this post in threaded view
|

Re: 1.9 trunk / 1.8 branch, or Firefox 2 / 3, tree management plan

Boris Zbarsky
Benjamin Smedberg wrote:
 > History and bookmarks are different in this case: history is called by
 > gecko and therefore requires intense cooperation between gecko and the
 > embedder, while bookmarks doesn't.

Except that with Places bookmark UI design decisions are affecting the proposed
history APIs, as far as I can tell.  So I stand by my point.

-Boris
_______________________________________________
mozilla-builds mailing list
[hidden email]
http://mail.mozilla.org/listinfo/mozilla-builds
Reply | Threaded
Open this post in threaded view
|

Re: 1.9 trunk / 1.8 branch, or Firefox 2 / 3, tree management plan

Benjamin Smedberg
Boris Zbarsky wrote:
> Benjamin Smedberg wrote:
>  > History and bookmarks are different in this case: history is called by
>  > gecko and therefore requires intense cooperation between gecko and the
>  > embedder, while bookmarks doesn't.
>
> Except that with Places bookmark UI design decisions are affecting the
> proposed history APIs, as far as I can tell.  So I stand by my point.

It is silly to expect that the UI design would not affect the APIs... what
exactly do you expect to be done differently? Trying to design "universal
APIs" to anticipate every future need does not seem reasonable or cost
effective.

--BDS
_______________________________________________
mozilla-builds mailing list
[hidden email]
http://mail.mozilla.org/listinfo/mozilla-builds
12