Hi Craig, Thanks a lot for the proposal! I agree with others that we should probably make it a JEP.
I would be also interested to make some changes in the adoption process, especially to simplify it for plugins which are obviously non-maintained. I rather prefer to keep ownership requests in the mailing list so that other developers can see them and comment if needed (e.g. request ownership as well, vote for and against ownership transfer, etc.). JIRA requests can be also easily lost in the inbox if there is no pings. E.g. I cannot physically process all notifications I receive even after doing a lot of work on setting up filters. I am currently working on a JEP for hosting 3rd-party components used in Jenkins, and I also have an adoption section there (link <https://docs.google.com/document/d/1GRwJCfybnW8X273cPhOc2q4kdpqocX2zm_857DBGCY8/edit#heading=h.oqgvxp58dtwz>). If there is a JEP submitted for this proposal, I am interested to follow similar process in that components. I would be especially interested to allow requesting ownership via pull requests and JIRA issues (see the proposal). Maybe we could also improve the process to simplify adoption requests for abandoned plugins which have no adoption label, e.g.: - The plugin can be considered as open for adoption if *all* conditions below are met... - All plugin maintainers were inactive in GitHub for 1 years or above (Web UI check) - All plugin maintainers were inactive in JIRA for 2 years - All plugin maintainers were inactive in Jenkins mailing lists for 2 years or above - There are outstanding issues and pull requests where a feedback from maintainers was requested - The plugin can be considered as open for adoption if the maintainer explicitly confirmed to be no longer active in the Jenkins project in a public channel - IIRC bap2000, harebrain and gboissinot have replied something like that at some point It's especially important IMO since people requesting to become maintainers > may often be somewhat newcomers that won't necessarily dare asking twice if > we miss or forget the request. > Actually I would not consider it as a huge deal. If the requesters lose interest and do not ping if the request gets stuck, probably they are not that interested in the plugin. But it does not excuse us for missing requests, of course BR, Oleg On Friday, August 24, 2018 at 4:01:26 PM UTC+2, slide wrote: > > Using the hosting project would be great. If there is anything we want to > do in terms of automating the flow, I'd be interested in helping there too. > > On Fri, Aug 24, 2018, 05:54 Baptiste Mathus <[email protected] <javascript:>> > wrote: > >> I like that idea, and I agree having a clearer way to track ongoing >> requests, so that they're not forgotten would be great. It's especially >> important IMO since people requesting to become maintainers may often be >> somewhat newcomers that won't necessarily dare asking twice if we miss or >> forget the request. >> >> I think using the HOSTING project kind of makes sense, but I'm not >> feeling strongly for the actual JIRA project to use for this. I think we >> want to get feedback from Slide (CCed) here as he's the now one clearly >> doing the heavy lifting on the HOSTING process, so if we're going to add >> /requests/ that will appear in his bucket, he should be aware before we do. >> >> And I think that we should have a JEP for this, yes. I think we somehow >> could have a global JEP for the hosting process, then have a part on >> adoption, but that would make this a much bigger task which likely would >> kill the effort. IMO let's just have a smaller process JEP, and we'll use >> the existing process to deprecate it once/if we include it some day in a >> bigger JEP to describe the whole hosting/plugin handling process. (BTW, >> might be something interesting to do during JW/DW. IIUC Daniel started to >> do this during FOSDEM, as of >> https://jenkins.io/doc/developer/publishing/requesting-hosting/ but I >> think it's not finished as I would imagine once fully done, we'd blank >> https://wiki.jenkins.io/display/JENKINS/Hosting+Plugins or add a link to >> jenkins.io). >> >> -- Baptiste >> >> >> Le mar. 21 août 2018 à 18:54, Craig Rodrigues <[email protected] >> <javascript:>> a écrit : >> >>> *PROBLEM* >>> >>> - Over time, Jenkins plugin maintainers need to change as the >>> original maintainer may need to move on to other work. >>> - https://wiki.jenkins.io/display/JENKINS/Adopt+a+Plugin outlines >>> the process for adopting a plugin. It mentions that the Jenkins >>> developer >>> mailing list should be e-mailed to start the process. >>> - Due to the popularity of Jenkins, the mailing lists receive a lot >>> of messages. For casual Jenkins users who maintain plugins, it is easy >>> to >>> miss these types of e-mails. >>> >>> >>> *PROPOSAL* >>> >>> - Plugins need to change owners and there needs to be a clear >>> adoption process which can be tracked. >>> - I propose that JIRA be used as the primary mechanism by which the >>> plugin adoption process is tracked, from proposal to adopt a plugin, all >>> the way to when the plugin is adopted. >>> - Email would be used as a secondary mechanism. If someone e-mails >>> the Jenkins mailing list, they should be directed to the Adopt+a+Plugin >>> JIRA page, which would instruct them to file a JIRA ticket. >>> >>> *DETAILS* >>> >>> - When someone wants to adopt a plugin, they should file a JIRA >>> ticket. >>> - They should set the Component field to the name of the plugin >>> - In addition, they must set a tag in JIRA to something like " >>> *adopt"* >>> - The current plugin maintainer will receive an e-mail from JIRA. >>> If there are multiple plugin maintainers, they should be mentioned via >>> the >>> "@" mechanism in JIRA. >>> - If the plugin owner does not respond to the JIRA ticket within 3 >>> weeks (enough time to cover reasonable vacation time, sick time, >>> emergency), then the plugin can be adopted. >>> - Plugin authors are also able to file a JIRA ticket with the " >>> *adopt*" tag, and mention that they want to give up maintainership >>> of the plugin >>> - By doing things in JIRA, it is easier for Jenkins administrators >>> to query the list of plugins which are up for adoption and there is a >>> clear >>> audit trail of when a plugin was adopted. >>> >>> *POST ADOPTION TASKS* >>> >>> - new maintainer needs to be given write access to the git >>> repository with the plugin code. I believe that this can be done by >>> sending special commands to the bot on the IRC Freenode #jenkins channel. >>> - in JIRA, new maintainer should be made the default assignee for >>> tickets filed with Component set to that plugin >>> - in JIRA, all Unresolved tickets should be assigned to the new >>> maintainer >>> - new maintainer is responsible for updating the wiki page for the >>> plugin, and also for updating the pom.xml metadata for the plugin >>> indicating that they are the maintainer >>> >>> >>> This will hopefully reduce the amount of email going to the lists (by a >>> small amount), yet give a clear trackable process by which >>> plugins can change maintainershp. >>> >>> Thank you. >>> >>> -- >>> Craig >>> >>> -- >>> 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/CAG%3DrPVdd81B73r0aMRcOWD%2B50HfTb3qh5asTnt44tD9XWNMq%3DQ%40mail.gmail.com >>> >>> <https://groups.google.com/d/msgid/jenkinsci-dev/CAG%3DrPVdd81B73r0aMRcOWD%2B50HfTb3qh5asTnt44tD9XWNMq%3DQ%40mail.gmail.com?utm_medium=email&utm_source=footer> >>> . >>> For more options, visit https://groups.google.com/d/optout. >>> >> -- 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/b04de754-44ad-4ae8-ba10-4955f3eec4aa%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
