Move phrog closer to Phosh upstream ecosystem

[samcday]

🐸 is lonely. Wants to live closer to good friends like Phoshi. Phoshi's neighborhood is very different to here. Some people over there not so sure about this weird new mind-mirror thing.

Two different things to do.

First (most important) - observe and respect the culture and values of Phoshi's family:

• Release every 6 weeks (in sync with Phosh's schedule)
• Adopt code / commit style from Phosh's HACKING.md
• Mimic tone of Phosh's README

Second - make sure Phoshi's HOA (gitlab.gnome.org) not get upset at 🐸:

• Write a concise repo policy on AI usage.
• Port Github workflows to Gitlab (reuse GNOME ci-fairy + Phosh's ci machinery as much as possible)
• (Maybe) Decommission heavy-weight wf-recorder + editly demo recording infrastructure? That make 🐸-papa Sam very sad but he always sad so whatever.

[a-wai]

Port Github workflows to Gitlab (reuse GNOME ci-fairy + Phosh's ci machinery as much as possible)

Feel free to ping when you get to this, I'm quite fluent in Gitlab CI and can likely help porting things over ;)

(Maybe) Decommission heavy-weight wf-recorder + editly demo recording infrastructure?

If it's "just" a matter of not overloading shared runners, we can likely find solutions for that as well!

[agx]

As noted in private chat it's would be great to have phrog together with the other components / in the regular release train. I think the first 3 points can even happen without having to touch the other three. As we use rustfmt large parts of the HACKING.md things can thankfully be ignored.

Regarding CI pipelines: the basic bits can likely just be taken pfs or libphosh-rs but there's also certainly lots of room for improvements there too.

[samcday]

@a-wai:

Feel free to ping when you get to this, I'm quite fluent in Gitlab CI and can likely help porting things over ;)

Who in their right mind would turn down such a generous offer? I will absolutely take you up on this when we get to this stage, thanks :)

If it's "just" a matter of not overloading shared runners, we can likely find solutions for that as well!

I was mostly thinking about the impact on the shared runner infrastructure, yeah. But I also remembered how you bumped into those assets with your Debian Packager hat on and had concerns about the unclear licensing. Hopefully there's not much to work through here overall, because I'd love if we kept it in place :D

@agx:

As noted in private chat it's would be great to have phrog together with the other components / in the regular release train.

🎉

As we use rustfmt large parts of the HACKING.md things can thankfully be ignored.

Agreed. cargo fmt and cargo clippy codify a lot of the things we'd put in a Rust/phrog-y HACKING.md, so that saves quite some effort and ongoing maintenance 👍 I guess it's mostly the commit style and approach to engaging a pull request that I want to emulate / align on.

Regarding CI pipelines: the basic bits can likely just be taken pfs or libphosh-rs but there's also certainly lots of room for improvements there too.

When the time comes, I'll defer to @a-wai on this :D Ideally we'd directly share the shared CI configs from meta-phosh as much as possible.

[a-wai]

But I also remembered how you bumped into those assets with your Debian Packager hat on and had concerns about the unclear licensing.

I don't think that's a problem for migrating to the GNOME infra: the Debian copyright reviews are quite strict, so including the shader file would have required quite some work to ensure the copyright info is accurate and acceptable for Debian, but AFAICT it's all open source licensed, so no actual legal concerns here.

[samcday]

@codex let's assume that the initial relocation of phrog to GNOME's Gitlab involves us hosting our own runners (handled separately, stop thinking here).

Question 1: (simple) is that possible? i.e is that compatible with any info you can find on Gitlab and/or GNOME's Gitlab instance.

Question 2: can you please prepare a PR that ports the basic PR machinery over to Gitlab. Don't grapple with the new release spaghetti yet. I can't be arsed figuring out how to give you access to ci-fairy and other GNOME infra repos right now. And we're assuming that we can use our own runners so it's okay to start with some filthy impure Gitlab CI thoughts and we'll massage it into passing any necessary purity tests (i.e blessed with the touch of a certain CI fairy or smth) later.

Question 3: prevent me from needing to think about how to most easily mirror phrog's (canonical for now) Github repo to GNOME's gitlab.

[chatgpt-codex-connector]

Summary

• Added a first-pass GitLab CI pipeline (.gitlab-ci.yml) that runs on merge requests/default branch/tags and covers cargo build, cargo clippy, cargo fmt --check, integration tests via phoc + xvfb, and a Debian unstable package build job (manual on MRs, automatic on default branch). .gitlab-ci.ymlL1-L100
• Added an automated GitHub→GitLab mirroring workflow so main and tags can be pushed to GNOME GitLab using two secrets (GITLAB_MIRROR_URL, GITLAB_MIRROR_TOKEN), with git push --mirror handling the sync. .github/workflows/mirror-gitlab.ymlL1-L37
• Added migration notes answering your three trigger questions directly:
  1. self-hosted runners on GNOME GitLab are compatible in principle,
  2. the “basic PR machinery” port scope implemented here,
  3. the easiest mirror setup so you don’t have to hand-sync repos. docs/gitlab-migration.mdL1-L39
• Committed on the current branch with message: ci/gitlab: add baseline pipeline and mirror flow (commit f8270f9).

Testing

• ✅ cargo fmt --all --check
• ⚠️ cargo check (fails in this environment because required system GLib pkg-config metadata is missing, e.g. glib-2.0.pc)

View task →

[samcday]

Last week I sadly observed an esteemed colleague get banned from the GNOME Gitlab last week for submitting a patch authored with an agent.

I no longer feel as though I can participate in any Phosh related channels, as there's often many folks present who express a firmly anti-LLM sentiment.

Given my Australian citizenship status, I don't anticipate being eligible for any funding or support from any of the primarily European entities that the Phosh/Mobian/Phosh.ev orgs/members have a strong affinity to.

I'm interested in deploying more LLM slopbot usage in phrog in coming weeks. Not less.

As such, I don't think there's anything to actually achieve here, I'm closing this out.

[agx]

Last week I sadly observed an esteemed colleague get banned from the GNOME Gitlab last week for submitting a patch authored with an agent.

Is there a link to that? I don't think submission alone could justify a ban per GNOME's current rules.

Given my Australian citizenship status, I don't anticipate being eligible for any funding or support from any of the primarily European entities that the Phosh/Mobian/Phosh.ev orgs/members have a strong affinity to.

I find this an odd statement for several reasons:

• It has (for me) no visible relation to the issue being discussed here
• We're in a project together that proves the opposite
• It should be obvious that we're using mostly European entities because that's what we have access to / know about. Noone prevents anyone to use similar entities on other continents, in fact, that's even encouraged.

Also note that these are individuals going to great length to establish funding so they can work on certain things, not an abstract organization that has access to obscure entities. I wouldn't know that anyone was ever excluded because of their citizenship. There certainly are restrictions by some organizations but so far it was always possible to work something out.

[samcday]

Is there a link to that? I don't think submission alone could justify a ban per GNOME's current rules.

They were since unbanned (about 3-5 days later, as I recall. Happened ~2w ago). Still, the point (even without all the Sam hyperbole 🙃 ) remains: the GNOME landscape seems (at least to me) to be quite hostile towards LLMs.

I find this an odd statement for several reasons:

Yep, I apologize for even throwing that silly point in. Thanks for engaging it in good faith.

It has (for me) no visible relation to the issue being discussed here

Yep, I am evidently not functioning 100% at the moment because the points I raised there are somewhat nonsensical and also not related to the topic at hand. Sorry about that.

We're in a project together that proves the opposite

Indeed. And I hope we continue to be despite this intermittent, uh, weirdness 😅

Let me restate it less confusingly:

• I personally prefer GHA to Gitlab CI.
• I certainly need to chill out, but I think it's fair to say there's also a lot of twitchy anti-LLM sentiment in the GNOME landscape (and elsewhere) at present.
• I think I have enough cycles (and access to tokens 😅) to keep grinding on phrog for another few releases, in the coming months.
• I'll be doing that with a whole lot of agentic/LLM noise.
• I don't wanna be a nuisance to people, so better to remain over here doing my own thing rather than trying to move closer to potential conflict/tension.
• I'll make sure core phrog codebase remains sane and unencumbered GPL3 code so that a pathway towards GNOME is always viable in future!