Re: [eigen] Bitbucket is dropping its Mercurial support!

Hi all,

I also think that migrating everything to one place is a great idea. I strongly favour GitLab over GitHub (GitLab just has so many more useful features useful for reviewing, bug-tracking etc., as me and many others have noted already). I would also favour GitLab.com over the INRIA instance, if we can get GitLab Gold on GitLab.com (I think we should, if memory serves me right, open-source projects get free Gold). Gold simply has a few essential features (like "Related issues" and other things Gael mentioned already).

Also I agree with the argument that more users would already have a GitLab.com account. Though it's worth noting that CMake have their own GitLab instance and they have many contributing users, I don't think having their own instance is a barrier for new users/contributors for them (also can't you log in to other GitLab instances using GitLab.com credentials?).

I can personally only see one reason against migrating issues from Bugzilla to GitLab: Eigen is a project that has lived for 15+ years (I actually don't know and couldn't find out when 1.x was released), and it will very like live another 15+ years. So we're thinking very long-term here. Who knows where GitLab will be in 15 years. Bugzilla may more likely still be here as it's fully open-source? The core of GitLab is open-source too, sure, but it's tied more to a company.

Though Bugzilla may have other issues - its last release seems to be from Feb 2018, which makes me wonder how active they still are in terms of critical fixes (particularly security-related problems).

In any case, I think GitLab is a good bet and it would well be worth it to have everything neatly in one place. If something does happen in 10 years or whenever, oh well, I am sure there will be a migration path then.

Best wishes,

Patrik

On Fri, 6 Sep 2019 at 00:24, David Tellenbach <david.tellenbach@xxxxxxxxxxxxx> wrote:

Hi,

and gitlab.com allows you to login using your bitbucket or github account.

I would very welcome this.

- gold should have way more features than the community edition but this is something we could check if necessary

yes, the community edition is lacking some welcome features, like:
- explicit relationships across issues,
- multiple approvers in code review
- reorder Issues in Issue Board List
- push rules

Do you see reasons to choose gitlab.inria.fr beside the existence of an gitlab.inria.fr/eigen?

gitlab.com/eigen is already taken by someone else (same for github) and gitlab.com is kind of slow, but those are minor compared to the advantages of the gitlab.com instance.

I don't now how slow "slow" is but then I would definitely choose gitlab.com over gitlab.inria.fr. We should find a suitable name for the repo such as eigen-official or whatever or could ask to get gitlab.com/eigen as Gustavo suggested (although I wouldn't know whom to ask). Reserving a name is actually something we can do right now.

On 5. Sep 2019, at 23:59, Yuanchen Zhu <yuanchen.zhu@xxxxxxxxx> wrote:

For issue/bug tracking and code review, at my company we have really enjoyed Phabricator for its tight integration of code review with inline commenting + issue tracking + freeform workboard. Phabricator also supports using a repo hosted externally, e.g., in github or bitbucket, and it has built-in integration with CircleCI (among others) based continuous integration. Back then we compared it to gitlab and github, and found its code review and workboard system to be vastly more usable and powerful. LLVM's huge C++ code base also used it for issue tracking + code review + workboarding.

Thanks for mentioning Phabricator which I really love since its platform agnostic and allows reviewing based on diffs and not on forks or branches. However, it's only free if self-hosted (that's what LLVM does) and each instance has it's own user base. Correct me i I'm wrong, but if you don't want to just copy diffs into a webform contributors have to use Phabricator's arcanist which is even more exotic for most people than mercurial. As much as I like it, from a practical point of view I find Phabricator to be a poor choice for Eigen.

David

On 5. Sep 2019, at 22:48, Gael Guennebaud <gael.guennebaud@xxxxxxxxx> wrote:

On Thu, Sep 5, 2019 at 8:38 PM David Tellenbach <david.tellenbach@xxxxxxxxxxxxx> wrote:
If we go with gitlab, then we have the choice of the gitlab instance, e.g.:
- gitlab.com with gold feature for free
- gitlab.inria.fr (it is running the community edition)

I have no personal objectives against the Inria gitlab instance. However some arguments pro gitlab.com:
- Addressing your pro github argument: People are less likely to have a gitlab.com account than a github.com account but far more likely to have a gitlab.com account than a gitlab.inria.fr account. gitlab.com would therefore be some kind of compromise between these three alternatives

and gitlab.com allows you to login using your bitbucket or github account.

- gold should have way more features than the community edition but this is something we could check if necessary

yes, the community edition is lacking some welcome features, like:
- explicit relationships across issues,
- multiple approvers in code review
- reorder Issues in Issue Board List
- push rules

Do you see reasons to choose gitlab.inria.fr beside the existence of an gitlab.inria.fr/eigen?

gitlab.com/eigen is already taken by someone else (same for github) and gitlab.com is kind of slow, but those are minor compared to the advantages of the gitlab.com instance.

gael

Thanks,
David

On 5. Sep 2019, at 16:57, Gael Guennebaud <gael.guennebaud@xxxxxxxxx> wrote:

Hi,

let's try to get a consensus on a few decisions.

Proposition 1:

