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 > <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]> 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 > <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 > <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 > <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 > <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 > <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 > ------------------------------------------------------------- > > >
