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.

[falkTX]

I am in favour of 2 (Sourcehut primary, GitHub secondary)
If that is not possible, 4 (GitHub primary, Sourcehut secondary)

While GitHub gets the most attention and users, it is not something I wish to stick around for the long-term.

We need to remember that those developers that are not okay with GitHub cannot come here and vote.
Having an alternative for them would be great.

[nbsp]

I am in favour of 2.

Speaking as a user, as I've left the team for a related reason.

As much as I'd like option 1, I understand it would be suicide for the project. It's just now gotten traction, deleting it would be the end.

Option 2 is the one I've been championing for since the start of the debacle. GitHub is a proprietary software forge, owned by a (subjectively) malicious company, and might be in violation of various viral licenses. Sound familiar?

The dislike toward sourcehut stems from 2 primary reasons:

1. You don't like Drew DeVault, for whatever reason, and do not wish to support him
2. The original "old" email-driven workflow is alien, and feels slower, and the UI is too simple

I'm not gonna argue with the former, but I can assure you that the UI being simple is a blessing; a recent blog post I read goes into detail about that. It's also way more accessible. As I said, everyone online has email, not everyone has a GitHub account. Contributing on sourcehut does not require a sourcehut account.

Whatever the community decides on will be the right choice by definition; just my 2 cents.

[AnErrupTion]

I'm in favor of 3.

I would prefer option 4 but because I never used Sourcehut I would go with option 3, since GitHub has and will get you the most users.

[falkTX]

I would prefer option 4 but because I never used Sourcehut I would go with option 3, since GitHub has and will get you the most users.

Why does it make a difference to you then? The idea with primary and secondary is that you would use one of them, not both.
So we can receive as many developers and contributions as possible.

[fossdd]

I am in favor of option 2 (alternativly 1, after that 4)

SourceHut is completly free and has a completly email-driven patch and discussion system like in many project like the linux kernel.

I would also like to see it completly on sourcehut that we don't have to look at open issues and PRs here on GitHub and can controll all withour email-client. But the most people also want to control their workflow over GitHub and we won't ignore these people.

I hope that many users come with and continue contributing. Hey: No account is needed, you can discuss and send patches in with your already (for GitHub required) E-Mail address. So there is no loss, just the people don't have to loss their fun contributing if there are 2 platforms or just one which is not so famous like GitHub is.

[fossdd]

I would prefer option 4 but because I never used Sourcehut I would go with option 3, since GitHub has and will get you the most users.

Like I just said, you can do all with your email client and don't have to register or so. It's like the old-style linux workflow.

[nils-van-zuijlen]

I am in favor of option 2. (then 4)

As anyone with an email account can contribute to srht, and you have to have one to even use git, it seems to be a good solution.
Also, if anyone has issues with git-send-email, they will be able to submit PRs.

[Sciss]

Despite all valid criticism and problems of GH, I would always keep it as one platform/mirror of the project (thus not option 1). The next problem arises where you want users to interact, because you wouldn't want more than one ticket system, wiki, etc. Sourcehut doesn't even have a formal Wikipedia entry, to try to lift a project off the ground by moving to an obscure platform as first step, doesn't sound wise to me. And no, many people do not want to send and review git patches via e-mail.

[fossdd]

@Sciss Can you edit your post and add the I am in favor of option ....?

[Sciss]

Well, it is a request for comment, so there is my comment. Not sure this should be a vote by now.

[Be-ing]

Speaking from years of experience struggling with self hosted cross platform CI and setting up alternatives, I think that unless someone comes forward with a plan for cross platform CI besides GitHub Actions, this discussion is largely moot. Option 4 would be a reasonable compromise, but reviewers would need to diligently check CI results from GitHub Actions before merging on SourceHut.

[adrianheine]

I am in favor of option 2 (alternatively 5, 1)

5 being moving to another forge (probably gitea), possibly self-hosted.

[Semisol]

@adrianheine Added.

[JPcode05]

I am in favor of option 4. Most people use GitHub and discover the project via GitHub. Not everyone will play well with Sourcehut, especially git-send-email. But my solution is to use both at the same time. If you prefer Sourcehut, use it. If you prefer GitHub, use that.

If another raid happens, in mailing lists, Sourcehut's servers may not be able to handle the load (since it's smaller than GitHub), and your Inbox will blow up just like Cookiengineer's did. Either your Email experience will be ruined because of the mailing list (and what if your mail server can't handle it?) or so many messages will be sent to spam that all of Sourcehut's future emails will be marked spam by your mail provider. Best example is Gmail, which most people use.

