On Wed, Oct 2, 2019 at 3:18 PM Neal Gompa <ngompa13(a)gmail.com> wrote:
On Wed, Oct 2, 2019 at 2:45 PM Colin Walters <walters(a)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!