Concerns with the direction and ownership of pywinrm

[badcure]

I am currently concerned with the state of pywinrm, and winrm in general within the Python community. The core of the issue is the apparent inability for not just me, but others to be able to contribute and help guide the direction of pywinrm. For some examples, you can see my comments in #243.

I created a couple of PRs back in 2016, and since then have had 0 interactions. Most notably is #132, which I think is still valid today. I think the ability to completely close all network connections to the server when the task is completed would be great. Ansible doesn't necessarily need this, the application exits when it is done. If there is an always-on application that uses it, this can become very beneficial.

The problem as I see it and as @nitzmahone stated in #249: It is not maintained because they are moving to https://github.com/jborean93/pypsrpby in Ansible. Let me preface this, I am not questioning the quality, direction, etc of this new project. Nor am I saying that others should not use it. If it makes sense for you, go ahead! My concern is that @jborean93 also works for Ansible...I may be wrong in the long run, but it is very possible that the fate of that project will be the same: Features will be added only to the extent that it benefits the Ansible product.

The current owners essentially have 0 vested interest in seeing pywinrm succeed. One example that I see is the ability to transfer files. Each application has to build its own, which is what Ansible did. As you can see in #77, @nitzmahone mentioned that Ansible had to build its own even though he essentially runs this project. ansible/ansible#13209 is an example of work he did for Ansible for this in particular, that I think could have benefited this project and community as a whole. Even to this day, I think that would be an extremely beneficial feature to have. @jborean93 wrote his own. It will probably become the new standard out of necessity and not community preference. As far as committing work, #222 is an example to where multiple multiple PRs years old by various people, were finally addressed only by work that they both did.

My question out of all this is simply: Are there any community driven(and not Ansible dictated) WinRM solutions out there? If it is pywinrm, what is the process? Regardless, my view is it should be clearly stated whether pywinrm is now an Ansible helper library only, or an open source library for the Python Community.

[diyan]

@badcure If you have a will to support this package further I can grant you all required permissions including GitHub and PyPI.

[badcure]

@diyan That works if you don't mind, I really do want to see this project succeed.

FYI, for you and and anyone else, feel free to hold me accountable. It will be good feedback to make sure things are going in the right direction.

[nitzmahone]

@badcure Your concerns seem to imply the existence of governance and community process around this project where there really is none. @jborean93 and I got involved to contribute back enhancements we'd made for Ansible that might be of interest to the community. It would've been much simpler for us to just bundle the code into Ansible and enhance it in place, but we wanted to give those features back to the project as thanks for the time it saved us. WRT Ansible's local file upload: we needed to continue working with older pywinrm releases, so the file transfer and input support got coded inline, and just never got copied over. Nothing stopping anyone else from doing it...

Last I recall, @diyan had moved on to other things and didn't have the bandwidth to continue active maintenance on the project. I'm a maintainer on a number of OSS projects, but mostly because they're critical to the thing I get paid to work on (Ansible), so my participation is usually limited to keeping our use cases working. I also don't have the bandwidth for general project owner kinds of duties (eg, issues/PRs that are of neutral-or-negative benefit to Ansible, or that may introduce breaking changes). I'll take a quick pass looking for low-hanging fruit once in awhile, but if something looks at all questionable, I usually end up just skipping over it, as breaking changes to this project affect a lot of users. If you've got the time, skills, and willingness to take those things on, great!

[diyan]

Maintainer access on https://pypi.org/project/pywinrm granted to @badcure , @jborean93
Collaborator access on https://github.com/diyan/pywinrm granted to @badcure , @jborean93

@jborean93 Shame on me. I always though that you already has the very same access just like @nitzmahone . This explains why you have created a fork... but why you just did not ask about it?

[jborean93]

@diyan thanks for that, sound just be jborean93, that's what showing in pypi for me.

[diyan]

@jborean93 PyPI granted as well. See updated comment.

[nitzmahone]

@diyan oh, since you're doing that, can you grant admin privs on appveyor to mrd at redhat? I can't currently restart failed jobs or manage anything in there, and there's still a couple of flaky tests.

[diyan]

@nitzmahone Done. Granted to both mattdavi at redhat, mrd at redhat.

Administrator access on https://ci.appveyor.com/project/diyan/pywinrm granted to @nitzmahone , @jborean93 , @badcure

[badcure]

Awesome, I appreciated it! Just accepted the requests.

[badcure]

Thanks everyone, I will close out this issue.