Let's take this opportunity to migrate:
- code hosting (currently hg/bitbucket),
- bug tracker (currently bugzilla/self-hosted),
- pull/merge requests (currently bitbucket),
- code review (currently a mix of bugzilla/bitbucket),
- continuous integration (currently a mix of cron job, gitlab runners, etc. without ability to test PR)
to a *single* and *stable* "tool" hosted and maintained by a reliable third-party.
Here "tool" is either github or gitlab, and thus we also have to switch from hg to git.

-> Do we agree on this proposition?

If YES, then all it remains to do is to choose between github or gitlab (and then hack some migration scripts!).

github main pro:
- most users/contributors already have an account

gitlab main pros:
- more freedom/independence
- gitlab CI rocks:
- this make it a real all-in-one solution
- thanks to gitlab-runners anybody can easily share computing resources. I can myself dedicate two very powerful machines without VM overhead compiling Eigen's unit tests within a few minutes. That's a key feature if we want to automatically test PRs.
- part of the work is already done (e.g., gitlab-runners, bugzilla to gitlab)

gitlab main cons:
- the search engine for issues does not search within the comments yet. This is a very serious limitation, hopefully it'll be resolved soon, but the current patch proposal is exhibiting very serious performance issues with no clear solution: https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/24458

You can have a look at an initial attempt of migration of our bugzilla to gitlab there: https://gitlab.inria.fr/guenneba/eigen-bzmigration-test2/issues
Bug's ID are preserved, and it's only missing hash/link conversions from hg/bitbucket to whatever we switch for code hosting.
The migration script should not be too difficult to adapt to github if github ends up as the winner.

If we go with gitlab, then we have the choice of the gitlab instance, e.g.:
- gitlab.com with gold feature for free
- gitlab.inria.fr (it is running the community edition)

Gael

On Wed, Aug 21, 2019 at 3:54 PM Christoph Hertzberg <chtz@xxxxxxxxxxxxxxxxxxxxxxxx> wrote:
Hello Eigen users and contributers!

As some may have noticed, bitbucket/atlassian is "sunsetting" its
mercurial support:

https://bitbucket.org/blog/sunsetting-mercurial-support-in-bitbucket

If they stick to their timeline, we will have to migrate until June 1st,
2020. That means we still have time, but if we do nothing, things will
break ...

Converting the repository itself to git should not be a bigger issue --
and if we do this we could as well migrate to a more mainstream provider
(i.e., github).

I think the main problems for migration are:
a) Migrating open pull-requests (for historical reasons, the
closed/merged ones should probably be archived as well)
b) Fixing internal links inside commit messages ("grafted from ....",
"fixes error introduced in commit ...")
c) Fixing external links to the repository. Most notably, any links
from our bugtracker will eventually fail (even if we stayed with
bitbucket, the hashes won't match). I doubt that we could set up any
automatic forwarding for that.
d) Any third-party which relies on our main repository will need to
change as well (not directly "our" problem, but we need to give a
reasonable amount of time for everyone to migrate to whatever will be
our future official repository).

Smaller issues (relatively easy to fix or not as important):
e) Change links from our wiki (to downloads)
f) Change URLs for automated doxygen generation and for unit-tests
g) Automatic links from the repository to our bugtracker (currently
"Bug X" automatically links to
http://eigen.tuxfamily.org/bz/show_bug.cgi?id=X)
h) Change hashes in bench/perf_monitoring/changesets.txt

I probably missed a few things ...

I see essentially three options:
1. Migrate to another mercurial provider
2. Convert to git, stay at bitbucket
3. Convert to git, migrate to another provider

Honestly, I see no good reason for option 2. And the only real reason I
see for option 1 would be that it safes a lot of hassle with b) and h)
-- also perhaps it would simplify c) (e.g., we could easily crawl
through our bugzilla-database and just replace some URLs).

Any opinions on this? Preferences for how to proceed, or other alternatives?
Does anyone have experience with migrating from hg to git? Or migrating
between providers? Especially, also dealing with the issues listed above.
Does anyone see issues I forgot?

Cheers,
Christoph

--
Dr.-Ing. Christoph Hertzberg

Besuchsadresse der Nebengeschäftsstelle:
DFKI GmbH
Robotics Innovation Center
Robert-Hooke-Straße 5
28359 Bremen, Germany

Postadresse der Hauptgeschäftsstelle Standort Bremen:
DFKI GmbH
Robotics Innovation Center
Robert-Hooke-Straße 1
28359 Bremen, Germany

Tel.: +49 421 178 45-4021
Zentrale: +49 421 178 45-0
E-Mail: christoph.hertzberg@xxxxxxx

Weitere Informationen: http://www.dfki.de/robotik
-------------------------------------------------------------
Deutsches Forschungszentrum für Künstliche Intelligenz GmbH
Trippstadter Strasse 122, D-67663 Kaiserslautern, Germany

Geschäftsführung:
Prof. Dr. Jana Koehler (Vorsitzende)
Dr. Walter Olthoff

Vorsitzender des Aufsichtsrats:
Prof. Dr. h.c. Hans A. Aukes
Amtsgericht Kaiserslautern, HRB 2313
-------------------------------------------------------------