Closed Semisol closed 3 years ago
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.
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:
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.
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 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.
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.
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.
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.
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.
@Sciss Can you edit your post and add the I am in favor of option ....
?
Well, it is a request for comment, so there is my comment. Not sure this should be a vote by now.
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.
I am in favor of option 2 (alternatively 5, 1)
5 being moving to another forge (probably gitea), possibly self-hosted.
@adrianheine Added.
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.
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.
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.)
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.
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.
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.
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.
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.
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.
I am in favor of option 5 (Something else).
GitHub pros:
GitHub cons:
SourceHut pros:
SourceHut cons:
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?
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.
Three platforms feels like too big of a hassle.
Actually, as all of srht is email driven...
Which I believe is a con these days. GitHub, for instance:
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.
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.
they achieve the same task of submitting a contribution to be merged, so who cares too much?
this is a little offtopic, but why do you think so?
I thought this issue was for discussion about Sourcehut migration, uh? How's that not an argument against using Sourcehut?
it is just going to be a heated debate that won't stop. people have different preferences and tastes. You explained your reasons why you prefer a certain option. that is good for now.
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
so why not GitLab https://about.gitlab.com/company/
not Microsoft, an Open Sourcefactory in general , and MS have already a OpensourcePortal.. GitHub, i don't know if MS want buy Gitlab also.. ... so, well..
Gitlab have Open Source Partners :
https://about.gitlab.com/partners/
there be a possible for find partners and many others... to hold tenacity more healthy in the future
Option 5,
Primary Gitlab <-rsync -> Sourcehut
this gives later more commercial possibility's at Gitlab and therewith can the secured Sourcehut - sources be in able to make profit in any form from it. therewith be with 2 places both tree's saved,
first it's possible for working with an free account on gitlab, later it's possible for let make more , if tenacity more supported from different parts..
Gitlab have Gui like Github and very easy for Beginners, Users and Extended Users and Programmers.. and i guess, also FOSS...
well, Gitlab is not only in the States.. https://about.gitlab.com/company/visiting/
check it out : https://about.gitlab.com
so.. add a Option for Gitlab and Sourcehat
best
so why not GitLab
Which is exactly what I recommended, please read what others post, thanks.
1 or 2, for me.
@imachug well, can i not give my Opinion ? be i here wrong ?
I am in favor of option 1 / 5 on Sourcehut do you not need a account, and you must not use an Gitlab account for working.. so what else ? i have already account and it disturbs me not.. and right, Sourcehut be i am not familiar , this here is now where i have hear from.. Who was on Github can also work easy with Gitlab .. and because this an rsync option make it possible for working in Sourcehut and supports with Gitlab the nonprogrammers .. the easy Users who want browse programs and want make a issue.. like in Github ... but in Gitlab
1 or 2, for me.
Pick one and put the other(s) as "then x, y, z"
Current results (I'll keep tallying as the vote goes on):
I am in favor of option 4.
After reading all the arguments here as well as on matrix/libera, I personally think that for now, option 4 would be best fit. This way, new contributors are not scared off by the unfamiliar workflow on sr.ht, while those who want can simply submit patches via email. I would possibly consider making sr.ht the primary forge in the future, but Github should be kept in some form because of 1. ready to use cross platform CI and 2. greater exposure to the public (which is important!).
Actually, as all of srht is email driven...
Which I believe is a con these days.
I don't think so. Everyone has these days a email address (for example for GitHub,..). E-Mail is a federated protocol. Everyone can write messages to everyone else over E-Mail.
If someone doesn't want to write patches over emails, you can use github as secondary/primary.
so why not GitLab
GitLab is not a good idea. It has A LOT of javascript which loads long. It requires Google Captcha, uses Cloudflare,... They aren't open source.
They are a for-profit-company. Of course it isn't directly a con, but you should think about it.
If you want to have a GitHub-like or GitLab-like platform I would suggest Codeberg. It is completly community-funded and uses the complete open-source Gitea. It has less JavaScript (does it have javascript?). And users already know it's design and workflow from Git(Hub/Lab).
Primary Gitlab <-rsync -> Sourcehut
Using rsync is a bad idea. Git uses remotes. With remotes you can push it to multiple servers, and pull it, and have it integrated in your git workflow. rsync is too much and in my opinion not usefull.
Let's please try to keep this on topic. If you have a reason for why you prefer something in specific, write it on the post where you left your vote. Thanks
@fossdd we have today Gightz Networks.. or they comes, Computers becomes ever more Power in the engines.. and the Partners of Gitlab be not MS supporter.. or ? and by the way Gitlab is more Prominent as .. ?Codeberg ? huhh again something new..
and as buy MS Github be a couples project goes to Gitlab.. how i become with.. the "Nonprofit" wellll : Pricing
so less nonprofit is it also not..
Because rsync.. okey, i be no more on that stand of things, I must admit :) :grin:
edit: @falkTX Filipe, if this offtopic is fossdd posting also..
Current results (I'll keep tallying as the vote goes on, but this is the last comment I can do today, so it would be great if another contributor could step in):
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.
(Note - for second and third choices I added 0.5 votes and 0.25 votes respectively)
I am in favour of 4
I am in favour of option 2.
Option 1 if not.
I am in favour of option 5: Wait a while and do the vote again.
Sourcehut seems like a popular idea, but it's also in alpha. Maybe it would be best to delay any migration/mirroring effort, and make an agreement to hold the vote again once Sourcehut is more stable?
I am in favour of option 5: Wait a while and do the vote again.
Sourcehut seems like a popular idea, but it's also in alpha. Maybe it would be best to delay any migration/mirroring effort, and make an agreement to hold the vote again once Sourcehut is more stable?
Stability will take time and we are binding ourselves to GitHub more and more every day, which will make it harder to switch.
Sourcehut seems like a popular idea, but it's also in alpha. Maybe it would be best to delay any migration/mirroring effort, and make an agreement to hold the vote again once Sourcehut is more stable?
That could take a while. And maybe it's better to directly at the begin make a decision that the community can build on this platform.
Sourcehut seems like a popular idea, but it's also in alpha. Maybe it would be best to delay any migration/mirroring effort, and make an agreement to hold the vote again once Sourcehut is more stable?
Stability will take time and we are binding ourselves to GitHub more and more every day, which will make it harder to switch.
Also, even if srht is in alpha, it's already the platform with the least downtime and the fastest pages. So it can be considered as a quite stable service. (APIs are changing and some parts need more polishing though)
If we want the most traction and activity, GitHub is definitely the way to go. It's a very large community (in fact, about 50-100 user accounts are made on it every minute as I recently manually determined).
A very many large projects use it too, and more are moving to it all the time.
Having a secondary system is definitely interesting, but it's perfectly possible for it to start getting complex, so let's keep that in mind.
I am in favor of option 4. (not changing my opt anymore 😆)
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:
Options for migration:
We recommend you read all the comments before responding.