On Wed, 2019-10-02 at 15:57 -0400, Colin Walters wrote: > > On Wed, Oct 2, 2019, at 3:18 PM, Neal Gompa wrote: > > On Wed, Oct 2, 2019 at 2:45 PM Colin Walters <walters@xxxxxxxxxx> wrote: > > > > > > > > > > > > On Wed, Oct 2, 2019, at 1:40 PM, Fabio Valentini wrote: > > > > > > > As others in the thread have pointed out, mandatory pull requests just > > > > make no sense for most single-maintainer projects, which most packages > > > > probably are. > > > > > > Well, a lot of this relates to what the *merge policy* is. If a PR submitter can merge their own PRs, and there's a mechanism to do "merge when tests pass" (this is an important aspect), then submitting a PR can be just about as equally ergonomic as `git push`. > > > In OpenShift we use Prow, which has the latter; I really like it. However we also *require* peer review (submitters can't merge their own PRs). > > > > Unfortunately, it doesn't scale for the large number of packages we > > have. Pull requests would work if we had mergify[1] working on > > Dist-Git, otherwise I can't see how it'd work. > > > > [1]: https://github.com/Mergifyio/mergify-engine > > Yes, I mentioned Prow which does something similar. https://github.com/kubernetes/test-infra/tree/master/prow > Which as I noted we use today in OpenShift and are moving to use in the CoreOS group as well. I do not know how it is working today, but when I was working on it it was a real chore as PRs would regularly flake. Most of the time it was openshift/kube's code fault, other times it wasn't and would cause a lot of overhead for teams to babysit PRs that should have just merged. > > I'm surprised you didn't realize these issues. You've examined Git > > very deeply and you should be more than aware of how bad of idea it > > would be to use a monorepo for package sources. We don't have separate > > Git repos per package for no reason... > > https://github.com/projectatomic/rpmdistro-gitoverlay/blob/master/doc/reworking-fedora-releng.md#unified-source-and-pr-driven-workflow > links to a number which do it today. You're right that there are > tradeoffs; I think the best is probably something closer to what > OpenEmbedded is doing with "layered" repos, not one gigantic dist-git > repo. > > It certainly seems to me the current Fedora setup is basically just > inertia from the first dist-cvs -> dist-git conversion; no one really > in the intervening time has had the power/will to change the > underlying layers, just add new layers on top. Both are true probably, there is inertia and the tradeoffs probably were not worth the change so far. Simo. -- Simo Sorce RHEL Crypto Team Red Hat, Inc _______________________________________________ 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
