Move to a free-as-in-freedom forge

[triallax]

First and foremost, GitHub is proprietary software. I value free software very highly, and this alone would have made me attempt moving Clima to another forge, but that's not the only issue at hand. I highly recommend reading https://github.com/toastal/toastal/blob/f%F0%9F%92%80ck-github/README.adoc; it articulates my concerns very well.

Thus, I propose moving Clima to a software forge that actually supports free software values. Here are a couple options:

• Codeberg - this is what I personally use for my projects, and it works quite well in my experience. It uses Gitea, an open-source hosting solution for Git.

  Advantages (these apply to any Gitea instance):

  • GitHub-like UI and workflow (not all people will view this as an advantage, me included, but it means that it's familiar to people coming from GitHub)
  • Seamless migration from GitHub, including issues and pull requests

• Sourcehut - this is an open-source forge with a particular focus on simplicity. For instance, it has no PRs; you submit patches to a mailing list.

  Advantages (these apply to any Sourcehut instance, though I'm not aware of any other than https://sr.ht):

  • Very simple and light on resources
  • Participation in projects does not require an account; you can, for instance, send patches and create TODOs (the equivalent of GitHub issues) by sending e-mails, without any need for an account. I consider this one of Sourcehut's biggest advantages.

  Considerations:

  • At some point in the future, hosting repos on https://sr.ht will require subscription (to be clear, people can still contribute without a subscription, only hosting repos will require payment). This isn't a bad thing really, but we have to keep it in mind.
  • It has no migration tools, so we would lose all our PRs and issues coming from GitHub. This may not be a big problem though if we keep our GitHub repo around as an archive/mirror.

Feel free to suggest other options, such as Gitea instances other than Codeberg and GitLab instances (https://gitlab.com is a no-go though, it has proprietary components).

We'll have to lose CI if we move to either of these platforms (Codeberg requires self-hosting CI, and Sourcehut has CI but it requires payment, though I hear it's pretty good), but I don't think that's a big deal. It's a mere convenience, we can still run checks on the code locally.

Ideally, we would archive Clima on GitHub, but I can reluctantly accept keeping it on GitHub as a mirrored repo. However, the issue tracker would be on whatever forge we move to.

Other things to consider:

• Should we accept PRs on GitHub? I'd say no, but I'm open to discussing this.

@prestosole what are your thoughts?

[Matsyir]

First time peeking into this repo, nice app.

No specific comment on the repo hosts but I support the general idea. It would definitely take me a while to get used to something that's significantly different than github. sr.ht at a glance kind of sounds like a mess to me if it's only issues and no PRs.

Should we accept PRs on GitHub? I'd say no, but I'm open to discussing this.

I don't really see why you wouldn't want to, unless you have a very strict/personalized vision for your app, and know you're basically going to reject any PR. But even then, you could just only allow PRs for existing issues / the team's feature requests. It's free code/work, free features for your app. If you don't like the feature or how it's implemented/commented/styled/etc, you (the main contributors) have the power to say it won't be added or has to be done a certain way. I noticed a few minor improvements I may like to contribute to in the future, and it would sadden me to realize I simply have to wait until someone gets around to it.

FOSS isn't only great for free software & code, but for helping many like-minded people come together and collectively contribute towards one piece of software, which allows the software to grow much faster. Perhaps a weather app doesn't need that extra manpower, but I still don't really see the point in outright denying any and all PRs.

[triallax]

First time peeking into this repo, nice app.

Thanks for the words. :)

sr.ht at a glance kind of sounds like a mess to me if it's only issues and no PRs.

Sourcehut does have patches, which serve the same purpose as PRs but are quite different in nature.

I don't really see why you wouldn't want to, unless you have a very strict/personalized vision for your app, and know you're basically going to reject any PR.

You misunderstood me. My question was that if we moved to e.g. Codeberg, should we only accept PRs there, and not on GitHub?

I noticed a few minor improvements I may like to contribute to in the future, and it would sadden me to realize I simply have to wait until someone gets around to it.

You're welcome to submit changes; we receive fewer external contributions than we'd like to have.

[Matsyir]

Sourcehut does have patches, which serve the same purpose as PRs but are quite different in nature.

I am open minded enough for it, but it scares me. I will have to see it.

You misunderstood me. My question was that if we moved to e.g. Codeberg, should we only accept PRs there, and not on GitHub?

Oh, man, I see. Sorry about that, the whole 2 last paragraphs are irrelevant then. Was a bit tired when I wrote all these last night 😅

In that case, I agree, because it would be a lot more organized if all the actual "activity" was focused on one platform. Having a read-only repo mirror is convenient though.

[WhyNotHugo]

My two cents:

I would actually add a notice on GitHub that the project has moved, and then archive it (which set everything to read only).

This would avoid people opening new issues or alike on GH, while leaving the read-only project for historical purposes.

Keeping it non-read-only will just result in having issues opened in the wrong place.

---

If you move to Sourcehut, you can use this as a reference on how to set up CI for a flutter project on their CI system: https://git.sr.ht/~emersion/goguma

[triallax]

@WhyNotHugo we can disable the issue tracker on GitHub, but the PRs tab cannot be disabled, and some people may be persistent enough to somehow open PRs as issues; such cases should be very rare though. Of course, I still agree with you that the better idea is to just archive the whole thing.

If you move to Sourcehut, you can use this as a reference on how to set up CI for a flutter project on their CI system: https://git.sr.ht/~emersion/goguma

Sure, thanks for the pointer.

[WhyNotHugo]

The issue with disabling them is that you also break all links pointing to existing issues.

[triallax]

Good point.

I just remembered that it's possible to enforce "interaction limits" on a GitHub repo, but that might be somewhat confusing for people. Archiving the project would communicate our intent better.

[triallax]

@prestosole you've yet to voice your opinion on this issue. Do you have anything to add to the discussion?

[prestosole]

There is nothing much to add on my part, but I do favor Codeberg above all others because it's similar to GitHub, and it won't take long to get used to it. And yes, archiving the project on GitHub would be more convenient than, let's say, "interaction limits".

[WhyNotHugo]

I wouldn't mind trying to port the CI I wrong for sourcehut builds into codeberg. I've been meaning to try out their CI and how its caching works.

[triallax]

@prestosole I also vote for Codeberg, so let's move there when we have the time (read: after 2.0.2 is out).

@WhyNotHugo thanks for volunteering, but Codeberg only supports self-hosted CI, which we aren't willing to host. I just learnt that Codeberg now has a Woodpecker instance in closed testing: https://codeberg.org/Codeberg-CI/request-access

[triallax]

We've decided to move to Codeberg ahead of schedule, and here it is: https://codeberg.org/Lacerte/clima/issues

I'm archiving the GitHub repo. All further development is going to happen on Codeberg.