For general discussion (especially in forum help), people do not want to figure out how to sign up for Sourcehut to join a mailing list when all they need help with is how to use Tenacity, which in that case we will use Discourse. Developers, on the other hand, can sign up for either GitHub or Sourcehut to discuss development issues. Just be sure to get rid of the Discussion tab.

Edit: Just in case something wrong happens to GitHub, I do want this project to be on Sourcehut so that it's easier to abandon GitHub when the time comes.

[Semisol]

I am in favor of 4 (then 2).

I currently do not want to confuse potential contributors on GH, but also provide people that do NOT want GH an alternative.

[JPcode05]

I'm in favor of 3.

I would prefer option 4 but because I never used Sourcehut I would go with option 3, since GitHub has and will get you the most users.

I don't like 3. I prefer 4 over 3. (My vote comment is above.)

[fossdd]

Yes, understand @JPcode05 meaning. Git is already federated & decentralized and using pusing both to the two remotes would work. But we should have a main instance where we can people link to.

[Semisol]

Yes, understand @JPcode05 meaning. Git is already federated & decentralized and using pusing both to the two remotes would work. But we should have a main instance where we can people link to.

That is what we decide as Primary will be.

[gregsskyles]

I'm in favour of 3.

I'd echo all of the reasons given above- it would be suicidal to migrate at this point as @SFR-git says, how to manage CI as @Be-ing says, and as several state, it would maximise the users, exposure and leverage what most people know. And as @Sciss suggests, I do not want to review git patches in email, and I'd worry about using something as obscure (to me) as SH is. I'm also not hearing what the advantage of SH is, other than its not M$ and the Linux kernel devs like it (are they going to contribute to this project?).

The email-driven issue management of the Audacity developer list was an ugly mess; GH issues are much superior. Maybe SH doesn't have this issue, but the email driven workflow comments have me worried.

All this being said, I could vote 2 or 4, if I knew anything about SH other than how to spell it and what the actual potential for interoperation is.

[Be-ing]

maximise the users, exposure and leverage

FWIW, I think this is a bad reason to stick with GitHub. Cross platform CI is a compelling reason though.

[Sciss]

I think this is a bad reason to stick with GitHub

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? And exposure for a project that is not yet standing on its own feet, why is that bad? That doesn't have to mean we will forever stay on this platform. I think it doesn't preclude us from designing the process so that we are not locking our selves into this platform. At least GH has API to move things, e.g. migration to GitLab works pretty well.

[gregsskyles]

maximise the users, exposure and leverage

FWIW, I think this is a bad reason to stick with GitHub. Cross platform CI is a compelling reason though.

Yes, could be that's not what you want. Reading through issue #8 didn't really point one way or the other on this one.

[purplesyringa]

I am in favor of option 5 (Something else).

GitHub pros:

• Simple for beginners
• Almost everyone is familiar with it
• Lots of great built-in features such as milestones, projects, issues, PRs, CI, etc.

GitHub cons:

• Not FOSS
• Doesn't work well with LibreJS
• Too corporate / owned by Microsoft / whatever, if you see that as a problem

SourceHut pros:

• FOSS, works with LibreJS, etc.
• Great CI
• Simple, for some definition of simple

SourceHut cons:

• Not familiar to many people, requires yet another account, etc.
• Rather complicated for beginners: doesn't immediately show code tree, patches are mixed with issues, mailing lists, no labels/milestones/etc. for issues

Tenacity badly needs more contributors, so I think switching to SourceHut at this point is not worth it; moreover, some of the problems of srht I listed apply to those who would like switch to a FOSS solution too. What about complete (or almost complete) synchronization of three platforms at once: GitHub, GitLab and SourceHut? GitHub would be useful for beginners (or as a landing page, because some people think that Git is synonymous to GitHub), SourceHut may be used by professionals and GitLab would be a great middle ground?

[nils-van-zuijlen]

SourceHut cons:

• Not familiar to many people, requires yet another account, etc.

Actually, as all of srht is email driven, contributors are not required to have an account to send patches (PR), todos (issues) nor an email to any list. That's a lower bar of entry than GitHub, GitLab or Gitea which all require you to have an account to do anything beside browsing.

[Semisol]

Three platforms feels like too big of a hassle.

[purplesyringa]

Actually, as all of srht is email driven...

Which I believe is a con these days. GitHub, for instance:

• Differentiates issues from PRs, this is lost in email
• Supports formatting, which is not exactly easy to get in email
• Has great tools for code review, and all the comments are in one place, whereas in emails you have to read the whole thread
• Immediately shows the current state of the issue such as whether it is open or closed, issue labels, who is assigned, whether there are PRs that fix a bug if the issue is a bug report, etc. In emails, you have to grep the emails for 'state changed' or something.
• On GitHub and such stuff connected to any given repository lives at a well-known location: github.com/username/reponame, whereas your incoming mail box may be filled with spam, work mail, notifications and info about other repositories.
• The younger generation seldom uses email nowadays, which isn't a problem for us at the moment but may become one later on.

