This leaves the question on what people would like to see done for the GitHub mirror I maintain.
I originally setup the mirror for 2 reasons:
Visibility of the package in the ecosystem just because GitHub is the defacto standard
Redundancy as GitHub and GitLab have historically had some issues in handling network traffic which affects people's ability to resolve their package dependencies.
(Now that SwiftPM handles caching of packages much better, #2 is no longer as much of an reasoning)
The options
I'd like people's thoughts on the following options
Archive the repo and no longer maintain it as a mirror
GitLab supports automated mirroring of git refs to external services, which is what I use for RediStack. Practically immediately after a git ref is pushed to GitLab, it's also pushed to GitHub so that branches, commits, and tags stay in sync.
However, issues, Merge Requests (Pull Requests), and releases are NOT synchronized.
This is coming up mainly for the following reasons:
Confusion of where to "contribute" to. I've had people file issues and try to open Pull Requests against the GitHub repo - even with issue/PR templates redirecting them to GitLab
As an extension of this, some packages rely on the GitHub repo as the source, while other packages rely on GitLab and I'm worried about any potential resolution errors that ideally wouldn't happen - but you never know
With me maintaining it as a mirror for visibility, I have to manually release versions twice (though this probably could be automated as well through CI)
Though as part of the manual release, I also fix up links that GitLab natively creates (much like GitHub does) into regular URL links and an automated release mirroring would still require editing the release notes or otherwise lose this for GitHub viewers
On GitHub, the "Insights" tab tells you some basic metrics about views and clones, so you can know if there will be any disruption to archiving the repository.
The issues you mentioned don't seem so great that they're worth ending the package's presence on GitHub. One of the goals of the community is to improve visibility for packages, and as you pointed out, GitHub is the defacto standard.
Of course, getting more visibility on the GitHub mirror isn't ideal, but the chances are that if you didn't have the mirror, they wouldn't discover the package at all.
How many developers would even go to look on GitLab for the second half of the list (would they expect them to have different packages?).
I am not considering moving back to GitHub as I find GitLab CI to be vastly superior to GitHub Actions, aside from the cloud macOS runner support.
In general, I don’t have any strong opinions on the options I’ve laid out - it’s just with the pending move I felt it appropriate to hear others thoughts.
It's a tough one this. Can you push to archived repos? That might stop issues/PRs
Hopefully over time we'll get more repos on GitLab and in the Swift Server Community GitLab repo to grow it. And things like the package collections and Swift Package Index should help address visibility issues.
I don't think putting the repo in the GH org will help, if anything it could drive more issues/PRs to the wrong repo. So I vote archive it as preference or leave it as is
Update: Given that RediStack 2.0 isn’t released yet, we can be more aggressive here: create a new branch that contains only README with deprecation note, make it default on GitHub, and retain the mirror until final archiving. This should give existing users enough time to migrate.
I would suggest soft-archiving — mark it as moved in description and README (not sure if it’s implementable because this need future pulls to be rebase), set up a bot to reject issues automatically.
And eventually, drop support by EOL of current major version (1.x).
This raised a question on how package authors can inform users of such migration. That’s a minor yet useful feature to bring to SwiftPM.
Thankfully GitHub will do the redirection for you. As long as the original URL has not been overwritten it will redirect to the new URL. For example https://github.com/swift-aws/aws-sdk-swift still links to soto even after 18 months. Ideally your clients would be using the correct URL though.
A general way to pass messages (eg migration, deprecation, upgrade) onto users would be a useful addition to SwiftPM.
Nope. Tried this earlier this morning and the server rejects any pushes:
ERROR: This repository was archived so it is read-only.
fatal: Could not read from remote repository.
Please make sure you have the correct access rights
and the repository exists.
This is interesting, and not something I'd considered!
Edit: The only downside that I've neglected to mention is that leaving GitHub entirely means losing support of being listed in Swift Package Index unless (or until) they support reading from GitLab as well. Last I knew, they only support GitHub hosted packages right now
There is also the long awaited package registry support from github. I wonder if the Swift on the Server working group could make an "official" inquiry about the status of that feature. There could be a future where you might have to host the registry on github but not the code.
I don’t think we should base anything on that possibility. We haven’t seen anything from GitHub or Apple about it in a year (I think?), so it doesn’t seem to be going anywhere. We should probably operate as if those proposals had never been accepted.
To be honest I'd argue to not mirror - it causes more confusion than help IMHO, and we instead need to promote RediStack harder using other means, including getting it recommended in SSWG which we can do if we get another maintainer (which is why the move to the org is happening anyway I believe).
With the swift.org site revamp coming up as well, we'll have a better and more easy way to promote libraries there as well, not just the "hidden away in the corner" list as we do now I'd hope (certainly was one of the goals of OSS ing the website).
Yes, this is possible and something I considered back when debating the move to GitLab in the first place - but I personally find GitLab better in most aspects over GitHub, but that’s more subjective than GitLab CI which is why I only mentioned it.
I still appreciate all these ideas, as it means people are invested in finding the best solution
Yes, the primary motivation for the move is to meet SSWG requirements.
Haha yes sorry I should have filled that out for a library already on GitLab and that requires contributions via GitLab the benefits of being on GitHub (a bit of extra potential visibility that hasn't been measured and that's it?) don't come close to the downsides, so I'm in favour of archiving and making it GitLab only
It can be measured, though. GitHub show you a repository's traffic statistics. You won't see all the network effects though.
Let's say I'm thinking about using Swift on a server, but I'm wondering if there's any good redis library. If I go to GitHub and type "swift redis", I won't find RediStack - or I'll see it archived at the search results page and think it's dead. And if I type "swift server" and find the community, I again won't see any mention of RediStack. I also won't be able to compare packages using typical engagement metrics such as stars and forks.
Yeah it's a bit of potential confusion for filling issues, and some tedious release note changes (which could possibly be automated), but is that really worth giving up your presence on the place where the entire rest of the Swift ecosystem lives? That's where the compiler and every other library in the toolchain lives. It's where the majority of the Swift project infrastructure lives (we're even right now finally ditching Jira and moving to GitHub Issues). That's where every first-party library - from Foundation and XCTest, swift-system, swift-atomics, swift-collections, swift-algorithms, swift-async-algorithms, etc, all live. It's where NIO lives, where the SSWG group repo itself lives, async-http-client, etc. It's where Vapor lives, including all of its 68 repositories.
I'd advise caution. People rely on GitHub more than they like to admit, and the whole idea of having a global community of developers who can all contribute to each others projects benefits from the same kind of massive scale that other social networks do. It wasn't this easy back in the days when everyone ran their own SVN servers and sent patches via mailing lists. But it's 2022, and just having an official mirror and presence on the world's biggest developer community and home of the Swift ecosystem is worth something.
