Hello, If votes are opened to the full eigen community: Proposition 1: I agree Proposition 2: I would prefer gitlab.com or github.com Kind WT.
________________________________ From: David Tellenbach <[email protected]> Sent: Thursday, September 5, 2019 11:36 AM To: [email protected] <[email protected]> Subject: Re: [eigen] Bitbucket is dropping its Mercurial support! Hi, 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? I do! 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. This looks very promising! If we go with gitlab, then we have the choice of the gitlab instance, e.g.: - gitlab.com<http://gitlab.com/> with gold feature for free - gitlab.inria.fr<http://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<http://gitlab.com>: - Addressing your pro github argument: People are less likely to have a gitlab.com<http://gitlab.com> account than a github.com<http://github.com> account but far more likely to have a gitlab.com<http://gitlab.com> account than a gitlab.inria.fr<http://gitlab.inria.fr> account. gitlab.com<http://gitlab.com> would therefore be some kind of compromise between these three alternatives - gold should have way more features than the community edition but this is something we could check if necessary Do you see reasons to choose gitlab.inria.fr<http://gitlab.inria.fr> beside the existence of an gitlab.inria.fr/eigen?<http://gitlab.inria.fr/eigen?> Thanks, David On 5. Sep 2019, at 16:57, Gael Guennebaud <[email protected]<mailto:[email protected]>> 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<http://gitlab.com/> with gold feature for free - gitlab.inria.fr<http://gitlab.inria.fr/> (it is running the community edition) Gael On Wed, Aug 21, 2019 at 3:54 PM Christoph Hertzberg <[email protected]<mailto:[email protected]>> 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: [email protected]<mailto:[email protected]> 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 ------------------------------------------------------------- William Tambellini | Software Architect | SDL Los Angeles | [email protected] http://www.sdl.com Click here<https://www.mailcontrol.com/sr/d7jKkmjiOAfGX2PQPOmvUu5zZAYN1Mos0XPqT_salSIlwAbknsc5QuCLLjiNhGi3leXAjXoi-lhSWoTyPktGDA==> to report this email as spam.