[falkTX]

Tenacity badly needs more contributors

this is a little offtopic, but why do you think so?
if goal is to stay close to audacity, most of the work is going to be for initial setup, the rest is just trivial maintainer stuff.

PS: let's please not discuss git send-email vs github web approach cons vs pros here. this is a debate like many others (which build system is better, which language is better etc etc) that never end.
thanks.

[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.

[12people]

I am in favor of option 5. Specifically, moving to Gitlab and mirroring code only to Github.

As some have mentioned above, Sourcehut is only in alpha state, which makes it a risky choice for a larger long-term project. More importantly, it's not particularly user friendly and could potentially discourage people from contributing.

We can learn from GNOME's, Freedesktop.org's and KDE's migrations here. I don't know about the others, but GNOME migrated because their previous stack was not very contributor friendly and was also getting harder to maintain. Sure enough, once they migrated, they saw a rise in contributions — showing that the user-friendliness of a platform really does matter.

Anyway, if Sourcehut is chosen, I'd be in favor of having a window (3 months?) where Github would still be primary and Sourcehut secondary. That way, developers could test out Sourcehut and see if it really meets their needs.

[blackcrack]

please Vote and not only Reason

I am in favor of option 1/2/3/4/5.
<insert reason>

and any can have his reason, but it must justified
if like, thump's up or not it's no matter and can f... the same imho, so please, give a clean VOTE
at me is 5th or 2 and read the ..beep.. Topic on top if you are write something ...
Gitlab and Sourcehut at me, but this have i already say's more top why..
in short: Independent of MS (Github belongs MS) and the States ...

(that comes out when you hide something)
( i want not directly goes offtopic, with a new post, but @Be-ing , hey DJ, Gitlab supports the most systems, include WinNT and Sourcehat too so far i am know.. so, imho must first goes independents and support Linuxbin's then thinking about WinNT and Mac is a Linuxsystem with own restricted driver in short, so.. what about "cross compiling" and if need it's able to use external compiling engins DJ.. i know you have wrote Mixxx ... )

[Be-ing]

It is too early to vote on this. We have work to do exploring technical options, namely cross compiling.

[Songtech-0912]

@Be-ing As stated previously, this is an advisory that will be taken into consideration for the final vote. Anyways, 2 more contributors before the final vote is taken and I do the tally! I am voting for option 4.

[fossdd]

It is too early to vote on this. We have work to do exploring technical options, namely cross compiling.

But If we wait longer, the migration would getting harder and harder.

[bl-ue]

Also, we don't have enough normal users and potential developers in the voting. Most of the people voting for 1/2/5 have moved away from GitHub, and lots of them say so on their GH profiles. 😕

[cadadr]

If the opinon of users were requested too, I want to express mine. If not, you can dismiss my vote.

I'm in favour of (3), remaining on Github. Reasons are as follows:

• Sourcehut is a paid-for platform (tho currently it's free in its alpha IIUC). There's an exception for those who use it only to contribute but that might change and/or be confusing to newcomers.
• Sourcehut is run mostly by a single person. If a non-mainstream code forge is to be used, I feel like it's more appropriate to opt for a platform that is collectively community owned.

As for (5), I think there's not much that GH offers that GL doesn't. But IMHO postponing a move until after the fork is in some OS repos, a new website is made, and some traction is gained is wiser. As @Be-ing says, GH shouldn't have a monopoly on hosting FOSS, but I don't think there's harm in taking advantage of the existing contribution routes that the wider community is used to while the fork establishes itself.

Anyways, my 2c. Thank you so much for your perseverance on maintaining this fork and doing the right thing, despite a bunch of sad stuff we had to put up with.

[kubo6472]

I would do it in this way, if debating about whether or not move to sourcehut. Keep in mind, that you can host sourcehut software yourself. However, for performance and ease-of-use reasons, I much prefer gogs as a self-hosted product.

[Be-ing]

But If we wait longer, the migration would getting harder and harder.

I agree that we shouldn't wait for some arbitrary time to switch. I think we should switch when we have a solution figured out for macOS and Windows builds.

[kubo6472]

I agree that we shouldn't wait for some arbitrary time to switch. I think we should switch when we have a solution figured out for macOS and Windows builds.

I think you can build at least Windows binaries in docker containers.

[Be-ing]

That does not help:

Windows requires the host OS version to match the container OS version.

[fossdd]

I would do it in this way, if debating about whether or not move to sourcehut.

That would option 1.

Keep in mind, that you can host sourcehut software yourself.

Of course, but there is not a big reason. SourceHut doesn't require a account, all contributors can contribute with only having a email address. It is maybe a bit much for "just" a audacity fork, sr.ht already has it's servers.

However, for performance and ease-of-use reasons, I much prefer gogs as a self-hosted product.

Gogs (and also the fork, gitea) require a account for contributors if they want to submit a patch.

If the opinon of users were requested too, I want to express mine. If not, you can dismiss my vote.

The team would, i guess, allow everyone to vote. Users, Developers, and so on, everybody is welcome as it's a free and open source community-driven project.

[Semisol]

I have started tallying. The issue will be locked to collaborators until the results are out.

[Semisol]

Please note that only clear (I am in favor of x (optional: then y, z)) choices will be included in the tally.

[Semisol]

Using instant runoff voting (like previously done in the name private vote), the winner is:

Sourcehut primary, Github secondary.

Ballot data

BLT file

5 1
1 2 4 - 0
1 2 - - 0
1 3 - - 0
1 2 1 4 0
1 2 4 - 0
1 2 5 1 0
1 4 - - 0
1 4 2 - 0
1 3 - - 0
1 5 - - 0
1 1=2 - - 0
1 1=5 - - 0
1 4 - - 0
1 5 - - 0
1 4 - - 0
1 2 1 - 0
1 5 - - 0
1 4 - - 0
1 1 2 - 0
1 2 - - 0
1 2 - - 0
1 2 4 5 0
1 3=4 - - 0
1 1=5 - - 0
1 2 - - 0
1 4 3 - 0
1 3 - - 0
1 5 4 - 0
1 4 - - 0
1 5 - - 0
1 5 - - 0
1 4 2 - 0
1 5 - - 0
1 4 - - 0
1 3 - - 0
1 2 - - 0
0
"Sourcehut"
"Sourcehut primary Github secondary"
"Github"
"Github primary Sourcehut secondary"
"Other"
"Vote for forge selection"

The raw ballots:

2 4 -
2 - -
3 - -
2 1 4
2 4 -
2 5 1
4 - -
4 2 -
3 - -
5 - -
1=2 - -
1=5 - -
4 - -
5 - -
4 - -
2 1 -
5 - -
4 - -
1 2 -
2 - -
2 - -
2 4 5
3=4 - -
1=5 - -
2 - -
4 3 -
3 - -
5 4 -
4 - -
5 - -
5 - -
4 2 -
5 - -
4 - -
3 - -
2 - -

(- = unspecified, a=b means both were selected)

OpenSTV logs:

OpenSTV version 1.7 (http://www.OpenSTV.org/)

Suggested donation for using OpenSTV for an election is $50.  Please go to
http://www.OpenSTV.org/donate to donate via PayPal, Google Checkout, or
Amazon Payments.

Certified election reports are also available.  Please go to
http://www.openstv.org/certified-reports for more information.

Loading ballots from file test.blt.
Ballot file contains 5 candidates and 36 ballots.
No candidates have withdrawn.
Ballot file contains 32 non-empty ballots.

Counting votes for Vote for forge selection using Instant Runoff Voting.
5 candidates running for 1 seat.

 R|Sourcehut  |Sourcehut p|Github     |Github prim|Other      |Exhausted
  |           |rimary Gith|           |ary Sourceh|           |
  |           |ub secondar|           |ut secondar|           |
  |           |y          |           |y          |           |
==========================================================================
 1|          1|         11|          4|          9|          7|          0
  |-----------------------------------------------------------------------
  | Count of first choices.
==========================================================================
 2|           |         12|          4|          9|          7|          0
  |-----------------------------------------------------------------------
  | Count after eliminating Sourcehut and transferring votes.
==========================================================================
 3|           |         12|           |          9|          7|          4
  |-----------------------------------------------------------------------
  | Count after eliminating Github and transferring votes.
==========================================================================
 4|           |         12|           |         10|           |         10
  |-----------------------------------------------------------------------
  | Count after eliminating Other and transferring votes. Candidate
  | Sourcehut primary Github secondary is elected.

Winner is Sourcehut primary Github secondary.

[EchedelleLR]

@Semisol why did you use propietary software for this?

For example, I suggested https://poll.disroot.org specifically to avoid this...

[EchedelleLR]

Ah okay, that was the last FLOSS version. I read.

Sorry.

[Semisol]

Ah okay, that was the last FLOSS version. I read.

Sorry.

I don't want to use the web OpaVote again after trying it (no source code annoys me too).

[Semisol]

I have locked the conversation to freeze the votes.
Thanks for participating, if there are any concerns
send an e-mail to the ~tenacity/tenacity-discuss@lists.sr.ht mailing
list or open a discussion.