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 < [email protected]> 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 <[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]> 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 >>> ------------------------------------------------------------- >>> >>> >>> >>> >> >
