On Wed, Oct 2, 2019 at 4:06 PM Simo Sorce <simo@xxxxxxxxxx> wrote: > > 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. > Kubernetes' project infrastructure is probably a very bad example, as it's primarily geared to support the CNCF's crazy process rather than helping developers. > > > > 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. > Dist-CVS is effectively a monorepo, just as Mageia's Dist-SVN is. Those SCMs have the advantage of supporting subtree checkouts as a first-class operation, and don't do proper "clones" like Git and Mercurial do. That makes it *much* simpler to deal with. I think layered repos would not be significantly better than just having groups and subgroups to organize the package sources git repos. You'd get the same organizational benefits, anyway. -- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ 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
