RFC: Sourcehut migration

[Semisol]

This post is only advisory on the decision to migrate.

As discussed in #51, there has been thoughts about migrating to Sourcehut. I would like to request opinion from the community.

Please respond to this issue with the following comment format:

I am in favor of option 1/2/3/4/5.

<insert reason>

Options for migration:

1. Full We abandon GitHub and move to Sourcehut
2. Sourcehut primary, GitHub secondary We will accept PRs and issues from GitHub, but mainly Sourcehut will be used. GH will be a mirror.
3. None We will stay on GitHub and Sourcehut will not be used except for mailing lists and other misc stuff.
4. GitHub primary, Sourcehut secondary We still continue to work as normal on GitHub, but Sourcehut can be contributed to. Sourcehut will still be primary on mailing lists and other features GH doesn't have.
5. Something else This option is for if you only want to move to another forge, partially or fully.

We recommend you read all the comments before responding.

[nkeor]

I'm in favor of option 1. If not, option 2.

[unbeatable-101]

I am in favour of 5, if we are going to move the primary repo from github, I suggest Codeberg. It will allow us to easily replicate most github functionality, so we could completely move away from it if that is what is wanted.

To expand on this, sourcehut isn’t as easy to learn how to use, so if we want to have more people contribute then it needs to be something similar to GitHub. As far as I know Codeberg fixes most of the concerns people have about GitHub.

It has less JavaScript (does it have javascript?).

It has javascript, but not much breaks if you disable it.

[caughtquick]

I'm in favor of option 2, though option 4 isn't bad.

[raavan13]

I would suggest Option 2

This will also be helpful for ppl who are not willing to leave GH and join SH for just this. I have accounts on both, so it doesn't affect me, but I would like his project to got to SH also.

[Seirdy]

Full disclosure: I am not an {Aud,Ten}acity contributor...yet. I've used it for a few years. Take this with a grain of salt. Despite that fact, I'm writing this partly because Tenacity could be an influential project, so other projects might follow its example.

Ranked choice (descending order): 2, 4, 5 (opt. 5 being a Gitea-based remote such as Codeberg or TildeGit). For the purposes of vote-tallying, consider this a vote for option 2.

If someone capable and trustworthy is able+willing to self-host, that's also an option.

Whatever option gets chosen, I'd like to suggest a Hydra Hosting approach. Hydra hosting (many remotes pushed/pulled to/from in parallel with a git alias) grants great hosting resilience with almost no additional effort, but it doesn't cover issue-tracking, support, or patch-submission; the choice of "primary" location should reflect these things.

As using GitHub comes with some ethical concerns for me and others in the Free Software community (e.g., much functionality requires enabling nonfree JS), and it requires creating an account (typical account-based service -> network effect -> vendor lock-in -> harder to leave if/when GH does something bad) to do anything beyond "read-only". It might be worth giving extra weight to ethical concerns like this because Tenacity was born out of very similar ethical concerns; the problems with Audacity apply to GitHub itself to a greater degree.

GitHub can be an option for existing users in the interests of making contribution more approachable, but I'd rather not make it the "default".

[mmmaisel]

I am in favor of option 3 or 4.

[Digit]

hi, audacity user for >17(?ish) years for all main stuff, will stick around (probably wont be much use though). long live tenacity.

I am in favor of option 1 or 5.

if not, prioritize away from gh.

5s: e.g. notabug.org, self hosted gitlab/gitea or whatever... idk, whatever is found best suitable for the project's ongoing freedom, after considering all the options. something on federated githosting would seem ideal. something activitypub backed? idk, just an idea. but if 1/sourcehut's good to go for tenacity, sourcehut.

[petersanchez]

Option 2 is the best choice here.

[dhocker]

Here's a suggestion to ponder before you make a decision on what to do with the existing repo.

