Re: Defining the future of the packager workflow in Fedora

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

 



On Wed, Oct 2, 2019 at 3:18 PM Neal Gompa <ngompa13@xxxxxxxxx> 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
>
> > 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@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