|
|
|
|
|
|
by carreau
1763 days ago
|
|
|
I'm not using debian that much anymore, but I'd be happy to make any changes upstream to make it easier on debian. When possible I try to have reproducible builds (https://reproducible-builds.org/) that respect SOURCE_DATE_EPOCH extracted from the commit datetime. At least for IPython I alway build twice to make sure the sha is identical. I'd also be happy to have a way to signal to debian that there is a new release instead of having QA watch have to scan things regularly. |
|
|
That would be great! Unfortunately the current forging model is very centralized, centered around the UX of private companies with their internal teams and little (if any) outside cooperation. That's why we need decentralized forging systems: https://staticadventures.netlib.re/blog/decentralized-forge/
There's an ongoing 5000€ bounty for implementing ForgeFed federation (based on ActivityPub) on top of Gitea, in case you know people familiar with golang/ActivityPub who'd like to help.
Also worth noting, i feel like there is room for experimenting with anti-authoritarian forging where you don't need upstream permission to receive webhooks (or other update notification). I've started experimenting with this but still pre-alpha quality: https://thunix.net/~southerntofu/forge/
> All of these CI/CD plateforms consider the repository itself should contain the tasks to be run, for example in a .gitlab-ci.yml file. This top-down deployment model is well suited to an organization controling the whole of its software supply chain, but is a severe restriction to 3rd party involvement, which mostly hinders volunteer-run projects.
> The forge suite adopts an opposite approach, where anyone can receive updates from remote repositories, and run the tasks they wish. This allows anyone within or without your projects to setup new test suites, benchmarks, and integrations. The applications are endless and should benefit your projects in many ways.