On Thu, Sep 5, 2019 at 8:38 PM David Tellenbach < [email protected]> 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 <[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 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 < > [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] >> >> 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 >> ------------------------------------------------------------- >> >> >> >> >
