I make releases when I fix important bugs and want people to enjoy the fixed version. Anyone else who patches webkit could do the same. Making everything necessarily go through me is a bad idea.
However, I would still prefer that the release source is stored on some haiku-official acccunt and not one personally owned by someone, that’s why it is on haiku’s github account at the moment
On codeberg Haiku inc manages the Haiku account, that could work. But contrary to disroot I don’t have explicit permission, and since that repo is pretty big that would be nice to have.
@kallisti5 Since you manage that, msybe you can ask for that permission to host a cooy at haiku/haikuwebkit on codeberg too?
Traditionally, we have had “official, non review.haiku-os.org repositories on Github”
I’m open to shifting that to Codeberg, however we would be taking a slight risk as it’s a lot younger than Github. To be clear though, i’ve spoken directly to codeberg maintainers before, they are good folk.
We would need to make that shift as an organization with community consensus.
@nephele if you want to try and get consensus, maybe start a new thread to discuss?
Out of scope: we’ll always mirror Haiku and other repositories to Github… the point here is migrating things that have their source of truth at Github to codeberg. (haikuwebkit, infrastructure, website, website-inc, etc)
I indeed have full owner access to the haiku org @ codeberg.
No, I’m not talking about a mirror. The haikuwebkit github repo stays where it is, and one can be on codeberg. I can push to the one on codeberg and make haikuwebkit releases there…
I’m not interested in that. I’ve pretty much given up on contributing to the website repo, trac, etc. because of this gihub nonsense (especially parts of my commits beeing removed or reverted despite my objections, solely because I have not written them on github even If i talked to the involved parties directly). And the reactions have always been negative.
I care about the haikuwebkit repo, and would make releases for that. But other than that I really am not interested in another pointless discussion about github.
Besides that, there is no such thing as a source of truth for git repositories. There isn’t really stopping us from switching between repos for one release or another.
The only thing that matters is the “pointer” from which haikuports builds it in that case.
And besides all of that, I still don’t see why there would be any problem hosting haikuwebkit on gerrit apart from vague statements that it could be a problem. Which I fond doubtfull since my old laptop manages that repo fine… and even if the machine is not powerfull enough, well then it should be. Our code should be on something we control.
I’m confused. How would you ensure those two repos stay in sync?
The Codeberg tutorial above shows a simple setup which pushes Codeberg commits to GitHub and GitHub commits to Codeberg. That would allow all haikuwebkit maintainers to use the platform of their choice. Do you have a better idea?
+1 from me for migrating things to a hosting system that uses open source software instead of GitHub.
We can of course keep a mirror on Github for all these things.
This is not pointless, it is about solving exactly the problem you have: these things should not be on GitHub, a platform that is closed source and owned by Microsoft, one of our direct competitors
I don’t agree with that. While technically true for git itself, having a central place where people can be confident that it is “the” repository makes things a lot easier for us and a lot harder for people who could attempt to impersonate us and distribute malware. Maybe that’s an unlikely situation for Haiku in its current state, but let’s try to use good practises where possible.
If we wanted to go to a full decentralized system, sure, Git makes that possible, but then we have to establish trust in a different way, for example, by having people use GPG keys to sign their commits. Given all the drama there was over the use of TOTP tokens for Github, I do not believe that the involved people can be trusted to manage GPG keys. so, let’s keep the simple solution: these things should be hosted at a single “official” place, managed by Haiku, and there can be as many mirrors as we want.
Yes, of course, the ideal thing would be to have everything on Gerrit. More than a software performance problem, my worry is that it adds extra work to the Haiku sysadmin team, and that team is mostly one person who may not have the bandwidth to do it.
True for haikuwebkit, but not for the website, for example. I would rather not end up with a situation where we have to tell people “ok so the main haiku website is on our selfhosted gerrit, but the website is on github, but haikuwebkit is on codeberg except we have to use github for it anyway because that’s where upstream webkit is and we have to send them pull requests anyways”.
The overall conclusion: this is a social and organizational problem, not a technical one. That was kind of obvious to me: a git repository is a git repostory, no matter where you host it.
I agree, however my response was to the question if I want to raise a thread to reach consensus, which I don’t since I doubt this will be anything else than the other times we discussed this. And I don’t want to start such a discussion again.
Anyhow, I am somewhat annoyed that all these unrelated git repos are now grouped together and somehow it is on me to convince “the community” to migrate everything somewhere else. That is a big goalpost that is moved, and I don’t see why I should do this. As I’ve said I’ve pretty much given up on the other repos, and I see energy invested into arguing about that as wasted energy for me.
Haikuwebkit is one repo to migrate (or well, I only asked about a second location…), and that is what I asked about. You wanted to have it on a “haiku” named account and that is an okay consideration I wanted to accomadate. But I don’t want to get repod into a yet another discussion of how some people think github is convenient or whatever for the other repos.
Edit: Beside all that, I think github is terrible for haikuarchives stuff, and would be the same for codeberg. It makes no sense to me why there should be one issue tracker per abandonded software. That just leads to nobody reading them. There has to be some grouped together issue tracker for everything. And I doubt codeberg provided any advantages for that right now. (Maybe a Overview in the organization, or some trac with components…)
Seeing as I don’t see haikuarchives as working right now, I don’t want to advicate for a solution that wouldn’t solve these problems… however Haikuwebkit does not have this problem.
Kallisti5 says he’s OK with it. I said I’m happy with it. You say you’re happy with it. Humdinger announced he has moving his project out of GitHub. APL says he is OK with it. I said I’m happy with it. How much more support do we need here?
And I think I have explained clearly why I think these Haiku repositories should be moved together rather than only some of them. It doesn’t need to be done all in a day, but there should be a plan to reach that goal. Maybe it’s “moving the goalpost”, but 1) it’s you who had set that goalpost of caring only about haikuwebkit, not us and 2) that’s just how Haiku works. Working on any app will inevitably end up with patching or improving the operating system itself ; working on any sysadmin task will inevitably unpack a lot more things to work on. If you are not happy to work that way, you will have a difficult time contributing to Haiku, and, yes, it is not always fun. But then, your life is simpler: you host your version of HaikuWebKit wherever you want, and start making releases from it. For that, you do not need any help from Haiku, as far as I can see.
HaikuArchives is a completely different thing. Let’s get Haiku stuff moved.
I don’t know. Before it was written to need “community consensus”. Anyway, My objection was to me creating a thread to reach a consensus. Not about the task itself.
I was under the impression this was also ment, okay
edit:
Sure, I could. But I’d rather work with each other than against each other. You have given reasons why you think such an aproach wouldn’t work well, and while I don’t see these issues as important as you do, but I do agree with them, and they were good to bring up.
The only thing here was your request to not host it on my personal repo, and instead host it on the haiku one. And for that I do need haiku support
So, at a high level… here’s what is being proposed if i’m following correctly:
Everything “not a mirror” at Github today gets migrated over to Codeberg
We continue to host haiku, buildtools at gerrit as usual and mirror them to Github and Codeberg
All of our containers will need to move to Codeberg as well since we use ghcr. (DigitalOcean technically has a Container Registry offering putting containers closer to infrastructure, but there is a cost.)
We have github actions for containers. These need migrated somehow…
We keep a single source of truth for repositories. We are not doing any weird bi-directional sync
Pros:
Less corporate, Not Microsoft.
Reduces our US footprint.
As a side note, most of our Infrastructure + Kubernetes clusters are in Amsterdam
Cons:
Newer
less funded, potentially less stable
Sometime services are a bit slower at Codeberg.
Questions:
Do we want to try to redirect from old Github repos to codeberg?
I need to check if this is even possible. I know you can redirect from old Github repos to new Github repos… not sure you can redirect externally.
We probably should add a social login to codeberg for sso.haiku-os.org. (that’s not a question!)
Does Codeberg have good enough actions / pipelines / CI/CD to continue our build automation.
There’s an interface on GitHub where you can see all the open issues across an entire organization, however it only works when logged in: the “Issues” page.