On Wed, Oct 2, 2019, at 3:18 PM, Neal Gompa 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
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'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/rew...
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.