Hi, > and gitlab.com <http://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 <http://gitlab.inria.fr/> beside > the existence of an gitlab.inria.fr/eigen? <http://gitlab.inria.fr/eigen?> > > gitlab.com/eigen <http://gitlab.com/eigen> is already taken by someone else > (same for github) and gitlab.com <http://gitlab.com/> is kind of slow, but > those are minor compared to the advantages of the gitlab.com > <http://gitlab.com/> instance. I don't now how slow "slow" is but then I would definitely choose gitlab.com <http://gitlab.com/> over gitlab.inria.fr <http://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 <http://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 <[email protected]> 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 <[email protected]> wrote: > > > > On Thu, Sep 5, 2019 at 8:38 PM David Tellenbach > <[email protected] <mailto:[email protected]>> > wrote: >> 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 > > and gitlab.com <http://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 <http://gitlab.inria.fr/> beside > the existence of an gitlab.inria.fr/eigen? <http://gitlab.inria.fr/eigen?> > > gitlab.com/eigen <http://gitlab.com/eigen> is already taken by someone else > (same for github) and gitlab.com <http://gitlab.com/> is kind of slow, but > those are minor compared to the advantages of the gitlab.com > <http://gitlab.com/> instance. > > gael > > 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 >> <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 >> ------------------------------------------------------------- >> >> >> >
