Re: Defining the future of the packager workflow in Fedora

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.


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

Simo.

-- 
Simo Sorce
RHEL Crypto Team
Red Hat, Inc



_______________________________________________
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




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux