Re: Defining the future of the packager workflow in Fedora

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

 



On Thu, 2019-09-26 at 18:26 +0200, Ben Rosser wrote:
> On Thu, Sep 26, 2019 at 5:29 PM Pierre-Yves Chibon <pingou@xxxxxxxxxxxx> wrote:
> > On Thu, Sep 26, 2019 at 04:46:32PM +0200, Ben Rosser wrote:
> > > On Thu, Sep 26, 2019 at 4:29 PM Pierre-Yves Chibon <pingou@xxxxxxxxxxxx> wrote:
> > > > There is a clear initial rejection of a PR-only contribution model. I hear that
> > > > and that may mean that we never go this way. I'm honestly fine with that :)
> > > > I do want to see why that is a show-stopper and if we can find ways to not have
> > > > it be a show-stopper.
> > > > 
> > > > When we work on upstream projects, I think it's pretty standard now to always go
> > > > via PRs, even for your own branch.
> > > > So that tests are run, so that other member of the community can see, comment,
> > > > review the change.
> > > > What is so different in Fedora that we cannot move to this model?
> > > > Is it a tooling issue?
> > > > Is it something else?
> > > 
> > > Most packages in Fedora are effectively one-person projects (modulo
> > > rebuild scripts and other automated tooling). My experience when
> > > working on a personal project is that I don't use PRs for changes even
> > > if I do develop a change in a branch, rather than master; it's a lot
> > > of unnecessary overhead. There are no "other members" of the
> > > community. No one is reviewing the change other than me.
> > 
> > Would this change if the PR was automatically tested for you without you having
> > to do anything?
> 
> No, not really? For a personal project, a continuous integration
> system can be set up to run tests on _all_ of my commits, regardless
> of whether or not they're to master or to a development branch. What's
> the benefit of creating a pull request here?
> 
> That being said, packages are slightly different. If it wasn't
> necessary to use the web interface to make a pull request and if
> fedpkg could do it for me [1], and automatically merge it when the
> build succeeds... that might be nice. But if manual work is required
> to create a pull request-- filling out a form on Pagure, manually
> forking a project, etc.-- I think it's a lot of overhead. And I
> wouldn't want to do it for most of my packages.
> 
> Ben Rosser
> 
> [1] And, in an ideal world, do it without needing an API key but
> rather authenticating to Pagure via some other mechanism that doesn't
> require manually downloading a key, but I digress...
If we are talking packager quality of live imporvements, I would vote for this as one of the
improvements - unification of the ~5 methods of authetication one might need to apply when working
with fedpkg at the moment.

Ideally there should be one method, most likely kerberos, that autheticates the user with FAS
and should be used for everything. While its true that some of the services (Pagure, COPR) use
API keys, this should be an implementation detail in this case. You authorize Pagure & COPR
with your FAS account once (or possibly this happens automatically) and don't have to care
about API keys unless you are wiritng some automated tool that needs them.


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