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.