fixing the access permissions for plugin maintained by unresponsive owner
105 views
Skip to first unread message
Jiri Vanek
Jan 16, 2024, 7:17:19 AM1/16/24
to jenkin...@googlegroups.com
hello!
It seems, that when there is unresponsive maintainer (about half year and more of none, or weird replies to PRs or bugs),
then it should be possible to rise a PR and become comaintainer of the plugin.
eg: https://github.com/jenkins-infra/repository-permissions-updater/pull/3721/
However that is not enough - as it is allowing to push to artifactory, however not to repo. So one can not do changes, nor approve PRs, nor to do a release.
Is that expected? If so, From above scope, what is the point of granting a permissions the jenkins-infra/repository-permissions-updater in such case? (as release can not be done anyway)
If not, what was expected? Or was something not working as expected?
Is there some mechanism how to fix unresponsive maintainer completely?
I know that this may be fragile and sensitive topic, but I belive that plugin belongs to wider community, and should not die jsut because single maintainer pass away or say that will do, but never does.
Thank you in advance,
J.
--
Jiri Vanek Mgr.
Principal QA Software Engineer
Red Hat Inc.
+420 775 39 01 09
It seems, that when there is unresponsive maintainer (about half year and more of none, or weird replies to PRs or bugs),
then it should be possible to rise a PR and become comaintainer of the plugin.
eg: https://github.com/jenkins-infra/repository-permissions-updater/pull/3721/
However that is not enough - as it is allowing to push to artifactory, however not to repo. So one can not do changes, nor approve PRs, nor to do a release.
Is that expected? If so, From above scope, what is the point of granting a permissions the jenkins-infra/repository-permissions-updater in such case? (as release can not be done anyway)
If not, what was expected? Or was something not working as expected?
Is there some mechanism how to fix unresponsive maintainer completely?
I know that this may be fragile and sensitive topic, but I belive that plugin belongs to wider community, and should not die jsut because single maintainer pass away or say that will do, but never does.
Thank you in advance,
J.
--
Jiri Vanek Mgr.
Principal QA Software Engineer
Red Hat Inc.
+420 775 39 01 09
Alexander Brandes
Jan 16, 2024, 7:37:11 AM1/16/24
to jenkin...@googlegroups.com
As seen evidently in https://github.com/jenkinsci/tap-plugin/pull/35, the maintainer is not inactive. I have forwarded the mail to the maintainer allowing some time for them to decide :)
--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/6fed3265-79d7-4e4d-989c-bdc02a3a332d%40redhat.com.
Jiri Vanek
Jan 16, 2024, 7:51:06 AM1/16/24
to jenkin...@googlegroups.com
On 1/16/24 13:36, 'Alexander Brandes' via Jenkins Developers wrote:
> As seen evidently in https://github.com/jenkinsci/tap-plugin/pull/35 <https://github.com/jenkinsci/tap-plugin/pull/35>, the maintainer is not inactive. I have forwarded the mail to the maintainer allowing some time for them to decide :)
Thank you. Unluckily, the maintainer who walk out of nowhere every half a year, just to tell you that that he well look into it is more worse then completely disappeared one. Just look to the hisotory of PRs of tap plugin! There were nice
contributions, al reviewed, and all left to rot without merging.
Anyway the generic question below, what to do, should be answered.
From https://github.com/jenkins-infra/repository-permissions-updater/pull/3721/#issuecomment-1893668857 I guess the idea what to do is clear, but the implementation itself have bugs.
> To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/1F78030A-1613-405E-B439-BEDA543B20AF%40notmyfault.dev
> <https://groups.google.com/d/msgid/jenkinsci-dev/1F78030A-1613-405E-B439-BEDA543B20AF%40notmyfault.dev?utm_medium=email&utm_source=footer>.
> As seen evidently in https://github.com/jenkinsci/tap-plugin/pull/35 <https://github.com/jenkinsci/tap-plugin/pull/35>, the maintainer is not inactive. I have forwarded the mail to the maintainer allowing some time for them to decide :)
Thank you. Unluckily, the maintainer who walk out of nowhere every half a year, just to tell you that that he well look into it is more worse then completely disappeared one. Just look to the hisotory of PRs of tap plugin! There were nice
contributions, al reviewed, and all left to rot without merging.
Anyway the generic question below, what to do, should be answered.
From https://github.com/jenkins-infra/repository-permissions-updater/pull/3721/#issuecomment-1893668857 I guess the idea what to do is clear, but the implementation itself have bugs.
>
>> On 16. Jan 2024, at 13:17, Jiri Vanek <jva...@redhat.com> wrote:
>>
>> hello!
>>
>> It seems, that when there is unresponsive maintainer (about half year and more of none, or weird replies to PRs or bugs),
>> then it should be possible to rise a PR and become comaintainer of the plugin.
>>
>> eg: https://github.com/jenkins-infra/repository-permissions-updater/pull/3721/
>>
>> However that is not enough - as it is allowing to push to artifactory, however not to repo. So one can not do changes, nor approve PRs, nor to do a release.
>>
>> Is that expected? If so, From above scope, what is the point of granting a permissions the jenkins-infra/repository-permissions-updater in such case? (as release can not be done anyway)
>> If not, what was expected? Or was something not working as expected?
>> Is there some mechanism how to fix unresponsive maintainer completely?
>>
>> I know that this may be fragile and sensitive topic, but I belive that plugin belongs to wider community, and should not die jsut because single maintainer pass away or say that will do, but never does.
>>
>> Thank you in advance,
>> J.
>>
>>
>>
>> --
>> Jiri Vanek Mgr.
>> Principal QA Software Engineer
>> Red Hat Inc.
>> +420 775 39 01 09
>>
>> --
>> You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
>> To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.
>> To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/6fed3265-79d7-4e4d-989c-bdc02a3a332d%40redhat.com.
>
> --
> You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com <mailto:jenkinsci-de...@googlegroups.com>.
>> On 16. Jan 2024, at 13:17, Jiri Vanek <jva...@redhat.com> wrote:
>>
>> hello!
>>
>> It seems, that when there is unresponsive maintainer (about half year and more of none, or weird replies to PRs or bugs),
>> then it should be possible to rise a PR and become comaintainer of the plugin.
>>
>> eg: https://github.com/jenkins-infra/repository-permissions-updater/pull/3721/
>>
>> However that is not enough - as it is allowing to push to artifactory, however not to repo. So one can not do changes, nor approve PRs, nor to do a release.
>>
>> Is that expected? If so, From above scope, what is the point of granting a permissions the jenkins-infra/repository-permissions-updater in such case? (as release can not be done anyway)
>> If not, what was expected? Or was something not working as expected?
>> Is there some mechanism how to fix unresponsive maintainer completely?
>>
>> I know that this may be fragile and sensitive topic, but I belive that plugin belongs to wider community, and should not die jsut because single maintainer pass away or say that will do, but never does.
>>
>> Thank you in advance,
>> J.
>>
>>
>>
>> --
>> Jiri Vanek Mgr.
>> Principal QA Software Engineer
>> Red Hat Inc.
>> +420 775 39 01 09
>>
>> --
>> You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
>> To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.
>> To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/6fed3265-79d7-4e4d-989c-bdc02a3a332d%40redhat.com.
>
> --
> You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
> To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/1F78030A-1613-405E-B439-BEDA543B20AF%40notmyfault.dev
> <https://groups.google.com/d/msgid/jenkinsci-dev/1F78030A-1613-405E-B439-BEDA543B20AF%40notmyfault.dev?utm_medium=email&utm_source=footer>.
Alexander Brandes
Jan 16, 2024, 7:53:35 AM1/16/24
to jenkin...@googlegroups.com
I have reached out to the maintainer will keep you posted with their decision.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/1F78030A-1613-405E-B439-BEDA543B20AF%40notmyfault.dev.
Alexander Brandes
Jan 16, 2024, 8:21:46 AM1/16/24
to jenkin...@googlegroups.com
The maintainer responded with a reasonable explanation and objected to your adoption request: https://github.com/jenkinsci/tap-plugin/pull/36#issuecomment-1893725271
Thanks for understanding.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/785B4889-CA83-4DDB-AF9D-87C02176F3D0%40notmyfault.dev.
Jiri Vanek
Jan 17, 2024, 10:45:51 AM1/17/24
to jenkin...@googlegroups.com
On 1/16/24 14:21, 'Alexander Brandes' via Jenkins Developers wrote:
> The maintainer responded with a reasonable explanation and objected to your adoption request: https://github.com/jenkinsci/tap-plugin/pull/36#issuecomment-1893725271 <https://github.com/jenkinsci/tap-plugin/pull/36#issuecomment-1893725271>
>
> Thanks for understanding.
Thanx a lot!
Fair enough, I will ping you after another 6 months of inactivity.
J.
>
>> On 16. Jan 2024, at 13:53, 'Alexander Brandes' via Jenkins Developers <jenkin...@googlegroups.com> wrote:
>>
>> I have reached out to the maintainer will keep you posted with their decision.
>>
>>> On 16. Jan 2024, at 13:36, 'Alexander Brandes' via Jenkins Developers <jenkin...@googlegroups.com> wrote:
>>>
>>> As seen evidently in https://github.com/jenkinsci/tap-plugin/pull/35 <https://github.com/jenkinsci/tap-plugin/pull/35>, the maintainer is not inactive. I have forwarded the mail to the maintainer allowing some time for them to decide :)
>> On 16. Jan 2024, at 13:53, 'Alexander Brandes' via Jenkins Developers <jenkin...@googlegroups.com> wrote:
>>
>> I have reached out to the maintainer will keep you posted with their decision.
>>
>>> On 16. Jan 2024, at 13:36, 'Alexander Brandes' via Jenkins Developers <jenkin...@googlegroups.com> wrote:
>>>
>>>
>>>> On 16. Jan 2024, at 13:17, Jiri Vanek <jva...@redhat.com> wrote:
>>>>
>>>> hello!
>>>>
>>>> It seems, that when there is unresponsive maintainer (about half year and more of none, or weird replies to PRs or bugs),
>>>> then it should be possible to rise a PR and become comaintainer of the plugin.
>>>>
>>>> eg: https://github.com/jenkins-infra/repository-permissions-updater/pull/3721/
>>>>
>>>> However that is not enough - as it is allowing to push to artifactory, however not to repo. So one can not do changes, nor approve PRs, nor to do a release.
>>>>
>>>> Is that expected? If so, From above scope, what is the point of granting a permissions the jenkins-infra/repository-permissions-updater in such case? (as release can not be done anyway)
>>>> If not, what was expected? Or was something not working as expected?
>>>> Is there some mechanism how to fix unresponsive maintainer completely?
>>>>
>>>> I know that this may be fragile and sensitive topic, but I belive that plugin belongs to wider community, and should not die jsut because single maintainer pass away or say that will do, but never does.
>>>>
>>>> Thank you in advance,
>>>> J.
>>>>
>>>>
>>>>
>>>> --
>>>> Jiri Vanek Mgr.
>>>> Principal QA Software Engineer
>>>> Red Hat Inc.
>>>> +420 775 39 01 09
>>>>
>>>> --
>>>> You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.
>>>> To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/6fed3265-79d7-4e4d-989c-bdc02a3a332d%40redhat.com.
>>>
>>>
>>> --
>>> You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
>>> To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com <mailto:jenkinsci-de...@googlegroups.com>.
>>>> On 16. Jan 2024, at 13:17, Jiri Vanek <jva...@redhat.com> wrote:
>>>>
>>>> hello!
>>>>
>>>> It seems, that when there is unresponsive maintainer (about half year and more of none, or weird replies to PRs or bugs),
>>>> then it should be possible to rise a PR and become comaintainer of the plugin.
>>>>
>>>> eg: https://github.com/jenkins-infra/repository-permissions-updater/pull/3721/
>>>>
>>>> However that is not enough - as it is allowing to push to artifactory, however not to repo. So one can not do changes, nor approve PRs, nor to do a release.
>>>>
>>>> Is that expected? If so, From above scope, what is the point of granting a permissions the jenkins-infra/repository-permissions-updater in such case? (as release can not be done anyway)
>>>> If not, what was expected? Or was something not working as expected?
>>>> Is there some mechanism how to fix unresponsive maintainer completely?
>>>>
>>>> I know that this may be fragile and sensitive topic, but I belive that plugin belongs to wider community, and should not die jsut because single maintainer pass away or say that will do, but never does.
>>>>
>>>> Thank you in advance,
>>>> J.
>>>>
>>>>
>>>>
>>>> --
>>>> Jiri Vanek Mgr.
>>>> Principal QA Software Engineer
>>>> Red Hat Inc.
>>>> +420 775 39 01 09
>>>>
>>>> --
>>>> You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.
>>>> To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/6fed3265-79d7-4e4d-989c-bdc02a3a332d%40redhat.com.
>>>
>>>
>>> --
>>> You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
>>> To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/1F78030A-1613-405E-B439-BEDA543B20AF%40notmyfault.dev
>>> <https://groups.google.com/d/msgid/jenkinsci-dev/1F78030A-1613-405E-B439-BEDA543B20AF%40notmyfault.dev?utm_medium=email&utm_source=footer>.
>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
>> To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com <mailto:jenkinsci-de...@googlegroups.com>.
>>
>> --
>> You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
>> To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/785B4889-CA83-4DDB-AF9D-87C02176F3D0%40notmyfault.dev
>> <https://groups.google.com/d/msgid/jenkinsci-dev/785B4889-CA83-4DDB-AF9D-87C02176F3D0%40notmyfault.dev?utm_medium=email&utm_source=footer>.
>
> --
> You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com <mailto:jenkinsci-de...@googlegroups.com>.
> --
> You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
> To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/9D0DB105-260E-4D9F-9A28-863B4A0DB18D%40notmyfault.dev
> <https://groups.google.com/d/msgid/jenkinsci-dev/9D0DB105-260E-4D9F-9A28-863B4A0DB18D%40notmyfault.dev?utm_medium=email&utm_source=footer>.
Reply all
Reply to author
Forward
0 new messages