Move website off GitLab.com

Moving to codeberg.org is fine, though we have to see the uptime statistics of prav website before we decide, it used to go down a lot, seems better these days.

https://status.prav.app shows average uptime over 30 days is only 96.41%.

fsci git is in the process of migrating to new server and ci is not yet in the plan.

Make a proposal with pros and cons too, so we can vote on it.

May be we can make codeberg as primary and gitlab.com as mirror so we can continue using gitlab pages, which addresses the frequent down times for codeberg pages.

Grebedoc would also work (may be for prav too) to address unreliability of codeberg pages.

@Pirate Praveen let's start with mirroring to Codeberg, as that can be done immediately. When git.fsci.in is set up in a few months' time we can see about switching to that + grebedoc.

@Badri Sunderarajan sounds good. @fugata can you make a proposal for this? We will move repo to codeberg as primary, but gitlab.com will have a mirror and website will be served by gitlab pages.

@badrihippo I'm a little confused by your phrasing here. I'm not sure it's possible to mirror "to" Codeberg, since AFAIK Codeberg does not allow mirrors to preserve storage space used up by dormant mirrors. @praveenarimbrathod seems to be proposing the opposite, i.e. main repository on Codeberg, with a mirror on Gitlab.com.

@fugata oh, I'm coming from the perspective of git as a decentralised system which means there's no such thing as "from" or "to" in a permanent sense. I just meant "mirror" in the sense of "have a copy of" (think "mirror to Codeberg" → "copy to Codeberg"). I wasn't aware of that Codeberg restriction but I don't have a strong opinion either way on what gets pushed where (which is what I assume your definition of "mirroring to/from" is based on).

I'd prefer git.fsci.in to become the primary place for collaboration once it's set up, so I suppose we'll have to figure out what to do about Codeberg at that point.

@Badri Sunderarajan We cannot have both copies editable to allow automated mirroring as conflicts would need to be resolved manually. Since the main issue is gitlab.com access restrictions over tor, editing should only be at codeberg. So we can setup codeberg to push to gitlab.com.

For pages hosting, we can evaluate uptime of prav.app after migrating to new git pages backend and decide if uptime is satisfactory.

I think it would be good to more to git.fsci.in as some dogfooding will be helpful. However, we should wait a bit as git.fsci.in is itself in the process of being migrated.

If you think the move is urgent, I am okay having it on Codeberg for now. Once git.fsci.in is ready, we can shift to that as the primary repo while keeping Codeberg as a mirror.

Regarding the CI (assuming we need one) we could run it on Codeberg (which will work if we have Codeberg mirror the primary repo) or use something like Grebedoc which is designed to work directly with git. In the long term, Megham has some plans for providing site hosting which could be an option too (when it gets going).