Host this fork on an alternative software forge about tenacity-legacy HOT 67 CLOSED

Hello! I'm the maintainer of sourcehut. Thanks for thinking of us.

First of all, on the subject of "deciding later" to switch: it will never be as easy to switch as it is now. Every commit you push, every pull request you open, every CI config you write, ties you more and more closely to GitHub. The CI scripts are not portable to other CI systems, the pull requests are not easily extracted and replicated elsewhere, and more links are being written around the 'net which point at this repository every day. New contributors are learning and getting used to the GitHub workflow and all of those people will have to re-learn another system when you move. It will only ever become harder. If you want to switch, you should decide and execute that plan as soon as possible. I'm the founder of a GitHub competitor and even I still have some projects on GitHub simply because they have built up so much inertia that it's hard to move them.

Codeberg is a great option, but it looks like they're already here so I'll let them speak for themselves. I don't think GitLab is a good choice, for reasons already stated by others; they are open-core and hail from the same faction of software companies which took over Audacity. As for sourcehut: we would love to have your project on our services.

A small community of audio-related projects has already been forming on sourcehut, which you can browse here:

https://sr.ht/projects?search=%23audio&sort=recently-updated

In particular, check out Zrythm, which is similar to Audacity in that it is a sophisticated GUI application targetted at non-technical users. I'm sure all of these projects would be happy to support your onboarding into the unfamiliar platform.

SourceHut's featured projects are curated by a person, not a bot, and that person (hi!) values the FOSS philosophy. Listings on sr.ht have a higher signal to noise ratio and are exposed to a community which more strongly values and understands the free software ethos. If you're concerned about visibility and access to developers during the early phase of the project, I reckon that you shouldn't. You have a lot of attention right now and being on sourcehut or codeberg isn't going to hurt your chances.

SourceHut requires payment for maintainers. Contributors are never required to pay, or even asked to pay, and in fact you don't even need to sign up for an account to contribute to projects on sr.ht.

I think you should consider this carefully. You pay for other platforms in some respect: your personal data, access to your users, and influence over you and your project. GitHub and GitLab are funded by staggering amounts of venture capital, and that means that a small group of capitalists has 10,000× more votes than you do when it comes to how you're treated on the platform. SourceHut has never accepted any investments, and in exchange for your payment, we are accountable only to our users, and no one else, and in exchange we have the resources to build a stable, fast, and sophisticated platform to host your project. The most stable, and fastest, by the way.

Even so, the intention is not to price anyone out. If you cannot afford our payments (which are as low as $2/month for full access to all features), then I completely understand. In these cases, you will be issued free service, no questions asked. Many users have already been given financial aid for a large variety of reasons, including students, those between jobs, those whose preferred currency is not supported for payments, and those who live in depressed economies.

I think that FOSS projects should support one another. A vote for GitHub is a vote against FOSS when there are equally capable FOSS platforms available. If you want the GitHub style, use Codeberg. If you're open to something else, consider sourcehut. But definitely don't use GitHub. For a project which was born of a free software crisis, I would think that you would uniquely understand just why it's wrong to cast your lot with a proprietary platform. There is a chicken-and-egg problem with FOSS platforms that compete with proprietary platforms, and the only way for any of us to overcome that is for projects like yours to give us your vote of confidence.

