Ryan Sipes wrote on 05.12.17 00:03:

I'm in favor of git. hg is posing a major barrier for new contributors.

hg is very similar to git, but still different enough to make people
trip. If you like hg and hate git, because git doesn't do what you want,
then you have an impression of how frustrated new contributors feel with
hg, because it's the same vise-versa.

git has now established as the de-facto standard of version
repositories. Even abandoned their own VCS and Visual Studio 2017 offers
to create a git repo together with a new project. Not that VS is a good
example, but rather the last bastion that git conquered: Everybody now
uses git, even more so open-source developers.

As for github, I do not want to rely on external infrastructure. But
given that git can make copies everywhere, I think we should have a copy
on github, while the authorative repo is hosted on our servers under our
control. Running a git server without frontend is trivial. I'm hosting
one myself, and I'm just a "hobby admin", so if I can do it, surely
Andrei can set it up in no time.

Ben

On 2017-12-04 6:20 PM, Tom Prince wrote:

I agree with this and to add to it, standing up a single VPS with git
installed is fine and all but it's not equivalent to Github or Mozilla
hosting. Github has a history of between 3 and 4 nines of
availability(99.9-99.99%), multiple data centers with failover, and lots
of other work done on systems. It's far more reliable, secure, and
guaranteed than anything that I can do with our current level of budgeting.

I prefer gitlab(or gitlab.com).

Hg is a big problem for new contributeur. But I don't think GitHub is best
choince for us.

If we relay on GitHub, there will be a vendor lock. There are many things
will cause some unaware risk.(If GitHub is down, if it doesn't support
public repo)

So, here is my propose:
If we have some high-quality server, network, we can run our gitlab
instance.
If we haven't, we can run at gitlab.com, And if gitlab.com changed, we can
migrate to our instance.

On Tue, Dec 5, 2017 at 12:02 PM, Andrei Hajdukewycz sancus@thunderbird.net
wrote:

--
Robert Lu robberphex@gmail.com
About me: http://about.me/RobberPhex

It's a justified question, but it's about more than just git or hg, it's
about the workflows to actually get the patch in tree. I think when
people argue that "git is more familiar" it's much about the github
flow, not so much about which source control system you're using.
Ultimately they are not that different.

Mozilla and Thunderbird has the workflow that you do your change, submit
the patch for review in bugzilla, and get it landed. Quite commonly for
projects on github your fork is actually that, a fork, that you could be
running for an extended time. This has very different from the situation
with Thunderbird, were you to create your fork and submit a pull request
for that.

Mozilla is also putting a lot of resources into streamlining this flow
with autoland plans etc., that will in time be integral parts of the
bugzilla workflow. Switching to git would make following this quite a
bit harder for Thunderbird. There is also the issue that the code base
(combined mozilla-central + comm-central) is too large to be allowed on
github (or bitbucket for that matter, both have a 2G limit), and using
their issue tracking is not sufficient for our needs - like hidden bugs
for security items. You might not realize it, but we (and Mozilla) are
really working through bugzilla much than anyone coming from the outside
could ever imagine. We're not abandoning that, it's the backbone of the
project.

Even setting the above points aside, it's not reasonable to use another
version control than mozilla, and having a git mirror is also just
problematic if you ask me. Having that choice is more confusion than
just having new contributors run a few commands in mercurial. Somehow I
don't buy that hg. vs git would actually be a major barrier to contribute.

 -Magnus

On 05-12-2017 01:03, Ryan Sipes wrote:

I agree with most of this.

On Thu, Dec 7, 2017 at 2:05 PM Magnus Melin mkmelin+mozilla@iki.fi wrote:

I don't think this is the common case; certainly most (maybe even all) of
the forks I have are to contribute to upstream projects.

One fact that mitigates this somewhat is that git integration is planned
for phabricator, so that contributors will be able to use git to interact
with the new code review tools.

This is definitely false. I know several prominent, skilled open-source
developers who have not bothered to make contributions (even easy ones)
because they can't be bothered to figure out or install a new version
control system. We want to make it easy for new people to start
contributing to Thunderbird; any hurdle we put in front of people means we
will lose some people before they actually start contributing. Certainly
once somebody has started contributing regularly, we can push them to start
using hg, but that shouldn't be the first hurdle they face. In any case,
even some Mozilla employees working on large firefox projects use git for
them, so why should we make it harder for a casual contributor to work on
thunderbird?

On 07-12-2017 23:50, Tom Prince wrote:

On linux, installing mercurial is maybe 30s and even on Windows, you'll set it
up in a few minutes. I'm sorry, but if 30s of your time is a major hurdle to
contribute, your contributions are not going to be considerable. For
comparison, setting up the build environment on Windows is a multi-hour effort
even on a fast machine and fast connection. Downloading the initial repos is
almost 3GB. I would think on the list of things blocking contribution, these
are more important hurdles, but of course not easily addressable.

Conversely, why should we make it harder for people working on Mozilla (and
used to hg) to contribute the off patches to Thunderbird?

With an assumption of the single source of truth, we're tied to whatever
Mozilla is using.

 -Magnus

Tom Prince wrote on 07.12.17 22:50:

In Phab, the process is:

1. arc branch foo -- creates git branch "foo"
2. git commit - commits changes locally
3. arc diff - sends your change to the Phab server and creates a
   "diff", with a web page
4. the reviewer sees the new diff and can comment on it, the review
   process goes. You get emailed about it, can reply etc..
5. You make code changes based on the reviewer's request
6. git commit and arc diff again -- it automatically finds and updates
   the existing diff.
7. The reviewer approves
8. You do "arc land" -- refreshes the local branch to master, merges
   the branch to master, and closes the "diff"

There's no need to upload files manually.

Agreed. hg is a major barrier. git is a very familiar tool for
everybody these days.

Between hg and git, the concepts are similar, but all the rest is
different. hg commands often do the inverse to what git does. E.g. "hg
revert" == "git reset HEAD^", "git revert" == "hg backout". "hg pull -u"
== "git pull", but "hg pull" == "git fetch". Once you know, it's simple,
but until you do, you are highly frustrated. The worst is when you try
to push your hg commit, but somebody else pushed right before you. Good
luck getting out of the "multiple heads" thing when you're new to hg.
It's a nightmare.

Why bother?

Everybody else uses git today.

Ben

Magnus Melin wrote on 08.12.17 06:55:

The install time is not the issue. Using it is. hg is as different from
git as Windows is from Mac. Similar concepts, but still hair-tearingly
different. If you're used to Mac, you'll just hate Windows. If you're
used to git, you'll just hate hg. If you demand people to do something
completely different than they are used to, a large part of them is not
going to be happy about it.

That's right. So let's please address those that we can address.

Do we have Mozilla employees contributing patches for us? A significant
amount?

Ben