winp maintainer

[James Nord]

Hi all,

Jenkins has a dependency on https://github.com/kohsuke/winp but it now seems like there is no one active in the project that can release it.  (
https://github.com/kohsuke/winp/pull/69#pullrequestreview-867992611). 

Has anyone got the inclination and time and environment to want to step up as a maintainer for it?

Additionally I looked at the new Java9 process API and it allows cross platform process enumeration but not retrieving environment variables, and changing to jna appears non trivial as there is no single windows API call. 

/James

--
Sent from my phone, please excuse the brevity, typos and auto-correct issues.

[Baptiste Mathus]

Is winp used outside of Jenkins?

Afaik we did move already a few components core to Jenkins to the Jenkinsci GitHub org. Would it make sense to consider moving this one too? Then I assume we'd give permissions to the core team to it?

-- Baptiste

--
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/CAPcEHyeDNWeo0dK%2BwYmo%3Diih1EcRUVfs8-PaydspXxGRcP8izg%40mail.gmail.com.

[Oleg Nenashev]

Hi all,

I am [barely] active in the project, but I cannot release it.

Just to share background for the team, Winp is outside Jenkins as it was discussed with Kohsuke at some point. Same for the Windows Service Wrapper. FTR I brought up the question of WinP and WinSW co-ownership with CloudBees engineering teams a few times after I moved outside of the product organization in 2019. It was not a priority at that point. I used to maintain it when my time allowed (e.g. security fixes or releases requested by Jenkins and CloudBees users), but WinP has never been on the top of my interest list. It is not trivial to maintain the release environment due to specific Windows requirements and Maven Central access. My release environment was wiped out when I left CloudBees as I notified the engineering teams and my managers,  right now I do not have time to set it up.

Regarding moving the components:

• I do not mind moving WinP, because it is not widely used outside Jenkins. Same for removing the Maven Central dependency, the repository can be easily moved to Jenkins repo or GitHub releases. Theownership can be formally transferred to the Jenkins core team. FTR Ideally we should be looking for deprecating the library and using something popular for Process and Environment management
• For Windows service Wrapper the situation is different, it will stay in a separate organization. Contributions are welcome: https://github.com/winsw

Best regards,

Oleg Nenashev

[Tim Jacomb]

Sounds good to move it to Jenkinsci very few usages by the looks of it:

https://mvnrepository.com/artifact/org.jvnet.winp/winp/1.28/usages

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/b634a9a7-f248-45b0-bf91-c286433748edn%40googlegroups.com.

[jn...@cloudbees.com]

What do we need to do to formalize this?  Is it just a case of a https://github.com/jenkins-infra/helpdesk ticket or something else?

Regards

/James

[Tim Jacomb]

Just need Oleg to transfer it

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/6c186233-8d6e-44a7-a4f9-b830ab9d73dbn%40googlegroups.com.

[Basil Crow]

On Mon, May 9, 2022 at 3:02 AM 'jn...@cloudbees.com' via Jenkins Developers <jenkin...@googlegroups.com> wrote:
>

> What do we need to do to formalize this?

When transferring repositories from the kohsuke GitHub organization to the jenkinsci GitHub organization, I have had success filing a GitHub issue in the source organization requesting a transfer to the target organization and @-mentioning an individual with owner permissions in the source organization with reference to a justification for the request in this mailing list. The usual justification that I have provided for such requests is that putting these repositories in the jenkinsci GitHub organization makes it easier to use Jenkins project resources, such as repository-permissions-updater, Artifactory, and ci.jenkins.io.

[Basil Crow]

In https://github.com/jenkinsci/winp/pull/71 I have proposed a path
forward that, while certainly not ideal for consumers outside of the
Jenkins project, matches the path of least resistance that we have
already taken with file-leak-detector, mock-javamail,
maven-jellydoc-plugin, maven-stapler-plugin, and other repositories
adopted from Kohsuke. This path is achievable by me in the short term
and unblocks the Jenkins project to deliver fixes for e.g.
JENKINS-69647. If and when someone volunteers to improve the winp
build, test, and release process even further as described in that PR,
their contribution(s) would be most welcome.

[Mark Waite]

+1 from me to take your proposal as the path forward.