In terms of logistics, I would recommend using builds.sr.ht for your CI no matter what, since our platform is the only CI platform which is portable to other forges - you can use builds.sr.ht with sr.ht projects, GitHub projects, and GitLab projects, and adding more is pretty straightforward (hey Codeberg, you're in this thread, do you want to work with us?). There is also a GitHub integration which will convert issues from a GitHub mirror, should you want to have one, into todo.sr.ht tickets. Let me know if I can help with any other concerns.

from tenacity-legacy.

Gitlab seems like the natural and easiest choice for me, and I think its the choice that will have the biggest approval from developers.

from tenacity-legacy.

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.

from tenacity-legacy.

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.

from tenacity-legacy.

Hello from a Codeberg praesidium member,

just dropping my opinion in here early, giving a few points for further consideration:

• we'd really welcome you on our service, also looking for a close collaboration if anything is missing to get you started here - just open a community issue or send a patch - we're community-maintained in the end and everything can be improved
• we're always ready to help with a transition to our platform, so feel free to ask your questions or for support
• CI service is high on the roadmap, and it might be possible to provide audacity with early access and collect some feedback on the go, we can talk about this. But please note, that our resources are limited, too. So if our new CI will all be eaten up by audacity, we'll definitely have to ask for donations then 😉
• CI already works fine with external providers that hook into Gitea, see a list of DevOps solutions including CI, integrating more external services is surely possible, too
• and: Gitea has an awesome migration feature that allows to migrate issues, pull requests, wiki, ... from GitHub, GitLab etc and also between Gitea instances. This way, you are never locked into a specific host, but can always move on (once Gitea adds federation for example), or move to a self-hosted version without loosing your data. For me, this is actually (one of?) the most important feature(s) of Gitea.

there are some FOSS gitlab instances like framagit.org

Isn't FramaGit about to be closed for non-frama-related projects? Heard this a while ago. Needs confirmation, though.

perhaps they know better and can provide concrete answers here.

Are there concrete questions I missed? We're glad to answer them.

Thank you for pinging us and considering our platform.

from tenacity-legacy.

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.

from tenacity-legacy.

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.

from tenacity-legacy.

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! ✌️

from tenacity-legacy.

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

from tenacity-legacy.

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

(side note: sourcehut doesn't want to price anyone out. email Drew DeVault at [email protected] with your situation and you will get your account sponsored)

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.

from tenacity-legacy.

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.

from tenacity-legacy.

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.

from tenacity-legacy.

I propose Tenacity as the new name

from tenacity-legacy.

@awslabspl you didn't need to register to see the public repos. Also "seems pretty empty" is not a valid argument for choosing a platform for development. I highly suggest you to read everything in this thread and see what are people's and devs' concerns, and what features they are after and what features are offered. By your standard Facebook would be an ideal platform!

from tenacity-legacy.

Looks like there is a sourcehut project: https://sr.ht/~tenacity/tenacity.

• git repository: https://git.sr.ht/~tenacity/tenacity
• mailing lists: https://sr.ht/~tenacity/tenacity/lists

source: https://tenacityaudio.org/

from tenacity-legacy.

Let's do this formally.

We're moving active development and development discussion to sourcehut.
The GitHub org and repository will remain, and you will be able to contribute via PR, though please send a patch if you can.
We also need this repository to stay on GH so we could have CI for macOS/Windows.

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:
https://lists.sr.ht/~tenacity/tenacity-announce/%3CCCN506I39651.289WTEN2QSSRF%40bellwether%3E

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!

from tenacity-legacy.

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

from tenacity-legacy.

Could someone with access to the Projects add this to stuff we do after we have a name? Drew brought up a great point -- the longer we wait, the harder it becomes to move.

I think this should be the plan of action:
While the community decides on a name, let's figure out which software forge we should use (I think this vote deserves its own issue). The current consensus seems to be either Codeberg or sourcehut.
When a name is made official, hopefully we'd already have decided on a host, and we could create an organization there and start moving the code. ¹

The only real block here is the name.

Regardless of where we host the project, I think two things are made clear:

1. A GitHub mirror should remain for the time being, and we should accept PRs from it (if it's not too much of a hassle for maintainers)
2. Consider using builds.sr.ht for CI, for the reasons I and Drew have mentioned

¹ SourceHut has yet to properly implement an organization structure, but it is planned for the beta. For now, either create a pseudo-org account, or have an already paying user host it (me, for example), and staff will make a note of the situation.

from tenacity-legacy.

There is a separate issue which addresses that. It's currently locked for spamming, so we'll have to wait -- that gives us more time to decide where to go.

from tenacity-legacy.

I would say, whatever case may be, there should be a github mirror.

from tenacity-legacy.

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.

from tenacity-legacy.

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.

from tenacity-legacy.

But wow, Plan9 images... :D

(Sorry, I'm an operating system nerd.)

from tenacity-legacy.

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?

from tenacity-legacy.

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.

from tenacity-legacy.

I would like to add that GitLab is open-core, not FOSS

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.

from tenacity-legacy.

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:

1. Allow at least several people root access to your servers so they can maintain them too.
2. Keeping the servers' operating systems and toolchains up to date and running.

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.

from tenacity-legacy.

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

from tenacity-legacy.

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

Sourcehut does not yet have a formal "Organization" structure. ~tenacity is a pseudo-org, managed by me (~sfr, [email protected] for any reason).

from tenacity-legacy.

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.

from tenacity-legacy.

I agree. We should make the transition after we decide a name and logo

from tenacity-legacy.

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.

from tenacity-legacy.

Additionally: Consider how we're going to move issues to an alternative software forge later down the line.

from tenacity-legacy.

[...] such as depending on GitHub Actions and trying to move our CI elsewhere.

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.

from tenacity-legacy.

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.

mrsh is a great example of a project that's

• hosted on git.sr.ht
• mirrored on GitHub
• accepts both PRs on GitHub and patches on lists.sr.ht
• has issues on GitHub because todo.sr.ht is still a bit lackluster
• uses builds.sr.ht

I'm sure there are projects which use Codeberg and mirror on GH in the same way.

from tenacity-legacy.

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.

from tenacity-legacy.

Of course. We have bigger problems now.
On that note, is there a master issue, GitHub project or Trello board with all of the urgent issues?

from tenacity-legacy.

On that note, is there a master issue, GitHub project or Trello board with all of the urgent issues?

Again, we shouldn't depend too much on GitHub. I'd assume that It'll work fine for now, though.

from tenacity-legacy.

Then a TODO.md file with checkboxes and links will do.

(there is already todo.txt)

from tenacity-legacy.

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:

1. It would be nice to have the main dev on a FLOSS platform
2. Imho the SourceHut is hard/unintuitive for potential users to engage into the project (I myself am a bit overwhelmed with the UI)
3. Having mirror on GitHub in which people can access code, issue bugs reports and feature requests, engage in the discussions and create PR would be great (I acknowledge that it might have some burden on the devs to moderate and aggregate things from this mirror to the main repo)

Regarding the target platform though, I would personally go in this order:

1. Codeberg (the CI is in the roadmap as far as I know)
2. Gitlab (it already has everything a project would need, but at the end of the day it is governed by a corporation and certain sh*t can hit certain fan)
3. Sourcehut (I don't have extensive experience as I mentioned before, but based on what I've read elsewhere and what @SFR-git mentioned here so far, sounds like a good option)

from tenacity-legacy.

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.

from tenacity-legacy.

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.

from tenacity-legacy.

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

from tenacity-legacy.

In addition to @Huy-Ngo there are some FOSS gitlab instances like framagit.org which have CI.

from tenacity-legacy.

@fnetX Do you know of any projects cross-hosted on GitHub/Codeberg which accept contributions on both? See my example with sr.ht. As much as I despise Microsoft, a GitHub mirror is essential at this time.

from tenacity-legacy.

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?

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.

@SFR-git

Gitlab CE is FOSS, it is MIT licence. Their SaaS platform is not.

from tenacity-legacy.

Yes, that's correct -- but we'd either need to find a public instance using CE with enough bandwidth, or host one ourselves. There are more viable solutions at the moment.

from tenacity-legacy.

Do you know of any projects cross-hosted on GitHub/Codeberg which accept contributions on both?

Hmm, not really. Like, I saw many small projects that are hosted on some (or many) instances, but if you only receive one issue a month it's probably not too hard to keep track of them. I don't have one at hand, but maybe someone else knows.

Maybe you can mirror issue / pull conversations via an API? It might be an idea to create a script for this use-case if it doesn't already exist. (Each time an issue is opened or receives a comment, a bot updates the very same on the other platform)

Gitlab CE is FOSS, it is MIT licence

Still, it's an Open Core model. This is the reason I personally don't like GitLab, because you know that some features will not make it into the FOSS version. The community would have to fork and rebuild certain parts. I'm always reluctant to settle on such solutions, because you know your feature request might only be available under a certain licence etc ... (I have had bad experiences with this, like, yeah it's free, but every useful function is behind a paid plugin - wow)

from tenacity-legacy.

Agree. Would love to see this fork on sr.ht!

from tenacity-legacy.

By the way, even if you stick with github you should probably delete and recreate this repository so that it's not listed as a fork. Forks are second-class citizens on GitHub: you don't show up in search results and cannot be featured on their explore page - where the original Audacity is featured instead.

from tenacity-legacy.

There's a separate discussion (#38) about that.

from tenacity-legacy.

I propose Tenacity as the new name

We also liked that name, but it's trademarked. :/

from tenacity-legacy.

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.

from tenacity-legacy.

little hint, one Main Server, and let mirroring at the University's/ Data center's around the world, like Linux Distributions
this is inexpensive as possible.

from tenacity-legacy.

from tenacity-legacy.

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

from tenacity-legacy.

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?

from tenacity-legacy.

builds.sr.ht

Suggesting services that don't support Windows and macOS is IMO not helpful in this case.

from tenacity-legacy.

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?

This has been addressed

builds.sr.ht

Suggesting services that don't support Windows and macOS is IMO not helpful in this case.

We will try to do something

Also if we move to SourceHut this will probably be a mirror.

from tenacity-legacy.

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:

1. Allow at least several people root access to your servers so they can maintain them too.
2. Keeping the servers' operating systems and toolchains up to date and running.

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

from tenacity-legacy.

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 ~tenacity (account), currently controlled by 2 admins. If they want to be public they can.
Essentially 2 admins own it for now.

from tenacity-legacy.

Are there plans how to transmit the whole issues, pull requests and discussions to sourcehut?

from tenacity-legacy.

Are there plans how to transmit the whole issues, pull requests and discussions to sourcehut?

Discussions are ongoing about what should be done, feel free to participate by joining #tenacity on libera.chat

from tenacity-legacy.

Matrix users can participate at #tenacity:libera.chat (you'll need to register with NickServ!)

from tenacity-legacy.

@ddevault if that feature does not exist in SourceHut currently, it sure would make SourceHut a much more appealing option for cross platform projects.

from tenacity-legacy.

Please submit opinion here: #155

from tenacity-legacy.

It seems that the SourceHut repo has been abandoned in favor of GitHub despite SourceHut winning the election. (Srht primary, GH secondary)

from tenacity-legacy.