Branching & tree mechanics for post Firefox 3.1 Beta 2
Mike Beltzner
At yesterday's Firefox/Gecko developers' meeting we discussed
branching options and tree mechanics for mozilla-central post beta 2.
Three issues were discussed, and I wanted to get more feedback and
input so we can make some decisions. Please feel free to comment on
any of the following:
1. Why branch & tree rules for the branch
2. When to branch
3. How to branch
// 1. Why branch & tree rules for the branch //
We've come to the time where we must narrow our focus aggressively,
taking only fixes that are critical to the success of Firefox 3.1. The
way we do this is by restricting the flow of patches which limits the
potential for regression, begins to slow the growth of the new testing
surface that must be checked by QA, and increases focus on the issues
that are on the critical path for release. (note: for Firefox 3 we
didn't actually branch as the "trunk" development simply moved over to
the new Mercurial repository.)
After we branch, tree rules for code that will become Firefox 3.1 /
Gecko 1.9.1 become stricter. To be accepted, a patch must:
- be reviewed (and superreviewed where required),
- include tests,
- fix a bug that has been marked as blocking-firefox3.1+ or
blocking1.9.1+,
- or be marked approval1.9.1+ by drivers
Note that these are the same rules that currently apply to the frozen
tree. As we move forward (probably after RC1) we can expect that we
will tighten controls even further such that only patches marked with
approval1.9.1+ will be accepted into the tree.
As always these rules do not apply to patches that are:
- not part of the Firefox build (NPOTB),
- test-only patches
The rules will also not apply to the trunk, which can remain more
flexible as work for the N+1 release begins.
// 2. When to branch //
The original proposal was to wait until we ship Firefox 3.1 Beta 2
(estimated Nov 21) to branch in order to prevent the number of double
landings required, on the assumption that we'll be spending now until
then fixing up topcrashes, functional regressions caught by testing
and QA, and slushy freeze landings, as well as the last of the l10n
work.
Stuart mentioned that this would adversely affect the mobile team who
need the tree rules to be flexible in order to get their changes for
Fennec completed. He requested that we branch earlier, at the point
where we cut our first builds for Beta 2 (estimated Nov 11). No
objection was raised, and so that's the current proposal on the table.
Boris recently wrote to dev.planning concerned that with the amount of
blockers left, branching now would cause undue pain in requiring
double-landings. That hadn't been raised as a concern at Tuesday's
development meeting, but if it's the case, it might affect the branch
date.
// 3. How to branch //
(note: a lot of this text was written with the help of Vlad, who
guided me through the pros and cons)
Once we branch, we'll need tinderbox and testing infrastructure to be
available both on the branch as well as the trunk. We'll also need to
adjust our documentation and process so that code changes are first
"baked" on the trunk (and ideally tested there) before then being
"ported" to the branch.
There are two proposals for how to branch, both with pros and cons:
A) Create a named branch within the mozilla-central repository (see: http://tinyurl.com/37js99)
B) Create a separate, cloned repository at the branch point (see: http://tinyurl.com/5jfe68)
/ 3.A Named branch
The advantages are that it is easier to uplift commits from the trunk
to the branch (as they are in the same repository) and it is simpler
to examine the history of the independent branches. Additionally,
future work is simplified as there is a single canonical repository
for the "mozilla" code base (including the few months of CVS history
we imported when we branched from Firefox 3) as opposed to requiring
many clones.
The disadvantages are that developers and the release engineering
group will need to do some work to figure out how to adjust their
processes and tools (such as Tinderbox and Talos) to work with named
branches within a single repository.
/ 3.B Cloned repository
The advantages of using a cloned repository are that it avoids
potential confusion when committing code; we've had some problems with
this in the past, though the particular circumstances are well known
and were most likely related to an older version of Mercurial being
used at that time. Additionally, the release engineering team has
stated that this is their preference, as it will be easier to modify
their tools (such as Tinderbox and Talos) to work with a separate
repository, as this is what they've had to do for l10n already.
The disadvantage of a cloned repository is that history essentially
diverges at the branch point; it's not possible to examine the history
of the branch at the same time as that of the trunk. In addition,
uplifting commits between the trunk and the 3.1/1.9.1 branch becomes
slightly more complicated.
/ Discussion
Vlad is in favour of named branches, as he feels it is the cleanest
approach going forward for the advantages stated above --
specifically, uplifting patches becomes much less painful, and things
like the try server won't need to be taught about new repositories. He
does state that should we go with cloning repositories, we should do
what dbaron suggested and ensure that the cloned repository has a
branch created there, so that if we decide to merge the repos in the
future we can do so.
jst and the release engineering team stated a preference for separate
repositories, both asserting that it would be simpler to do and allow
people to switch cleanly between working on trunk vs. working on
branch, at the cost of having uplift being more difficult and not
being able to examine history.
It was unclear what this choice would imply for the l10n repositories
(which are currently each independent repositories of mozilla-central).
cheers,
mike
Benjamin Smedberg
> // 2. When to branch //
>
> The original proposal was to wait until we ship Firefox 3.1 Beta 2
> (estimated Nov 21) to branch in order to prevent the number of double
> landings required, on the assumption that we'll be spending now until
> then fixing up topcrashes, functional regressions caught by testing and
> QA, and slushy freeze landings, as well as the last of the l10n work.
>
> Stuart mentioned that this would adversely affect the mobile team who
> need the tree rules to be flexible in order to get their changes for
> Fennec completed. He requested that we branch earlier, at the point
> where we cut our first builds for Beta 2 (estimated Nov 11). No
> objection was raised, and so that's the current proposal on the table.
>
> Boris recently wrote to dev.planning concerned that with the amount of
> blockers left, branching now would cause undue pain in requiring
> double-landings. That hadn't been raised as a concern at Tuesday's
> development meeting, but if it's the case, it might affect the branch date.
I have several large-ish changes planned for when the trunk reopens:
* nsQueryFrame (bug 396185) - changes layout frames to no longer inherit
from nsISupports... trivial but fairly conflict-prone changes to large parts
of layout
* Tree reorganization - I'm signed up to simplify the directory structure of
both content and layout.
Neither of these changes have to land immediately after branching (they
currently live in user repos), but I don't want to wait on them too far into
the next development cycle when merging with other incoming changes will be
more complicated.
> // 3. How to branch //
> A) Create a named branch within the mozilla-central repository (see:
> http://tinyurl.com/37js99)
> B) Create a separate, cloned repository at the branch point (see:
> http://tinyurl.com/5jfe68)
>
> / 3.A Named branch
>
> The advantages are that it is easier to uplift commits from the trunk to
> the branch (as they are in the same repository) and it is simpler to
> examine the history of the independent branches. Additionally, future
> work is simplified as there is a single canonical repository for the
> "mozilla" code base (including the few months of CVS history we imported
> when we branched from Firefox 3) as opposed to requiring many clones.
>
> The disadvantages are that developers and the release engineering group
> will need to do some work to figure out how to adjust their processes
> and tools (such as Tinderbox and Talos) to work with named branches
> within a single repository.
Is there a good description of what exactly will need to change?
mozilla-central already has multiple branches (at the request of release
engineering!) for alpha/beta minibranch releases.
I strongly prefer to use named branches for the long-lived branch if
possible... rebasing changes from the trunk to the branch becomes much
easier if the changes share a repository, and the likelihood of mistakenly
pushing central or branch changes into the "other" repo is greatly reduced.
Most importantly, however, all the viewer tools will show exactly where the
branch and trunk diverged, and will mark branch commits differently from
trunk commits.
> jst and the release engineering team stated a preference for separate
> repositories, both asserting that it would be simpler to do and allow
> people to switch cleanly between working on trunk vs. working on branch,
> at the cost of having uplift being more difficult and not being able to
> examine history.
In what way is separate repositories simpler? If you use a single
repository, switching between branches is a simple matter of `hg update -C
branch` or `hg update -C default`.
I understand there may be issues with release engineering tools, specifically:
* can the pushlog show pushes for only specific branches?
* can buildbot update to specific named branches without heavy customization?
I think the first can be solved pretty easily. The second I'm not so sure about.
--BDS
Karl Tomlinson
> repositories, we should do what dbaron suggested and ensure that
> the cloned repository has a branch created there, so that if we
> decide to merge the repos in the future we can do so.
IIUC, doing this would enable anyone (who chooses) to pull both
repositories into one local repository and have most of the
advantages of the named branch approach.
Axel Hecht
IMHO, we should note that we're already customizing the webtools quite a
bit, and could probably hack this support in, too, right?
That wouldn't work locally, granted, but still. Or maybe it could even
be hacked upon local setups.
>> jst and the release engineering team stated a preference for separate
>> repositories, both asserting that it would be simpler to do and allow
>> people to switch cleanly between working on trunk vs. working on branch,
>> at the cost of having uplift being more difficult and not being able to
>> examine history.
>
> In what way is separate repositories simpler? If you use a single
> repository, switching between branches is a simple matter of `hg update -C
> branch` or `hg update -C default`.
>
> I understand there may be issues with release engineering tools, specifically:
>
> * can the pushlog show pushes for only specific branches?
> * can buildbot update to specific named branches without heavy customization?
>
> I think the first can be solved pretty easily. The second I'm not so sure about.
pushlog can basically do anything, if we make it. It doesn't currently
support this, though.
buildbot source steps are likely not a problem either. We do run into
bigger problems on the level of hgpoller and change objects, though.
Currently, we use the branch in buildbot changes to denote changes from
different repos, with (your) hack for l10n to add additional properties.
Fixing this will likely introduce changes at a very low level of
buildbot. They're probably transparent in the way that the .locale hack
is, but they're not really the most stable thing in the world when it
comes down to upgrading buildbot.
Axel
Axel Hecht
I recall that a few months back there was the theory that fennec
wouldn't ship on code that we don't ship as Firefox, to benefit from the
security work there. Did we have to drop that theory?
Is there an example on why uplifting branches would be easier? I somehow
come to think that whether the branches in one repo or not, you need to
backport to branch point and then uplift to branch tip. At least that's
how I interpret it as soon as the repos drift apart that plain patches
don't apply anymore.
> jst and the release engineering team stated a preference for separate
> repositories, both asserting that it would be simpler to do and allow
> people to switch cleanly between working on trunk vs. working on branch,
> at the cost of having uplift being more difficult and not being able to
> examine history.
>
> It was unclear what this choice would imply for the l10n repositories
> (which are currently each independent repositories of mozilla-central).
I prefer separate repos. There's a bunch of code, locally and on the
l10n server, that's designed with the idea that we don't branch. The
releng stuff probably has the same challenge.
I wasn't happy with CVS branches, and I'm not sure we'll be much happier
with hg branches. I prefer a single place to get the code.
The relbranches are to me just a richer tag, not necessarily really
named branches.
Axel
Dirkjan Ochtman
> The disadvantage of a cloned repository is that history essentially
> diverges at the branch point; it's not possible to examine the history
> of the branch at the same time as that of the trunk. In addition,
> uplifting commits between the trunk and the 3.1/1.9.1 branch becomes
> slightly more complicated.
I feel that uplifting commits is only trivially harder for this case. We
do this a lot in the Mercurial project, where we keep our stable branch
in a separate repository. If you make your fix in the "stable" (3.1)
branch, you can trivially push-and-merge it into the development (trunk)
repository. If you have named branches, you do hg commit, hg up default,
hg merge stable. If you have a separate repo, you do hg commit, cd
../mozilla-central, hg pull stable, hg merge stable.
Also, I don't get the point that it's "not possible to examine the
history of the branch at the same time as that of the trunk".
> Vlad is in favour of named branches, as he feels it is the cleanest
> approach going forward for the advantages stated above -- specifically,
> uplifting patches becomes much less painful, and things like the try
> server won't need to be taught about new repositories. He does state
> that should we go with cloning repositories, we should do what dbaron
> suggested and ensure that the cloned repository has a branch created
> there, so that if we decide to merge the repos in the future we can do so.
Since there will be release (named-)branches anyway, I don't think you
need an extra named branches over and above those.
> jst and the release engineering team stated a preference for separate
> repositories, both asserting that it would be simpler to do and allow
> people to switch cleanly between working on trunk vs. working on branch,
> at the cost of having uplift being more difficult and not being able to
> examine history.
I think working in separate clones will also be less confusing for
committers. Additionally, for careful/advanced users, the repositories
can be kept in the same local repository anyway (but use push -r).
(All this assumes that stable will -- mostly -- be a strict subset of
trunk, which is what makes the most sense, and is the approach we use in
Mercurial.)
Cheers,
Dirkjan
Benjamin Smedberg
> IMHO, we should note that we're already customizing the webtools quite a
> bit, and could probably hack this support in, too, right?
It would not be simple at all... you'd be collecting data from two different
repositories.
> buildbot source steps are likely not a problem either. We do run into
> bigger problems on the level of hgpoller and change objects, though.
>
> Currently, we use the branch in buildbot changes to denote changes from
> different repos, with (your) hack for l10n to add additional properties.
Yes. However, the *revision* specified in the buildbot change would always
be on the correct branch. In terms of l10n changes, I think we could fix
this without any buildbot changes at all:
Poll http://hg.mozilla.org/mozilla-central/pushlog?branch=default : Change
objects would be:
revision - new default head revision
branch - 'mozilla-central-default'
Poll
http://hg.mozilla.org/mozilla-centrla/pushlog?branch=MOZILLA_1_9_1_BRANCH :
Change objects would be
revision - new branch head revision
branch - 'mozilla-central-1.9.1branch'
And if you have different masters for the 1.9.1 branch and for the trunk,
the only other buildbot issue is how it does periodic (i.e. no-Change)
pulls. The default buildbot.steps.source.Mercurial step, when a revision
isn't specified, just does `clone` without any arguments, when in fact we
want clone -rBRANCHNAME. But I think this is a very simple hack, and we
already patch this code in buildbotcustom.
If we wanted to run a single master that handled both trunk and branch
checkins, that would be a slightly more complicated affair, but I think it
is still doable with only a small replacement for the
buildbot.steps.source.Mercurial step.
--BDS
L. David Baron
> Mike Beltzner wrote:
>> The disadvantage of a cloned repository is that history essentially
>> diverges at the branch point; it's not possible to examine the history
>> of the branch at the same time as that of the trunk. In addition,
>> uplifting commits between the trunk and the 3.1/1.9.1 branch becomes
>> slightly more complicated.
>
> I feel that uplifting commits is only trivially harder for this case. We
> do this a lot in the Mercurial project, where we keep our stable branch
> in a separate repository. If you make your fix in the "stable" (3.1)
> branch, you can trivially push-and-merge it into the development (trunk)
> repository. If you have named branches, you do hg commit, hg up default,
> hg merge stable. If you have a separate repo, you do hg commit, cd
> ../mozilla-central, hg pull stable, hg merge stable.
We normally work the other way around, in that patches are required
to have landed on trunk (and been tested there for a few days)
before they are allowed to land on the release branch.
> Also, I don't get the point that it's "not possible to examine the
> history of the branch at the same time as that of the trunk".
The point I was really making is that a few years down the road,
somebody with a mozilla-central tree won't have the release history
of what was in version 3.1. They'd have to go pull a separate
repository to get that. I much prefer having it locally.
>> Vlad is in favour of named branches, as he feels it is the cleanest
>> approach going forward for the advantages stated above -- specifically,
>> uplifting patches becomes much less painful, and things like the try
>> server won't need to be taught about new repositories. He does state
>> that should we go with cloning repositories, we should do what dbaron
>> suggested and ensure that the cloned repository has a branch created
>> there, so that if we decide to merge the repos in the future we can do
>> so.
>
> Since there will be release (named-)branches anyway, I don't think you
> need an extra named branches over and above those.
I'm not sure what you mean by this. Could you explain? (The
suggestion I made was that if there is a separate repository, we
should issue the "hg branch" command so that the commits there show
up as a named branch in it, so that if we change our mind and want
them in mozilla-central later, they will still show up as being on
that branch.)
-David
--
L. David Baron http://dbaron.org/
Mozilla Corporation http://www.mozilla.com/
Dirkjan Ochtman
> We normally work the other way around, in that patches are required
> to have landed on trunk (and been tested there for a few days)
> before they are allowed to land on the release branch.
Hmm, I guess that could be sensible, but from the point of the revision
DAG it doesn't really make a whole lot of sense.
> The point I was really making is that a few years down the road,
> somebody with a mozilla-central tree won't have the release history
> of what was in version 3.1. They'd have to go pull a separate
> repository to get that. I much prefer having it locally.
You can just merge 3.1 into mozilla-central at regular intervals (or
when it's abandoned, or whenever, really).
> I'm not sure what you mean by this. Could you explain? (The
> suggestion I made was that if there is a separate repository, we
> should issue the "hg branch" command so that the commits there show
> up as a named branch in it, so that if we change our mind and want
> them in mozilla-central later, they will still show up as being on
> that branch.)
You could still merge them into mozilla-central later (and name the
branch at that point) without explicitly naming the branch now.
Cheers,
Dirkjan
Joshua Cranmer
> / 3.A Named branch
>
> The advantages are that it is easier to uplift commits from the trunk to
> the branch (as they are in the same repository) and it is simpler to
> examine the history of the independent branches. Additionally, future
> work is simplified as there is a single canonical repository for the
> "mozilla" code base (including the few months of CVS history we imported
> when we branched from Firefox 3) as opposed to requiring many clones.
Imagine five releases down the line, where mozilla-central will have the
history for five different release branches, three of which no one will
probably be using or maintaining. For casual developers who only care
about one branch, the repo will have the baggage of working with /every/
branch ever worked it, even those that are no longer supported. This
will be true unless both branch stripping is implemented and (key word
there) Mozilla adopts a policy of pruning old branches from the
repository once support is dropped for them. This is, at least in my
book, a very big disadvantage.
Benjamin Smedberg
> Imagine five releases down the line, where mozilla-central will have the
> history for five different release branches, three of which no one will
> probably be using or maintaining. For casual developers who only care
> about one branch, the repo will have the baggage of working with /every/
> branch ever worked it, even those that are no longer supported. This
Which repo? It is true that the hg.mozilla.org repository will have that
extra history. However, there is no reason a local clone would need to have
that history. You can simply clone only the default branch:
hg clone -rdefault http://hg.mozilla.org/mozilla-central
--BDS
Dirkjan Ochtman
> Imagine five releases down the line, where mozilla-central will have the
> history for five different release branches, three of which no one will
> probably be using or maintaining. For casual developers who only care
> about one branch, the repo will have the baggage of working with /every/
> branch ever worked it, even those that are no longer supported. This
> will be true unless both branch stripping is implemented and (key word
> there) Mozilla adopts a policy of pruning old branches from the
> repository once support is dropped for them. This is, at least in my
> book, a very big disadvantage.
Assuming the branches are kept as heads (and not merged back into
default), this is not true: you can just hg clone -rbranch
mozilla-central or even hg clone mozilla-central#branch.
Cheers,
Dirkjan
Ben Hearsum
> / 3.A Named branch
>
> The advantages are that it is easier to uplift commits from the trunk to
> the branch (as they are in the same repository) and it is simpler to
> examine the history of the independent branches. Additionally, future
> work is simplified as there is a single canonical repository for the
> "mozilla" code base (including the few months of CVS history we imported
> when we branched from Firefox 3) as opposed to requiring many clones.
>
Can someone expand on why it's simpler to examine history? I heard this
at the development meeting and I don't understand how that's the case.
In its current form, hgweb does not give you an easy way to only see
commits on a specific branch.
I would argue that cloning would make this clearer. The "firefox-3.1"
repository would only contain commits for Firefox 3.1 releases. These
would not show up in mozilla-central at all, and I believe that's a good
thing - especially when we get to stability releases.
> The disadvantages are that developers and the release engineering group
> will need to do some work to figure out how to adjust their processes
> and tools (such as Tinderbox and Talos) to work with named branches
> within a single repository.
>
If we go this route it is _extremely_ unlikely that we can branch the
same day we do en-US builds. The work here is mostly unscoped but as
Axel mentioned on the call today there is at least one major tool that
would need significant changes.
Another thing to consider is that many operations in Mercurial are
O(number of revisions). If we take this route commits to the maintenance
branch will add to the overall size of mozilla-central. I don't know
what the ratio of maintenance branch : trunk commits would be, but I
suspect the total number of maintenance branch commits would be
non-trivial over its life.
> / 3.B Cloned repository
>
> The advantages of using a cloned repository are that it avoids potential
> confusion when committing code; we've had some problems with this in the
> past, though the particular circumstances are well known and were most
> likely related to an older version of Mercurial being used at that time.
I don't think this can be understated. I can see "landing on trunk
instead of the maintenance branch" or visa versa being pretty common.
> Additionally, the release engineering team has stated that this is their
> preference, as it will be easier to modify their tools (such as
> Tinderbox and Talos) to work with a separate repository, as this is what
> they've had to do for l10n already.
There's actually no modifications to our infrastruture with this option
- it's a simple configuration change. (As opposed to an unknown amount
of code change.)
> The disadvantage of a cloned repository is that history essentially
> diverges at the branch point; it's not possible to examine the history
> of the branch at the same time as that of the trunk. In addition,
> uplifting commits between the trunk and the 3.1/1.9.1 branch becomes
> slightly more complicated.
I'm not sure why it's useful for the Firefox 3.1 maintenance branch to
contain history (forward history?) of post-Firefox 3.1 work.
> / Discussion
> and things like the try
> server won't need to be taught about new repositories.
The try server can already build from any Mercurial repo you give it.
> He does state
> that should we go with cloning repositories, we should do what dbaron
> suggested and ensure that the cloned repository has a branch created
> there, so that if we decide to merge the repos in the future we can do so.
>
If this means "clone to a new repository and do all work on a named
branch" this will be just as bad for us as doing a named branch in
mozilla-central.
> It was unclear what this choice would imply for the l10n repositories
> (which are currently each independent repositories of mozilla-central).
If we go the cloning route the cleanest thing to do (IMHO) would be to
create a firefox-3.1-l10n/ directory and clone the l10n repositories to
there. (Credit for that idea goes to whoever suggested it on the
developer call yesterday.)
To sum up:
I strongly feel that cloning is the right way to go. Many reasons are
above but the strongest one is that we already know how to do this. The
end of a release cycle is already a very busy time for Release
Engineering. It would very stressful, error prone, and probably delay
branching longer than we would like if we must figure out how to deal
with named branches during such a busy time.
I'm totally open to changing this down the road, but again, I strongly
feel that a week before we want to branch is _not_ the time to change
how we do things.
Of course, I realize that this decision can't solely be based on
RelEng's schedule and busyness, but as we are the ones who will be doing
most of the work I feel like we should have some influence :).
- Ben
Benjamin Smedberg
>> / 3.B Cloned repository
>>
>> The advantages of using a cloned repository are that it avoids potential
>> confusion when committing code; we've had some problems with this in the
>> past, though the particular circumstances are well known and were most
>> likely related to an older version of Mercurial being used at that time.
>
> I don't think this can be understated. I can see "landing on trunk
> instead of the maintenance branch" or visa versa being pretty common.
I can see making mistakes either way, and I'd hate to speculate which way is
likely to cause more mistakes... I think it's going to be very common for
developers who are backporting patches to pull both sets of history into a
common local repo in any case. This enables pain-free backporting:
Using named branches:
hg rebase -s revisiontoputonbranch -d MOZILLA_1_9_1_BRANCH
Using unnamed branches/repos:
hg rebase -s revisiontoputonbranch -d currentheadofmozilla191branch
In the latter case, when it comes time to push, the developer is going to
have to specify the exact revision to push, because he will have multiple
heads in his local repo and will only want to push the (unnamed)
mozilla191branch head.
>> The disadvantage of a cloned repository is that history essentially
>> diverges at the branch point; it's not possible to examine the history
>> of the branch at the same time as that of the trunk. In addition,
>> uplifting commits between the trunk and the 3.1/1.9.1 branch becomes
>> slightly more complicated.
>
> I'm not sure why it's useful for the Firefox 3.1 maintenance branch to
> contain history (forward history?) of post-Firefox 3.1 work.
It becomes very simple to perform backporting operations (using rebase) as
well as operations such as "compare the original commit of bug X with the
branch commit" to see if they matched.
But, as several people have said, you *could* do this locally by pulling
both repos into the same local space; the only problem is that the commits
don't have any identifying information, so it's hard to see which head is
the "branch head" and which is the "trunk head".
> I'm totally open to changing this down the road, but again, I strongly
> feel that a week before we want to branch is _not_ the time to change
> how we do things.
I'm surprised, actually: I thought that we added support for named branches
on mozilla-central precisely so we could do long-term branches there. I'm a
little surprised to learn that was not the plan. Not that it makes a big
difference at this point...
To resummarize then, the advantages/disadvantes are:
NAMED BRANCHES (in one repo or in two)
* Advantage: can easily identify which commits and history belong to what
branch, which makes rebasing and comparing branches a lot easier
* Disadvantage: requires some mostly-unscoped set of releng changes
SEPARATE REPOS with NO NAMED BRANCHES:
* Advantage: requires no releng infrastructure changes
* Disadvantage: requires developers who are rebasing patches or comparing to
pull both repos into a single tree, keep track of which head/history belongs
to which branch, and push only the correct head back to the correct central repo
--BDS
Axel Hecht
I'm not sure this is correct. I think the distinction is not so much
about named branches or not, but about independent builds within one
repo vs not.
In terms of scheduled builds, we currently totally ignore branches. That
might actually be a bug, though. Like, I would expect our builds to
actually kick off when pushing the relbranches.
In terms of release automation, I expect things to be a lot more
straightforward in that that would probably just take anything that hg
likes in lookup. But Ben had to confirm this.
Axel
Axel Hecht
Another item that I forgot to mention so far is the lack of an
equivalent of the frozen l10n modules we have on cvs/bonsai now. Those
turned out to be essential to have cooperative existance of several
projects with different tree rules on one repo.
No idea which way would be the easiest to bring this back to life.
Axel
Boris Zbarsky
> * nsQueryFrame (bug 396185) - changes layout frames to no longer inherit
> from nsISupports... trivial but fairly conflict-prone changes to large parts
> of layout
>
> * Tree reorganization - I'm signed up to simplify the directory structure of
> both content and layout.
Right. These were the sorts of changes that I was worried about making
landing on both branches (all 4 for security bugs!) a bit of a pain.
If we end up with a perl script or some such that could be used to
massage a m-c default branch diff into shape to land on the other three
branches by renaming the files in the patch, that could alleviate the
fallout from the tree reorg. I think we had something like that for
dbaron's layout reorg...
In any case, if you're willing to hold off on these for a week or two
after branch, and we do the same with other treewide changes, that would
probably significantly reduce the pain involved, at least assuming
people are on top of things and try to get as much stuff as possible
fixed as soon as possible. I would hope that immediately after branch
we're still focusing on 1.9.1 blockers.
-Boris
Dirkjan Ochtman
> * Advantage: requires no releng infrastructure changes
> * Disadvantage: requires developers who are rebasing patches or comparing to
> pull both repos into a single tree, keep track of which head/history belongs
> to which branch, and push only the correct head back to the correct central repo
If developers just have two local clones, I don't expect this to be much
of a problem. (But I maybe underestimating the unfamiliarity of many
developers with hg, again.)
Cheers,
Dirkjan
Benjamin Smedberg
> If we end up with a perl script or some such that could be used to
> massage a m-c default branch diff into shape to land on the other three
> branches by renaming the files in the patch, that could alleviate the
> fallout from the tree reorg. I think we had something like that for
> dbaron's layout reorg...
hg 1.1 (to be released in the next week probably) will make this a simple task:
hg rebase -s changesettoputonbranch -d branch-head-revision
> In any case, if you're willing to hold off on these for a week or two
> after branch, and we do the same with other treewide changes, that would
> probably significantly reduce the pain involved, at least assuming
> people are on top of things and try to get as much stuff as possible
> fixed as soon as possible. I would hope that immediately after branch
> we're still focusing on 1.9.1 blockers.
Yeah, I'm happy to wait for 1.9.1 stuff to basically finish. I just don't
want to get stuck competing with "new" layout work.
--BDS
Ben Hearsum
> Ben Hearsum wrote:
>
>>> / 3.B Cloned repository
>>>
>>> The advantages of using a cloned repository are that it avoids potential
>>> confusion when committing code; we've had some problems with this in the
>>> past, though the particular circumstances are well known and were most
>>> likely related to an older version of Mercurial being used at that time.
>> I don't think this can be understated. I can see "landing on trunk
>> instead of the maintenance branch" or visa versa being pretty common.
>
> I can see making mistakes either way, and I'd hate to speculate which way is
> likely to cause more mistakes...
Fair enough
> I think it's going to be very common for
> developers who are backporting patches to pull both sets of history into a
> common local repo in any case. This enables pain-free backporting:
>
> Using named branches:
>
> hg rebase -s revisiontoputonbranch -d MOZILLA_1_9_1_BRANCH
>
> Using unnamed branches/repos:
>
> hg rebase -s revisiontoputonbranch -d currentheadofmozilla191branch
>
Is it that much more difficult with separate repositories?
hg export somerev
cd otherrepo
hg import somerev
(Of course, this requires multiple clones.)
Ben Hearsum
> You could still merge them into mozilla-central later (and name the
> branch at that point) without explicitly naming the branch now.
>
If this is indeed true (and not a horribly pain inducing task) I don't
think there's _any_ reason not to do a full clone and revisit this when
we're not ramping up for a big release or blocking developers from
landing on trunk while we change up our infrastructure.
Ben Hearsum
> branch at that point) without explicitly naming the branch now.
>
If this is indeed true (and not a horribly pain inducing task) I don't
Benjamin Smedberg
> Is it that much more difficult with separate repositories?
> hg export somerev
> cd otherrepo
> hg import somerev
export/import don't do any merging, so see the issue above with bz: when we
move files around in layout/content (which will happen soon after branching)
patches from trunk won't apply directly to branch. However, rebase within a
single repository has the ability to track file moves.
Also, if there are any substantive changes between trunk/branch, rebase will
open a 3-way merge program to help the developer resolve things, while
export/import will just leave reject files scattered around.
You really do want to have both histories in a single repo for rebasing,
though we could probably live without doing that in the hg.mozilla.org repos.
--BDS
Robert Kaiser
> buildbot source steps are likely not a problem either. We do run into
> bigger problems on the level of hgpoller and change objects, though.
We should clear that in any case though, so that named release branches
as we already have don't create further problems in the future.
I don't actually see problems with named branches that we shouldn't
solve in any case as long as we're planning on doing named release branches.
Robert Kaiser
Robert Kaiser
> I prefer separate repos.
Does that include separate repos for all localizations? How well do you
expect localizers to be able to deal with that?
Robert Kaiser
Ben Hearsum
I am not a localizer but I do think that separate repos is a more
obvious distinction. It's easy to tell someone "hg clone
http://hg.mozilla.org/l10n-central/ab-CD" for Firefox .next and "hg
clone http://hg.mozilla.org/l10n-firefox-3.1/ab-CD" for Firefox 3.1.
Do we even take string changes on stable branches? I know we add new
localizations, but dunno about the former.
Axel Hecht
Yes, we do take l10n improvements on stable releases, too.
Which is the better scenario for really separate repos.
For new locales, it's going to be easier, too, as they don't have to do
funky things like starting their work on a named branch and then move to
default for the next upcoming or something similarily funky.
The concept of working branch against tip is something I tried back in
CVS days, and it led to more confusion still.
Axel
Mike Beltzner
we need to come to a decision, I just wanted to revisit what I've
heard to get confirmation and update with some proposals:
1. Why branch?
- nobody seems to disagree that a branch is needed
PROPOSAL: we're branching!
2. Branch when?
- BDS agreed to wait on some largish trunk changes for a few weeks,
which will help in terms of limiting divergence for the next little
while
- no significant objections to proposed date
PROPOSAL: branch date set for Nov 11th, 2008
3. Branch how?
- lots of pros and cons, back and forth
- releng is set up to use separate repos now
- l10n prefers separate repos as well
- seems like separate repos is easier for developers working on a
single branch, named branches easier for developers porting between
branches
- seems like whatever route we take, we can re-evaluate and change
branching strategies next time around
PROPOSAL: use separate repos for the 1.9.1 branch and see how it goes;
this allows quicker spin-up of build resources which we know will work
properly, and represents the smallest threat to the 1.9.1 shipping
date. We should pay attention to how it affects developers porting
between branches, and revisit the decision when we branch next.
Comments welcome!
cheers,
mike
Ben Hearsum
> PROPOSAL: use separate repos for the 1.9.1 branch and see how it goes;
> this allows quicker spin-up of build resources which we know will work
> properly, and represents the smallest threat to the 1.9.1 shipping date.
> We should pay attention to how it affects developers porting between
> branches, and revisit the decision when we branch next.
>
I probably don't need to say it but this WFM.
Ben Hearsum
Hi all,
We talked a lot about branching for Firefox 3.1 in the Platform meeting
today. There was also some discussion in the tracking bug
(https://bugzilla.mozilla.org/show_bug.cgi?id=464640).
To summarize:
* We will be branching ASAP.
* mozilla-central will be branched to
http://hg.mozilla.org/releases/mozilla-1.9.1
* l10n will be branched to
http://hg.mozilla.org/releases/l10n-mozilla-1.9.1/ab-CD
* As soon as these repositories are cloned RelEng will start bringing up
build infrastructure.
If there are no strong objections by tomorrow morning EST (approx 6am
PST, 2pm UTC) I will begin filing the bugs and preparing the patches to
get this done. I realize this doesn't give people much time to respond
but there in the name of getting it done quickly, this will help a lot.
- Ben
Axel Hecht
Are we going to get the pushlog db's copied over, too?
Axel
Ben Hearsum
I don't see why we shouldn't, so sure.