Re: [GitHub] Third-party application approval request for Python Packaging Authority

[Paul Moore]

I just saw this request. I took a quick look at the Tidelift website,
but I'm not clear on what it provides or what implications approving
it would have. Can someone clarify what this is (presumably Bernat
would be best able to do so)?

Paul


On Sun, 12 Jan 2020 at 11:18, Python Packaging Authority
<nor...@github.com> wrote:
>
> @gaborbernat has requested approval for a third-party application to access Python Packaging Authority organization resources via the GitHub API:
>
> "Tidelift" from Tidelift
>
> Until it is approved, this application will have no access to private resources and will have read-only access to public resources belonging to your organization.
>
> You may approve or deny this request here:
>
> https://github.com/orgs/pypa/policies/applications/293917
>
> Learn more about organization application access policies in this GitHub Help article:
>
> https://help.github.com/articles/about-third-party-application-restrictions/

[Sviatoslav Sydorenko]

Hi Paul,

нд, 12 січ. 2020 о 12:27 Paul Moore <p.f....@gmail.com> пише:

>
> I just saw this request. I took a quick look at the Tidelift website,
> but I'm not clear on what it provides or what implications approving
> it would have. Can someone clarify what this is (presumably Bernat
> would be best able to do so)?

I can answer this question. Tidelift is a startup that tries to solve
the problem of paying FOSS maintainers.
They offer a sort of FOSS subscription to enterprise customers.
Maintainers can register there and get payouts for their packages
based on the amount of subscribers
Tidelift has for the given project.

Lifters (maintainers) are supposed to execute a series of tasks like
properly marking which versions
of their packages get security updates, which are dangerous, posting
release notes, confirming licenses
and so on.

One of the tasks was to add their GitHub App which was apparently used
to work around GitHub API's
rate limits. But recently they announced that it's no longer necessary
and they're going to get rid of that
task also allowing people to uninstall the integration.

Ref: https://forum.tidelift.com/t/removing-task-install-github-app/334

So I'd say that you can safely ignore the request for adding this GitHub App.

P.S. AFAIK among PyPA projects at least setuptools is enrolled in the
Tidelift's program.


--
Kind regards,

Sviatoslav Sydorenko
email: sviatoslav+/nospam/~@sydorenko.org.ua

---
https://useplaintext.email/
() ascii ribbon campaign - against html e-mail
/\ www.asciiribbon.org - against proprietary attachments
---

[Paul Moore]

On Sun, 12 Jan 2020 at 15:15, Sviatoslav Sydorenko
<svyat...@sydorenko.org.ua> wrote:

> I can answer this question. Tidelift is a startup that tries to solve
> the problem of paying FOSS maintainers.
> They offer a sort of FOSS subscription to enterprise customers.
> Maintainers can register there and get payouts for their packages
> based on the amount of subscribers
> Tidelift has for the given project.

Thanks. That mostly matches what I understood from their website. What
wasn't clear to me was why they needed a GitHub app, and more so, why
it had to be registered against the whole PyPA organisation, rather
than against individual projects.

> Lifters (maintainers) are supposed to execute a series of tasks like
> properly marking which versions
> of their packages get security updates, which are dangerous, posting
> release notes, confirming licenses
> and so on.

That makes sense - but obviously, whether to commit to this sort of
thing would be a per-project decision, not something PyPA-wide.

> One of the tasks was to add their GitHub App which was apparently used
> to work around GitHub API's
> rate limits. But recently they announced that it's no longer necessary
> and they're going to get rid of that
> task also allowing people to uninstall the integration.
>
> Ref: https://forum.tidelift.com/t/removing-task-install-github-app/334
>
> So I'd say that you can safely ignore the request for adding this GitHub App.

Cool, thanks for explaining.

Paul

[Sviatoslav Sydorenko]

нд, 12 січ. 2020, 16:34 користувач Paul Moore <p.f....@gmail.com> пише:

What wasn't clear to me was why they needed a GitHub app, and more so, why
it had to be registered against the whole PyPA organisation, rather
than against individual projects.

By design, GitHub Apps are installed into orgs or individual user accounts. You cannot "install" it into a repo. You can, however, limit its access to just one repo on the installation level.

When non-admin users request to install an App, they are offered to choose if they want it for specific repos. But from my experience admins don't see this in the notifications. Maybe it's just a UX bug on GitHub.

> Lifters (maintainers) are supposed to execute a series of tasks like
> properly marking which versions
> of their packages get security updates, which are dangerous, posting
> release notes, confirming licenses
> and so on.

That makes sense - but obviously, whether to commit to this sort of
thing would be a per-project decision, not something PyPA-wide.

Yep, except as per limitation above, it affects the org too.

See, when a GitHub App is installed, this installation entity is a bond between that App and the org. App then acquires a token for such installation and can use it to query things. The interesting part is that every installation gets a rate limit of 5000 requests per hour plus some bonus requests on top of the org is big.

--Sviatoslav.

Sent from my phone, please pardon any typos.

[Paul Moore]

On Sun, 12 Jan 2020 at 15:48, Sviatoslav Sydorenko
<svyat...@sydorenko.org.ua> wrote:
> Yep, except as per limitation above, it affects the org too.

Odd that if setuptools is part of Tidelift, that they didn't have to
install the app PyPA-wide, then...

Never mind, at this point it's just my own curiosity (and I certainly
don't have any objections to projects signing up with Tidelift!)

Paul

[Sviatoslav Sydorenko]

нд, 12 січ. 2020 о 17:16 Paul Moore <p.f....@gmail.com> пише:

>
> Odd that if setuptools is part of Tidelift, that they didn't have to
> install the app PyPA-wide, then...

Because of the task execution not being strongly enforced. Many folks
postpone doing them or sometimes don't really have ability to solve
things. Plus some tasks aren't mandatory at all.

[Pradyun Gedam]

Okay, as per the discussion, it looks like this isn't needed so I've "denied" the request that was made.

Best,

Pradyun

--
You received this message because you are subscribed to the Google Groups "pypa-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pypa-dev+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/pypa-dev/CAFYONRAZ9wkRzjqNe6kXqe34KCohVj6CV1HGFq3xsLJ%3D9o9Bmw%40mail.gmail.com.

[Sumana Harihareswara]

Thanks Pradyun.

> Odd that if setuptools is part of Tidelift, that they didn't have to
> install the app PyPA-wide, then...
>

> Never mind, at this point it's just my own curiosity (and I certainly
> don't have any objections to projects signing up with Tidelift!)
> > Paul

I believe Jason R. Coombs set that up. Jason, I wonder whether you'd
like to talk about setuptools's setup with Tidelift and how it is
organized? And whether you think more PyPA projects should sign up?

-Sumana

[Jason R. Coombs]

I connected with the founders of Tidelift at PyCon in 2018. I like the model they’ve designed and excited about the prospects of creating a sustainable funding model for open-source work. I particularly laud their goal to allow popular projects that power profitable commercial applications to share in the value they generate through those applications. I enthusiastically support their efforts and would do so even if I were not benefiting from them. I appreciate the way they’ve attempted to align incentives and create a fair and reasonable system to help keep the software ecosystems healthy.

For Setuptools, that was the first project I enrolled with and the most prominent project I support, but I also maintain 11 other projects popular enough to receive funding through Tidelift. There’s a part of me that hopes I can retire one day on a modest income for the open source projects and that I can spend more time advancing them.

As the prime maintainer of Setuptools, I enrolled the project, but I involved the other key maintainers in the conversation.

As to whether other projects should sign up, I say yes. I’d recommend that each project have a prime maintainer and that individual should direct the income from Tidelift however they see fit, whether that means keeping it for themselves, sharing it with other maintainers, or donating it to charity. The important thing is that if that person steps down from maintainership, they should also be prepared to hand off the Tidelift project. It’s conceivable that a project could join tidelift as a committee or similar, but I wouldn’t recommend it.

There are some responsibilities as a lifter, but they’re modest compared to the responsibilities of project maintenance. Still, I’d encourage any project’s maintainer to explore the possibility.

As for “why did Setuptools not have to install the app”, I don’t know the answer to that question. I don’t see it as a task for the project. I don’t recall if I attempted to install an app for Tidelift before, or if perhaps my projects have not demanded it due to having been enrolled in the program early. Regardless, I don’t have any visibility into the tradeoffs or consequences of having enabled the app or not.

> --
> You received this message because you are subscribed to the Google Groups "pypa-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to pypa-dev+u...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/pypa-dev/b975bbe4-a959-1e02-9cb7-b0a6bb4f3a0d%40changeset.nyc.