On Sun, 10 Feb 2019 at 02:26, Eric F (iEFdev) wrote: > > I had this idea I want to test here. When creating a Portfile and adding: > maintainers - only GitHub is recognized when adding a username like > “@fooBar”. One *could* cheat and use: > > In Portfile: maintainers {GitHost:\ @fooBar} > With "port info": Maintainers: Email: GitHost: @fooBar > > > So, I was thinking it would be great with an optional syntax to be able to > add a couple of Git host services: GitLab and Bitbucket (= the 3 big ones), > so one could use something like: > > # just as a test to get the output: > In Portfile: maintainers @fooBar @gh:Foo @gl:Bar @bb:Baz > With "port info": Maintainers: GitHub: fooBar > GitHub: Foo > GitLab: Bar > Bitbucket: Baz
As Zero already explained, this wouldn't help in any way. We use the github handles for one single purpose: to be able to easily @mention maintainers (either manually or by the bot when someone else opens a pull request) and assign them tickets on Trac. Email is useful outside of github ecosystem and lets up easily contact the individual maintainers. Having gitlab, bitbucket, irc, twitter, facebook, linkedin, ... accounts in the Portfiles would not really serve any purpose. We do support fetching sources of various software from bitbucket and gitlab (improved / simplified support underway; Chris mentioned https://github.com/macports/macports-ports/pull/3510 for example), but that's orthogonal to what you are asking. > Are there any plans to expand to GitLab? Not that I'm aware of. I don't see any real benefit of using GitLab compared to GitHub, only lots of additional headaches brought by the migration. A while back the only benefit would have been the ability to use private repositories, now GitHub offers that functionality for free as well. GitLab offers some CI tools which are useless to us as there is no (decent) support for Macs anyway. In my opinion GitHub has a way more polished user experience and a few orders of magnitude more users, making it much easier to attract new contributors. I use a private installation of GitLab, and have an account on the public GitLab as well. With the first one we've been facing serious issues, in particular: - A slightly longer diff between commits would nearly crash your browser (maybe this has been improved in the meantime?) - When users have a slow internet connection, they are not able to clone some repositories due to some Unicorn web server thinking that connection timed-out while the clone was actively working; and the super helpful bot closed the bug report after X days due to lack of activity. With the second one I won a lottery ticket by registering username / org name @context (ConTeXt is an excellent typesetting system, LaTeX's cousin) and now I'm getting a zillion of useless spam messages every time someone hits a "reply" button in autogenerated emails from GitLab itself, as the footer contains something like {"@context":"http://schema.org","@type":"EmailMessage","action":{"@type":"ViewAction","name":"View Issue","url":"#1 (closed)"}} I'm not saying that everything about GitHub is perfect. In particular, the issue tracker is too limited, which made us decide to stay with Trac, which is certainly suboptimal. Another annoying misfeature is that you can only open and close pull requests via UI with one single identity. So if you are active in both MacPorts and another organisation, you can only pick up one default identity for online operations. > They have a great function to import/mirror from GitHub, which keep the repo > updated. If it would help anyone, we could gladly mirror the MacPorts sources on GitLab, but is there any real benefit to that? If anyone wants that, it's easy to set up, I just don't believe that this would really bring us any additional users or developers. I'm sure that having an account on SourceForge drives developers away; i cannot see that with GitHub just yet? > I know when everyone “fled” to GitLab last year… there were a few articles > how to intergrate the two. I don't remember though if it was possible to > manage PR/issues from one and sync with the other. Note that until relatively recently even GitLab itself had the main repository and all the issues on GitHub, for publicity reasons (because a lot more people were using GitHub). There might be various tools to help with migration, but if one is to judge based on GitLab's own migration, I'm not exactly impressed. I had at least one issue open in their GitHub tracker. When they migrated the project, they didn't leave notifications in their issues, so I was never notified about the move of the issue, and thus didn't get any link to the new location of the issue either. I managed to find the new issue after a pretty long search, it wasn't actually trivial, as the new issue isn't even indexed by Google and all google hits mostly lead to now broken links on GitHub. They only imported the description of the issue and skipped the full discussion that followed. In the new issue they posted a link to the old issue on GitHub, but they shut down their project on GitHub, and all issues were gone, so all the links to the old issues are now broken, loosing most of the history / discussion about the issues, and doing any search whatsoever nearly impossible. Just to make it clear: Despite all the issues listed above I'm super super super grateful that someone wrote very decent software like GitLab which one can install on a private server and it does the job relatively well compared to insanely overpriced GitHub in case you need it self-hosted (due to large files) for a hobby project only. It's just that I personally don't immediately see any benefit of switching to GitLab for MacPorts. (If they offered sufficient resources for CI on macOS, I might reconsider.) Mojca