----- Original Message ----- > From: "Fabio Valentini" <decathorpe@xxxxxxxxx> > To: "Development discussions related to Fedora" <devel@xxxxxxxxxxxxxxxxxxxxxxx> > Sent: Monday, January 25, 2021 4:43:21 PM > Subject: Policy proposal (draft): Don't push knowingly broken or work-in-progress work to dist git > > On Mon, Jan 25, 2021 at 4:37 PM Stephen Gallagher <sgallagh@xxxxxxxxxx> > wrote: > > > > On Mon, Jan 25, 2021 at 10:31 AM Miro Hrončok <mhroncok@xxxxxxxxxx> wrote: > > > > > > On 25. 01. 21 16:19, Stephen Gallagher wrote: > > > > I'm fully in favor of this and I'd really like to see us add some > > > > degree of CI gating to support it. > > > > > > Note that unfortunately CI gating happens too late. It has no capability > > > to > > > block commits that fail to build, because it only tests successful builds > > > and > > > because it only tests already pushed changes. CI on Pull Requests can > > > solve > > > this, but many packagers seem to be very much agianst the idea of sending > > > PRs to > > > packages they maintain themselves :( > > > > > > > There are still ways around this; we could disallow direct pushes to > > release branches. > > > > Yes, there are always going to be people who reject any new approach > > we might take, but we should carefully consider whether "some/many > > packagers are mildly annoyed" exceeds the potential gains inherent in > > fewer broken builds and composes. > > For those few of us who maintain hundreds-thousands of packages, > having everything go via a Pull Request is just not scalable as things > are right now. > > If packaging tools can "hide the details" around this in a reliable > way so that packagers don't see what happens behind the scenes, then > we can talk. > > But that would involve at least six new steps that would've to be > automated: 1) Creating a fork on src.fp.o (plus error handling around > already existing forks), 2) Cloning the fork instead of the main repo, > 3) Automatically creating a PR after a git push, 4) Automatically > merging the PR if CI passes, 5) Deleting the fork, 6) Automatically > building the package in koji ... FWIW I have already created this tooling (and more) for maintaining my rubygem-* packages (and also creating updates). It can be generalized of course. :) Example PR: https://src.fedoraproject.org/rpms/rubygem-benchmark-ips/pull-request/1 I'll be presenting this on DevConf.CZ. (No external git yet, sorry.) Pavel > > Fabio _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
