Host this fork on an alternative software forge #51
Comments
|
I agree. We should make the transition after we decide a name and logo |
|
If we do want to move off GitHub, which does make sense given the spirit of the project I don't think that sourcehut is a great option. Unlike a lot of code hosted on sourcehut, audacity is not really tech enthusiast focused making sourcehut not as great a place for this community. I think that gitlab is the best option as it provides built in CI unlike codeberg.org. |
Sourcehut has, by far, the best CI in the industry. You're able to ssh into failed builds and troubleshoot the problem. As with any sr.ht app, it's standalone, so you can connect it to Gitea, too. I suggest Codeberg + builds.sr.ht. |
Oh no sourcehut is great don't get me wrong and I would definitely use it if I could afford it, it's just not as beginner friendly |
Personally I'm fine with using GitLab as my main hosting right now but when I do get the chance I will probably move to sourcehut, and I'm very willing to pay when I can. |
|
We can consider moving our repository outside of GitHub, then asking GitHub to mirror it later on. Let's just actually get to writing code first, before we go around asking people for sponsorships. |
I fully agree with that statement; just throwing it out there before we become too dependent on GitHub. |
|
We should just avoid making decisions that will increase that dependency, such as depending on GitHub Actions and trying to move our CI elsewhere. We also need to keep up with Audacity's patches without the crash reporting. |
|
Additionally: Consider how we're going to move issues to an alternative software forge later down the line. |
I would like to bring up builds.sr.ht again. There's nothing like it -- it also has images for BSD and Plan9, and some projects already use it with GH. Pinging @ddevault, founder of sourcehut, who has given out free access to sr.ht for large projects in the past. |
|
We'd seriously appreciate any sort of help and I've actually looked at moving my own repositories on SourceHut (and still plan to do so), but I'd just think that it's way too early, considering we haven't gotten a basic set of contributors yet or chosen our name yet. It's a drastic change. I won't, however, rule out anything in the not-so-distant future, it's just that everyone's visiting this repository because it exists on GitHub. I think that I and others would love to hear such examples and I could also see a situation where, say, we'd accept patches on both platforms and mirror them on both platforms. |
|
But wow, Plan9 images... :D (Sorry, I'm an operating system nerd.) |
mrsh is a great example of a project that's
I'm sure there are projects which use Codeberg and mirror on GH in the same way. |
|
I'll keep it in mind. It's just that we currently have a huge influx of interested people coming on GitHub to find us. On the one hand, this project is being formed as a result of a protest that aligns with SourceHut's values and overall vibe (?). On the other hand, new contributors wanting to learn will probably be intimidated by SourceHut, I'll try to think of how we could possibly accommodate users on both platforms at the same time and how we could think about switching completely at a later stage if this takes off? But yeah, there's a lot of stuff to take care of right now. If we are to move, we should also provide documentation for SourceHut. It may seem like I'm postponing this indefinitely and just sugarcoating my words right now, but I'll try to influence future decisions so that our dependency on GitHub won't be as big. |
|
Of course. We have bigger problems now. |
|
Gitlab seems like the natural and easiest choice for me, and I think its the choice that will have the biggest approval from developers. |
Again, we shouldn't depend too much on GitHub. I'd assume that It'll work fine for now, though. |
|
Then a TODO.md file with checkboxes and links will do. (there is already todo.txt) |
|
I partially agree with arguments made by @SFR-git, @caughtquick, and @panos. So to clarify I cherrypick what I like and put them down here:
Regarding the target platform though, I would personally go in this order:
|
|
I would like to add that GitLab is open-core, not FOSS. Apart from the (much worse imho) UI/UX, it's functionally identical to GitHub and Gitea. Seeing as the point of my request is to move the project to an open platform, GitLab is instant DQ in my book. |
That leaves sourcehut as the only fully FOSS solution with built in CI/CD. If we do move to sourcehut I would hope that we stay mirrored to GitHub and allowing Issues and PRs on GitHub. |
Yeah, I guess we've reached a conclusion here. Does anyone have an additional perspective that should be added to this conversation? |
|
Considering the existence of platforms like Travis, CI/CD shouldn't be the main limiting factor. I think the UI/UX and attracting user engagement is a bigger factor to consider. Regardless, I think Codeberg is still a better choice. I have pinged Codeberg on Fosstodon and perhaps they know better and can provide concrete answers here. Let's also wait for them. |
|
I think the forge-specific discussion is better suited for when we decide to move. For now, I think the acknowledgement of GitHub's disadvantages is progress enough. Let's wait for Codeberg, ddevault, and other people's opinions on the matter. |
Not to mention @cookiengineer who has currently done most of the work for this project |
|
Please remember that we are seen as a more than ambitious attempt that doesn't have high chances of succeeding from the perspective of an outsider. "Forking a project is hard". We will appreciate all the help we can get. I'll try to look at things that will be needed later down the line (e.g. donations for hosting infrastructure? See #28.) |
Afaik GitLab CI is not a proprietary part, so if you self host an instance it would not be non-free. Alpine Linux and GNOME use (self hosted) GitLab for hosting and CI, for example. I don't know about GNOME, but Alpine Linux also receive contribution via (self hosted) sourcehut mailing list. I suppose self-hosting is not really viable at this stage, so you can use some existing instance. I'm not advocating for GitLab, though, just laying out the options here. |
|
In addition to @Huy-Ngo there are some FOSS gitlab instances like framagit.org which have CI. |
We also liked that name, but it's trademarked. :/ |
|
The US trademark? I checked, the only software-related one is scoped to HR-related services. Trademarks are specific to a specific product domain, so you're safe to use the name. |
|
I would say, whatever case may be, there should be a github mirror. |
|
The problem is cross platform CI. This is not easy to set up or maintain, but GitHub Actions does this for free. Unless someone volunteers to both set this up and maintain it long term by updating OSes and toolchains, I suggest staying with GitHub Actions. |
|
little hint, one Main Server, and let mirroring at the University's/ Data center's around the world, like Linux Distributions |
|
Isn't the whole point to get off of github? Better to start with a CI
tool that is not locked to a specific fordge. You can self host gitlab
CI and use with other fodges, I'd assume most of the other OSS CI tools
are simalar.
I would suggest looking at nix Hydra. Just for example.
…On Tue, 2021-07-06 at 15:28 -0700, Be wrote:
The problem is cross platform CI. This is not easy to set up or
maintain, but GitHub Actions does this for free. Unless someone
volunteers to both set this up and maintain it long term by updating
OSes and toolchains, I suggest staying with GitHub Actions.
|
I like builds.sr.ht as with some limited research it seems pretty good and is git host independent so we aren't locked in and don't have to rewrite our scripts if we are forced to move git hosts |
|
If we move to sourcehut or a similar forge we should archive this repository and make a notice instead of just deleting the repository. My biggest concern is that we already have a pretty sizable community here thanks in large part to github. Would github staff be able to remove the fork status? |
Suggesting services that don't support Windows and macOS is IMO not helpful in this case. |
This has been addressed
We will try to do something Also if we move to SourceHut this will probably be a mirror. |
|
Just a last comment from Codeberg: We will have a CI of some kind quite soon, and if we have a choice we don't want to use a solution that's mostly maintained by a for-profit as the only/preferred CI, but are open to offering our members as many options as possible - Gitea support in builds.sr.ht would be awesome. Compared to Git hosting at sr.ht, we are a completely community-maintained non-profit, and offer some additional features for organizations (like more fine-grained permission control). For us, it would be great to have you on board, but ultimately it's your decision - All platforms have their advantages and disadvantages and the most important thing is that the platform fits your need (and is FLOSS!). We therefore recommend that everyone who is willing to contribute checks out the options now, so you can make a decision based on what you are most comfortable with. We wish you all the best with your fork and trust you to make the best decisions for this project, so it remains free for the world! ✌️ |
|
If someone is willing to host build servers on Linux, macOS, and Windows, then I agree it would be great to move off of GitHub. But if you volunteer to do this, you should commit to either, preferably both:
Otherwise the project will get stuck waiting on you. I have been in that position waiting on the single person who has access to the build server and it really sucks. |
I'd say root access should be provided for the admins only and another account for the build server itself, maintained by a group of people |
|
Looks like there is a sourcehut project: https://sr.ht/~tenacity/tenacity.
source: https://tenacityaudio.org/ |
|
The Sourcehut looks very confusing. I don't know how to check the owner of the repo! The only thing I saw was that it was done 7 hours ago |
The owner of the repository is |
Sourcehut does not yet have a formal "Organization" structure. ~tenacity is a pseudo-org, managed by me (~sfr, sol@solfisher.com for any reason). |
|
Are there plans how to transmit the whole issues, pull requests and discussions to sourcehut? |
|
Let's do this formally. We're moving active development and development discussion to sourcehut. The Issues tab will be deprecated. AFAIK there's no way to transfer it to lists.sr.ht, and the mailing lists / IRC serve the same purpose. Discussions will be closed for the same reason. Here is a more detailed explanation: If you want to see an example of a project which handles things this way: mrsh. I'm closing this now -- feel free to continue the discussion on IRC or tenacity-discuss. Cheers! |
Discussions are ongoing about what should be done, feel free to participate by joining #tenacity on libera.chat |
|
Matrix users can participate at #tenacity:libera.chat (you'll need to register with NickServ!) |
|
Is there a way for SourceHut to get the status of macOS and Windows build jobs on GitHub Actions? If not, the build will break and it won't be known until after merging. |
|
@ddevault if that feature does not exist in SourceHut currently, it sure would make SourceHut a much more appealing option for cross platform projects. |
|
It should be quite possible through the sr.ht API, but the community will have to put together the necessary integration. As a general policy, sr.ht does not support integrations with proprietary software or platforms. |
|
Please submit opinion here: #155 |
|
It seems that the SourceHut repo has been abandoned in favor of GitHub despite SourceHut winning the election. (Srht primary, GH secondary) |
and others
Is your feature request related to a problem? Please describe.
It doesn't make sense to me that a fork, which was created to continue the FOSS spirit of a project, is hosted on a proprietary software forge like GitHub.
Describe the solution you'd like
Move the project to a site like Codeberg or sourcehut, and keep this around as a mirror.
I'm partial to sourcehut, an AGPL, JS-free forge, having used it for a couple of months and contributed to it, but it's different in the way it handles contributions, using mailing lists and
git send-emailfor patches. This workflow is leagues faster than PRs, but is difficult to get used to if you've worked with GH.If you want a GitHub experience, go with Gitea, specifically Codeberg.
Regarding email, though: it's safe to assume everyone has email, not so for GitHub accounts. Even if you decide to stay here, please set up a mailing list as to not block people out of contributing.
The text was updated successfully, but these errors were encountered: