You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Upstream maintainer's permission and requests for packages #2573
We currently require people that send patches for new third-party packages to get permission from upstream maintainers. What should we do if the upstream maintainers do not reply, like for example in #2384? I suggest that when there is no response for 14 days, we accept stubs as if upstream gave their permission.
On a related note: We have quite a few issues asking for third-party packages, but with no activity. I am not sure how useful it is to keep these issues around, unless there is some discussion or a link to an upstream maintainer's permission in the issue or someone is actively working on the stubs. With our current direction, we potentially want stubs for all pypi packages that don't ship their own, so I suggest we add a comment to the effect of "we accept contributions, ask upstream before starting" to such tickets and close them after 14 days if there is no more activity.
I'm in favor of the idea, but maybe 14 days is a bit too aggressive, since people are often on vacation for more than two weeks and may not be keeping up with email. I'd suggest waiting for 21 or 28 days.
If we had this rule, it could be easier to motivate somebody (such as me) to ask a significant number of widely used third-party packages for permission to add stubs to typeshed.
We could also add a file to typeshed with a list of third-party packages that have been approved for inclusion in typeshed (or where we got no response), and add a prominent link to the list somewhere.
close them after 14 days if there is no more activity.
I assume that this means closing the issue asking for permission in the upstream issue tracker (just asking for clarification).
close them after 14 days if there is no more activity.
I meant closing issued tagged with type-stub-request if all they ask is "it would be great to have stubs for package foo", without any meaningful discussion after that. I think we should leave upstream requests for permission open indefinitely, even if we already added the stubs. (In that case we should leave a note in the upstream issue about that, though.) Let the upstream maintainers worry about closing it.
Edit: I am fine with a longer waiting time, say 21 days. But the longer we wait, the easier people are discouraged to contribute.
Activity
JukkaL commentedon Oct 31, 2018
I'm in favor of the idea, but maybe 14 days is a bit too aggressive, since people are often on vacation for more than two weeks and may not be keeping up with email. I'd suggest waiting for 21 or 28 days.
If we had this rule, it could be easier to motivate somebody (such as me) to ask a significant number of widely used third-party packages for permission to add stubs to typeshed.
We could also add a file to typeshed with a list of third-party packages that have been approved for inclusion in typeshed (or where we got no response), and add a prominent link to the list somewhere.
I assume that this means closing the issue asking for permission in the upstream issue tracker (just asking for clarification).
srittau commentedon Oct 31, 2018
I meant closing issued tagged with type-stub-request if all they ask is "it would be great to have stubs for package foo", without any meaningful discussion after that. I think we should leave upstream requests for permission open indefinitely, even if we already added the stubs. (In that case we should leave a note in the upstream issue about that, though.) Let the upstream maintainers worry about closing it.
Edit: I am fine with a longer waiting time, say 21 days. But the longer we wait, the easier people are discouraged to contribute.
Accept upstream stubs when receiving no response
Accept upstream stubs when receiving no response (#2608)
Accept upstream stubs when receiving no response (python#2608)