I think it would be a great improvement to the current process. Maybe it is 
better to add a new list to repository-permissions-updater 
<https://github.com/jenkins-infra/repository-permissions-updater/> files so 
that we can somehow credit the emeritus maintainers on the plugin site once 
https://issues.jenkins-ci.org/browse/WEBSITE-658 is implemented ("Use 
Repository Permission Updater as a source of the maintainer info").

In my case I also have several plugins which I de-facto maintain as 
"emeritus maintainer" (read as: "I step in when something is really broken 
there, but do not maintain it on a regular basis").
Maybe it is a use-case for emeritus maintainers retaining their release 
permissions.

P.S: It might be also good to explicitly mark plugins for adoption. Now it 
can be done by just setting a GitHub topic: 
https://jenkins.io/doc/developer/plugin-governance/adopt-a-plugin/

BR, Oleg

On Monday, March 2, 2020 at 12:06:21 PM UTC+1, Marky Jackson wrote:
>
> I like this idea so a +1 from me.
>
>
> On Mar 2, 2020, at 3:02 AM, Stephen Connolly <[email protected] 
> <javascript:>> wrote:
>
> 
> Can we add a concept of emeritus maintainer... by just commenting out 
> their username in the corresponding repository-permissions-updater yaml 
> file?
>
> An emeritus maintainer would be indicating that they are no longer active, 
> but if they want to re-activate they do not need to wait for existing 
> maintainers to approve... or in the case of unmaintained plugins they do 
> not need to wait for the claim-ownership period.
>
> If all maintainers of a plugin are emeritus and someone wants to claim 
> ownership then the emeritus maintainers can short-circuit the transfer of 
> ownership rather than having to wait out the full period.
>
> My use case is that I currently wish to be marked emeritus for all plugins 
> that I am a maintainer of *except*:
>
> - gitea (until I get the gitea token auth implemented, then I'll be 
> looking for someone to adopt it)
> - impersonation (until I decide whether to release it or kill it)
> - mock-load-builder (needed for work commitments)
> - random-job-builder (needed for work commitments)
> - metrics (needed for work commitments)
>
> I may need to step back on the other plugins at shorter notice, so it 
> would be annoying to have to go though recovering maintainer status... 
> which is why I have not dropped those permissions.
>
> I do think we need to be able to reflect better the case where maintainers 
> are not actively maintaining but do not want to drop permissions because it 
> could trigger the plugin as completely unmaintained and thus a lot harder 
> to reclaim... yet by not dropping permissions it leaves others who might be 
> interested in adopting the impression that the plugin is actively maintained
>
> -- 
> 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 [email protected] <javascript:>.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/jenkinsci-dev/CA%2BnPnMw0XFtd1PR00yuhJJ-q8B0s6LqHK%3DResjH8P%3Di%3DJ%2B-MTw%40mail.gmail.com
>  
> <https://groups.google.com/d/msgid/jenkinsci-dev/CA%2BnPnMw0XFtd1PR00yuhJJ-q8B0s6LqHK%3DResjH8P%3Di%3DJ%2B-MTw%40mail.gmail.com?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 [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/4bfb285d-ad86-42f0-9641-9e555d44a2dd%40googlegroups.com.

Reply via email to