single repository for thunderbird
Currently Thunderbird uses code from two separate repositories: the
mozilla-central repostitory and comm-central repository. The
mozilla-central repository is checked out into the mozilla/ subfolder
using a script.
Earlier there were plans, and some work, to have a single repository for
Thunderbird. I'd like to revisit that topic now that we have a build
engineer, and could actually get this done.
Having the code split over two repositories has many drawbacks, and
earlier it was a constant cause of breakage for the build automation.
That breakage type is not as common as it used to be, but there are
other aspects that makes it much preferable to have just one repository.
Lately we have had a few cases where adding "special patches" on top of
mozilla-central has been discussed to address breakages. We don't have a
reasonable way to do that at the moment, and the only proper solution is
to use version control the way it's supposed to be used, and that does
not include using multiple repositories.
What would it bring us?
- Regression hunting can be done in a sane manner.
- We achieve a standard workflow - it's in general not a common setup
to have to run a script to check out source code. You should be able
to just hg pull and that's it. - Ability to really use version control to our needs. For instance, if
there's a feature we really need that mozilla-central drops, we can
choose to ignore that at least until we worked out a good
replacement. We don't firefight bustages all the time, we can to an
extent choose when to deal with what. - ... many many more sane behaviors
The ccrework bug is https://bugzilla.mozilla.org/show_bug.cgi?id=648979
The initial idea was to merge mozilla-central into comm-central, but I
think it would make much more sense do it the other way around: make
comm-central a branch of mozilla-central. That's also at large what
Thunderbird is, so it fits the spirit. So comm-central would be a branch
of mozilla-central, and periodically (as often as we want/can, daily at
least) that mozilla-central would be merged in to comm-central. It
doesn't require any scripting because this is a standard workflow that
hg (and git) support. You could easily locally do a merge from m-c tip
and see if it builds.
Having comm-central as a branch of mozilla-central also gives all people
involved with Firefox development an easy way to do a fix in
Thunderbird, should they want to. Currently it's a significant pain to
set up. Now it would just be pulling a branch. One command.
At the moment it's also harder than it needs to be for people to do
actual feature work on comm-central. We could also have a bookmark or
something that's a last-good-build. I'd point out that is not really
possible at the moment since m-c code has likely changed to be
incompatible with the new revision you're checking out, and your new
checkout won't build.
Where would the repository live? I'd suggest we map it to
hg.thunderbird.net but the repository could live wherever. Along side
with mozilla-central if the allow it. The repository location doesn't
really matter too much as you can easily have mozilla-central with
different set of branches in different repositories. Our would carry a
comm-central branch.
Comments?
-Magnus
On Mon, Nov 20, 2017 at 1:40 PM Magnus Melin mkmelin+mozilla@iki.fi wrote:
I'd like to revisit that topic now that we have a build engineer, and
could actually get this done.
I'm not going to comment one way or the other on the details of this
proposal. I'm already quite busy working on migrating the buildsystem to
taskcluster, and will probably be busy with it through till 59 branches, at
least. So I'm not going to devote any time to thinking about this until
then. In any case, if we decide to do this, it will be much easier once all
the build configuration is in-tree.
-- Tom
Yes it's been open question which of those should go first, or if it
makes sense to do them in one step.
One thing to keep in mind though is that if we don't do it before 59
ESR, backports will be much more difficult. And for 59 we may end up
desperately needing some removed features from mozilla-central...
-Magnus
On 20-11-2017 22:48, Tom Prince wrote:
On Mon, Nov 20, 2017 at 1:40 PM Magnus Melin <mkmelin+mozilla@iki.fi
mailto:mkmelin%2Bmozilla@iki.fi> wrote:
I'd like to revisit that topic now that we have a build engineer,
and could actually get this done.
I'm not going to comment one way or the other on the details of this
proposal. I'm already quite busy working on migrating the buildsystem
to taskcluster, and will probably be busy with it through till 59
branches, at least. So I'm not going to devote any time to thinking
about this until then. In any case, if we decide to do this, it will
be much easier once all the build configuration is in-tree.
-- Tom
----- Pôvodná správa -----
Predmet: [Maildev] single repository for thunderbird
Od: Magnus Melin mkmelin+mozilla@iki.fi
Pre: maildev@lists.thunderbird.net
Dátum: Mon, 20 Nov 2017 22:39:48 +0200
What would it bring us?
- Regression hunting can be done in a sane manner.
- We achieve a standard workflow - it's in general not a common setup
to have to run a script to check out source code. You should be able
to just hg pull and that's it. - Ability to really use version control to our needs. For instance, if
there's a feature we really need that mozilla-central drops, we can
choose to ignore that at least until we worked out a good
replacement. We don't firefight bustages all the time, we can to an
extent choose when to deal with what. - ... many many more sane behaviors
How would the speed of hg commands be in the new setup ? Currently, hg
qpuch, qpop, qref, are unbearably slow on m-c, but they are fine on c-c.
Would the revision history of our files be preserved when migrating as a
branch of m-c ?
Having comm-central as a branch of mozilla-central also gives all people
involved with Firefox development an easy way to do a fix in
Thunderbird, should they want to. Currently it's a significant pain to
set up. Now it would just be pulling a branch. One command.
Will Firefox devs have/can be prevented to have commit rights into our
files/branch?
Also we probably do not need commit access to the main m-c branch.
Other than these, I'm probably fine with the conversion if it helps
something.
I agree that this is a good idea to have a single repository. I had
proposed the same here before. I'm in favor.
Primarily, because it reflects reality:
-
A given c-c revision will only work with a specific m-c revision (or
revision range). Currently, this connection is not recorded mechanically
at all, the only connection is the time stamp. (This is what makes
bisect hard.) The purpose of a version control system is to have a
recording of history that can be played back at any time. Our current
setup really falls short there, but a merge of the 2 repos achieves that. -
TB started out as directories in the Mozilla tree, with mail/ on the
same level as browser/. This would make it easier again. I guess that
would also make the build system quite a deal simpler. -
We don't need the client.mk script.
Also, it allows organizational changes:
- Right now, if the is a breaking m-c change, c-c is just broken. Then,
Jörg does his fire fighting thing and runs around panicking, and needs
to commit fixes without review, to keep the tree building. That's an
insane process, and Jörg suffers from it. Our procedures also suffer,
see "post checkin review".
With the unified tree, we decide when to merge an m-c change. It doesn't
make any of the work easier, the amount of changes and the speed stays
the same. However, we are never in a broken tree state, and therefore
the hectic goes away. We merge the m-c changes once the TB bustage fixes
are done and reviewed.
-
That means you can check out at any time and the tree should always
build. That's the goal of CI, after all. -
We can now modify Mozilla code. That means when Firefox removes some
code that we our XUL extensions depend on, and we want to keep it, we
have now the option. We simply did not have this option before, even if
it did make sense. However, that option comes with a maintenance burden,
so it's not to be taken lightly.
However, it brings some dangers that we must avoid:
-
We slack and lag behind m-c by a week or more. This would mean that we
do not have the latest security fixes from Mozilla. Given that there are
2 critical security holes found every week, 1 week behind would mean
anybody who knows the holes can take over your computer and all
passwords and files on it. So, we still need to stay very close to m-c
and must not lag behind. Given that there is nothing forcing us anymore
technically, we must now make it a hard and fast organizational rule.
This cannot be overridden for any reason. Otherwise, we lose connection
and won't catch up. -
We make too many changes to Mozilla. Every change we make carries a
maintenance burden. The more code we touch, the more code breaks with
every upstream change. That means, the cost of a Mozilla change is not
only the cost of writing and applying and testing it now, but of
adapting it every time that the same function changes upstream. And
testing again. This cost will accumulate and eventually the weight will
crush us. So, this is a trade-off we need to make carefully.
Ben
Magnus Melin wrote on 20.11.17 21:39:
The initial idea was to merge mozilla-central into comm-central, but I
think it would make much more sense do it the other way around: make
comm-central a branch of mozilla-central. That's also at large what
Thunderbird is, so it fits the spirit. So comm-central would be a
branch of mozilla-central, and periodically (as often as we want/can,
daily at least) that mozilla-central would be merged in to
comm-central. It doesn't require any scripting because this is a
standard workflow that hg (and git) support. You could easily locally
do a merge from m-c tip and see if it builds.
Correct. That's the right way to do it.
Initial setup:
- You a local copy of the m-c repo.
- You make a branch "thunderbird"
- You add the mail/, mailnews/, calendar/, suite/ etc. dirs to the top
level, as siblings of widget/ etc. - You commit and push it to your copy of the repo.
- You adapt the build system
- You commit again
To update to the latest m-c:
- you merge m-c into your local repo. This updates branch master of
your repo. - You merge branch master into branch thunderbird.
(Optionally, the merge result is on a new branch of your choosing). - You commit it, but do not push it.
- You fix the bustage, and commit it.
- You push the merge and fixes to branch thunderbird.
On the topic in general, I am fine with merging, but really what you
need is buy-in from relevant folks and a good strong argument why things
are different now.
On 11/20/17 10:09 PM, ace wrote:
----- Pôvodná správa -----
Predmet: [Maildev] single repository for thunderbird
Od: Magnus Melin mkmelin+mozilla@iki.fi
Pre: maildev@lists.thunderbird.net
Dátum: Mon, 20 Nov 2017 22:39:48 +0200
What would it bring us?
- Regression hunting can be done in a sane manner.
- We achieve a standard workflow - it's in general not a common setup
to have to run a script to check out source code. You should be able
to just hg pull and that's it. - Ability to really use version control to our needs. For instance, if
there's a feature we really need that mozilla-central drops, we can
choose to ignore that at least until we worked out a good
replacement. We don't firefight bustages all the time, we can to an
extent choose when to deal with what. - ... many many more sane behaviors
How would the speed of hg commands be in the new setup ? Currently, hg
qpuch, qpop, qref, are unbearably slow on m-c, but they are fine on c-c.
It would be slow, as in m-c. hg watchman apparently speeds this up, but
for me it has just caused corrupt repositories so I live with the pain.
Would the revision history of our files be preserved when migrating as a
branch of m-c ?
I believe so
Having comm-central as a branch of mozilla-central also gives all people
involved with Firefox development an easy way to do a fix in
Thunderbird, should they want to. Currently it's a significant pain to
set up. Now it would just be pulling a branch. One command.
Will Firefox devs have/can be prevented to have commit rights into our
files/branch?
Also we probably do not need commit access to the main m-c branch.
With L3 access you have access to Thunderbird and Firefox. Note that
recently there was talk about taking away direct commit access from
Firefox developers, so that autoland would be the only option. This
would also apply to us.
On 20/11/2017 22:12, Ben Bucksch wrote:
With the unified tree, we decide when to merge an m-c change. It
doesn't make any of the work easier, the amount of changes and the
speed stays the same. However, we are never in a broken tree state,
and therefore the hectic goes away. We merge the m-c changes once the
TB bustage fixes are done and reviewed.
... reviewed. So four weeks later: That's absolutely deadly since we
will never catch up. As long as I can't get review within - say - six
hours, I need PLR to avoid a pile-up.
Jörg.
On Mon, Nov 20, 2017 at 2:13 PM Ben Bucksch ben.bucksch@beonex.com wrote:
- A given c-c revision will only work with a specific m-c revision (or
revision range). Currently, this connection is not recorded mechanically
at all, the only connection is the time stamp. (This is what makes
bisect hard.) The purpose of a version control system is to have a
recording of history that can be played back at any time. Our current
setup really falls short there, but a merge of the 2 repos achieves that.
There is some support for this already, you can set MOZILLA_REV in
client.py and it will checkout that revision of m-c. There is a similar
affordance in the taskcluster configuration. I've had it suggested to me
that we pin the revision, and setup a job that automatically bumps this
when m-c merges.
- TB started out as directories in the Mozilla tree, with mail/ on the
same level as browser/. This would make it easier again. I guess that
would also make the build system quite a deal simpler.
As part of migrating to taskcluster, I've switched to building things with
c-c checked out in a subdirectory of m-c, and it does make the buildsystem
easier, but we don't need to merge things to take advantage of this.
ace wrote on 20.11.17 22:09:
How would the speed of hg commands be in the new setup ? Currently, hg
qpuch, qpop, qref, are unbearably slow on m-c, but they are fine on c-c.
I know that's a "vi vs. emacs" question, but there's a simple solution:
git. git is fast, even on a large tree. (I'm presuming that you have an
SSD and lots of free RAM.)
In one project, we did almost exactly what's proposed here, with git,
and it works fine for us.
In our git repos, you even have the 1998 CVS history. See
https://github.com/mozilla/gecko-dev
https://github.com/mozilla/releases-comm-central
(the latter is c-c, with commits from a few hours ago, despite the name.)
That said, the change to git is likely to cause some push back by some
developers, so we should discuss git vs. hg separately and not here as
part of this question. I am just mentioning it to say that there is a
solution, if speed is a problem for you.
Would the revision history of our files be preserved when migrating as a
branch of m-c ?
Yes. You essentially merge 2 branches. The full history of both branches
is preserved. (Unless you are stupid and deliberately squash it.) So, if
you look at the history of a mail/ code file, you'd see its full
history, yes.
Also, all modern revision history systems track file moves.
Both answers above apply to both hg and git. In git, you should not
modify the file at the same time that you move it. You can, but it makes
it harder for git to find the origin, so better don't.
Will Firefox devs have/can be prevented to have commit rights into our
files/branch?
Also we probably do not need commit access to the main m-c branch.
This should be solved with a separate repository. I am presuming that
c-c and m-c say separate repositories, like today, even if c-c then also
contains m-c.
That takes care of the commit rights. It also solves the problem that
originally created this mess, namely that Firefox devs simply don't want
Thunderbird in their repo. If done like this, they won't. But we will
have m-c in ours.
Ben
Ben