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(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 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/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.
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