The owner/leader of this project/repo should start a priority list of everything everyone wants to do. Order the priority list according to the value returned by an item (#1 yields the most ROI). Draw a cut-line at the point where items above the line are being worked on and items below the line are not being worked on (bandwidth limited). When a new item comes along, sort it into the list. Move the cut-line as necessary.

I don't have any idea what a priority list for this project might look like. But, I suspect that if you sort the item "move to a new source host" into such a priority list you might find that it is below the cut-line. I say that because the source host really doesn't return much value to the target user. It mostly returns value to the developers. To get such an item above the cut-line you would have to establish that there are other higher priority, more valuable items on the list that can't be accomplished without it.

If you make such a priority list you will likely find that there are many work items that have to be done just to move from the old Audacity repo to the new Tenacity repo. All of these items will meet what is known as the "must do" criteria, so they will be above the cut line (e.g. changing every occurrence of Audacity to Tenacity). Anything that does not meet the "must do" criteria will automatically get pushed down the list.

Just a thought...

Sorry...forgot to vote. This was really a recommendation for #3.

[Songtech-0912]

Latest Results

Alright, I'm back to doing the tally:

• Option 1: 4.75
• Option 2: 11.5
• Option 3: 3
• Option 4: 7.5
• Option 5: 3.75

(Note - for second and third choices I added 0.5 votes and 0.25 votes respectively)

[Semisol]

@dhocker thanks for the idea, marked offtopic though. we will consider

[Flyingmana]

Voting for primary 4, secundary 3.

Reason:

• Using Github is comfortable, keeping track of created Issues, done PRs, subscribe to single issues/changes to keep track of PR progress.
• Also good searchability and transparency.
• good CI integration
• providing many features related to delivery
• easier validating/Authentifikation of contributors by provided authentification with possible 2FA and easy validating of signed commits

Reason against sourcehut:

• using email to send patches is very uncomfortable and has lead to a few cases where I did need to resent patches, because of encoding issues
• I had bad experience, with submissions gotten lost and not receiving any feedback in the amount of other mails the maintainers had to handle.
• authorship of emails can easy be spoofed?
• it increases the hurdle for initial contributions high enough, that its likely to loose a lot of drive-through submissions. (for one of the projects I maintain, this drive through contributions make up more then 2/3 of all contributors https://cauldron.io/project/4125?from_date=2011-07-08&to_date=2021-07-08&tab=chaoss

[le-codechetif-blanc]

A self-hosted GitLab instance might also be a good idea- such as https://git.kiwifarms.net

[dhocker]

I vote for #3. See previous comment (that was removed as off-topic) about needs for a priority list to understand why I vote for #3.

[Semisol]

I vote for #3. See previous comment (that was removed as off-topic) about needs for a priority list to understand why I vote for #3.

(not removed, but marked)

[bl-ue]

When we finally take all the votes and make a decision, we should probably take 1 and 2 together and 3 and 4 together as they're very similar. 1 and 2 prefer Sourcehut, 3 and 4 prefer GitHub.

[Songtech-0912]

Let's take in all the votes once we've gotten the votes of 40 contributors, and then I'll make another tally. I believe the votes of 40 contributors are close enough to represent the general wishes of the community

[Be-ing]

Why is it a bad reason to want to lower the entry bar to new contributors and developers, some of which might not be as tech savvy as the core team?

I don't think trying to lower the barrier to entry to bad. I think it is important to pick a tool that is approachable for newcomers, so I think SourceHut is not a good choice. What I meant before is that I think making a decision to use a tool merely because everyone else does is not a good basis for that decision.

[Be-ing]

I think this voting is premature to make a final decision. The options haven't been discussed very thoroughly.

It seems few are really happy with GitHub, but we put up with it.

Considering nobody has presented any alternative proposals for cross platform CI, proposing to move exclusively to SourceHut is effectively proposing to drop macOS and Windows support, so I think that's out of the question.

As for GitLab, politically, I consider it only a little better than GitHub because it is owned by a private company heading for an IPO which has already demonstrated a willingness to work with fascists and has an anti-community open core business model. Practically, GitLab.com CI macOS Runners are in beta and so are Windows runners.

Gitea I think deserves more discussion. Its design is very similar to GitHub but it is a community project, not some corporate open core thing like GitLab. AFAIK the only cross platform CI that works with Gitea is AppVeyor, which only provides one job at a time for free. Speaking from experience, that's not adequate for an active project. GitHub Actions is much more generous with computing resources, allowing up to 20 concurrent jobs (or max 5 concurrent macOS jobs). Some compatibility with GitHub Actions is on the Gitea roadmap, so I think it could be feasible in the future to move from GitHub fully to Gitea.

[SethFalco]

I favor option 5, then 4.

I think GitLab would be nice to use:

• Stable
• Continue Integration
• Self-Hostable
• Open-Source (Unfortunately, it's open-core though, similarly to Bitwarden. So, not 100% open-source like other solutions.)

Overall, I'm not too fussed where it is so long as people can contribute easily, though.

I do think it'd be nice to keep the project on GitHub one way or another (primarily, just for PRs, or even as a read-only mirror) just so it's easy to find for people that look for projects here. (ie via topics)

[Be-ing]

Provided that the beta macOS and Windows shared runners work well, I think GitLab.com would be the best option at this point. That leaves open the possibility of moving to self-hosted GitLab or Gitea (self-hosted, Codeberg, or some other host) in the future.

[Songtech-0912]

I think this voting is premature to make a final decision. The options haven't been discussed very thoroughly.

I think most contributors agree with this sentiment. However, in the absence of a true governance structure, voting is a good way to find the general positions of the community - after the vote is over (at 40 contributors) I can write a full breakdown and summary of the vote results, including ideas placed forward by the community. Overall, I believe we should take a max-benefit least-risk approach to this, basically we compare each of the expressed options and then find the one which gives us the maximum net benefit without exceeding an agreed-upon risk/issue threshold.

[EchedelleLR]

I ask here.

Is not an hybrid solution possible?

In the beginning, I voted option 2 thinking on this.

Part of the CI at SourceHut and part at GitHub and allowed contributions in both sides.

You can maintain contributions here and allow the easy migration to a fully Free Software solution.

[Be-ing]

Part of the CI at SourceHut and part at GitHub and allowed contributions in both sides.

Not really. CI should tell you if a merge/pull request would break builds or fail tests before it is merged. SourceHut cannot tell you if code changes would break Windows or macOS builds.

[Be-ing]

voting is a good way to find the general positions of the community

I agree that the voting has been helpful for getting a general idea of where the community is, but I don't think the voting should be taking as definitive at this point. I get the impression many who voted for SourceHut were more voting for "not GitHub" than really voting for SourceHut.

[EchedelleLR]

Not really. CI should tell you if a merge/pull request would break builds or fail tests before it is merged. SourceHut cannot tell you if code changes would break Windows or macOS builds.

Well, this is not what I am used to do, given some projects in which I saw direct commits and the builds runs after it. If this is a behaviour that can be used I don't see any problem.

[Be-ing]

direct commits and the builds runs after it

All code should be reviewed before it is merged to the upstream branch unless you're working alone.

[EchedelleLR]

What would be the issue working with a development branch for it?

Then, periodical merges to the main branch. Some projects (I don't have anything in my mind right now but I remember to see it) work like that.

[Be-ing]

This is getting off topic. The more important point is that SourceHut's CI does not support Windows or macOS.

[EchedelleLR]

This is getting off topic. The more important point is that SourceHut's CI does not support Windows or macOS.

I am trying to solve the background issues after it supporting the idea of the hybrid environment.

It is not offtopic if I am just trying to solve any issue you submit to the idea.

[emabrey]

I am in favor of option 4.

[unbeatable-101]

voting is a good way to find the general positions of the community

I agree that the voting has been helpful for getting a general idea of where the community is, but I don't think the voting should be taking as definitive at this point. I get the impression many who voted for SourceHut were more voting for "not GitHub" than really voting for SourceHut.

That is what I got from this too, an actual vote should give more options other than GitHub and SourceHut. Also no matter what we do I think we should leave github up as a mirror, even if we don’t accept contributions to it (Like https://github.com/apple/darwin-xnu/).

[davidak]

I am in favor of option 5.

I think Codeberg would be the best option as it has similar workflow to Github that most developers are used to without the bloated nature of GitLab.

• They don't offer CI yet, but are working on it. A self-hosted CI can be used already (I tested that successfully).
• They are testing GitHub login right now, so every GitHub user can easily contribute. GitLab also considered.
• It is a community maintained non-profit based in Germany (strong privacy laws).

I'm against Sourcehut because i think the e-mail workflow is not user friendly (i tried once and it was hard to setup). It feels very archaic to me and is comparable to IRC. I think people that still prefer such technology from the 90s are also using window managers and CLI tools. Nothing against them, but i think it's not for the majority of people and projects should be accessible to everyone.

[falkTX]

If we use mingw, sourcehut can compile windows binaries just fine. There are some interesting projects out there to run macOS under qemu/kvm under docker, worth checking at some point.

We have to be aware that the tool picked needs to be good for new comers yes, but it should cater to the wishes/needs of a core team too because those are the ones that are going to maintain the thing..

[fossdd]

If we use mingw, sourcehut can compile windows binaries just fine.

Isn't that for have a GNU environment on Windows? And not for Windows under Linux. Maybe building for Windows work with Wine

[falkTX]

It can do both. cross-compile from linux and give unix-like environment on windows. The final binaries work on stock windows, I built audacity like that before.

[Be-ing]

If official builds rely on cross compiling, I think it is unlikely that there will be macOS or Windows contributors, which makes it unlikely that platform-specific bugs would get fixed.

[falkTX]

Not my call to make, but on Windows 10 and 11 running Linux CLI stuff is pretty simple now. And mingw has native windows tools too, no need for VMs and cross-compilation.

[Be-ing]

If we switch to cross compiling for official builds, someone needs to figure out how to maintainably make the same build system usable on macOS and Windows and thoroughly document how to builds on macOS and Windows. Otherwise I have little confidence that OS-specific issues will get fixed.

[Flyingmana]

Lets try to move the discussion about Build environments out here for better visibility. I created one for Windows here: https://github.com/tenacityteam/tenacity/discussions/183 I think OSX should get a separate topic, even as some approaches may overlap

[Be-ing]

Then let's put aside this discussion until we decide on that because it affects what options are available for this discussion.

[nova-nowiz]

I am in favour of 5.

My preferred platform would be Codeberg (thanks @davidak for your comment). It is based on gitea and is hosted in the EU. The UI is super clear like github so it would be very easy to switch from github to codeberg.

I also think the switch can be done later. This repository and organization are still very young, so I think this issue is not a priority right now. Furthermore, it will increase friction for contributors and require a lot of work in terms of setup (finding solutions for the CI is the more pressing one).

My guess is that the smartest thing to do in this case is to make the switch in steps. First, have github as the primary platform but setup and improve the alternative platform as time passes. Then at some point when all roadblocks and friction points have been cleared and the alternative platform is now as or more functional/usable than github, make a public announcement stating that the former secondary platform is now the primary one.

This hybrid solution would provide time to setup the alternative platform and also testing of the alternative platform. When it is made stable and usable as the main one, switch. The switch would in this case only be political or to gather the community in one place as the two platforms would be in fact functional.

[purplesyringa]

finding solutions for the CI is the more pressing one

I believe repository hosting and CI can be decided on separately. If sourcehut, for instance, only supported Linux CI, it wouldn't be very difficult to write a script to run Windows and macOS CI on GitHub or GitLab or something else and then show the logs on sourcehut (I've done something similar before)

[Be-ing]

If we switch to cross compiling for official builds, someone needs to figure out how to maintainably make the same build system usable on macOS and Windows and thoroughly document how to builds on macOS and Windows. Otherwise I have little confidence that OS-specific issues will get fixed.

If we can get this working so we only need Linux CI runners, my preferences would be Gitea, then GitLab, then SourceHut.

[Be-ing]

@falkTX if you can open a PR to get cross compiling working on a GitHub Actions Linux runner, I think that would be a great proof of concept to move this discussion forward.

[falkTX]

At some point will do. Still need to read stuff about github actions, I never used them before (only modified someone else's configs)

[NotAProton]

I am in favor of 4 then 2 Github requires an account and accepting of their terms & privacy policy.

[RoaddogLabs]

How does changing the source control benefit the project? If the goal of the project is to get as many contributors and expose the project to the largest possible audience then right here is the obvious choice. So far I've not seen one compelling technical reason to have two methods let alone leave here altogether. The reality is that for the fork to succeed it needs to be here in a manner where it isn't treated as second to another solution.

It's far from a done deal this fork will come close to the penetration of Audacity. Or even ship a point release. Too soon to tell. For that to happen there needs to be consistency in all things related to the project. Part of that consistency is retaining a presence here. It has nothing to do with who owns the platform, whether it's open source or any other altruistic leanings. It has to do with traction and visibility. Getting the best audio editing program possible should be the goal. The tools and workflow to make that happen are secondary in this case. There is more downside to moving than there is to staying.

[caughtquick]

How does changing the source control benefit the project? If the goal of the project is to get as many contributors and expose the project to the largest possible audience then right here is the obvious choice. So far I've not seen one compelling technical reason to have two methods let alone leave here altogether. The reality is that for the fork to succeed it needs to be here in a manner where it isn't treated as second to another solution.

It's far from a done deal this fork will come close to the penetration of Audacity. Or even ship a point release. Too soon to tell. For that to happen there needs to be consistency in all things related to the project. Part of that consistency is retaining a presence here. It has nothing to do with who owns the platform, whether it's open source or any other altruistic leanings. It has to do with traction and visibility. Getting the best audio editing program possible should be the goal. The tools and workflow to make that happen are secondary in this case. There is more downside to moving than there is to staying.

That's my opinion too, I think we should stay on GitHub until this project is known for more than the GitHub repository.

[Be-ing]

The reality is that for the fork to succeed it needs to be here in a manner where it isn't treated as second to another solution.

This is an obviously false assertion. GitHub does not have a monopoly on software development.