On Wed, Oct 2, 2019 at 3:18 PM Neal Gompa <ngomp...@gmail.com> wrote: > > On Wed, Oct 2, 2019 at 2:45 PM Colin Walters <walt...@verbum.org> 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 > > > I'd like to require review, but it does seem like a prerequisite is moving > > away from the one-repo-per-package model. > > No it isn't. A pre-requisite would be that we'd require maintainer > teams, and have to make those first-class in Fedora (rather than > barely third-class as they are now). Besides, I've worked in > distributions where you have monorepo package source control, and it's > arguably worse. Rolling through the revisions is difficult, dealing > with searching through the tree is hard, and features like git blame > basically don't work (they time out more often than they return > results). Meaning that we'd need groups and subgroups that have ACL > inheritance for projects, among other things. >
Erk, this is not worded in the right order... I mean this instead: No it isn't. A pre-requisite would be that we'd require maintainer teams, and have to make those first-class in Fedora (rather than barely third-class as they are now). Meaning that we'd need groups and subgroups that have ACL inheritance for projects, among other things. Besides, I've worked in distributions where you have monorepo package source control, and it's arguably worse. Rolling through the revisions is difficult, dealing with searching through the tree is hard, and features like git blame basically don't work (they time out more often than they return results). > 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... > > > -- > 真実はいつも一つ！/ Always, there's only one truth! -- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
