dryark / stf_ios_support

Central repo to connect and document components/repos needed for IOS stf support
Other
154 stars 65 forks source link

Request Transfer out of namespace #121

Closed nanoscopic closed 1 year ago

nanoscopic commented 1 year ago

I request that stf_ios_support and it's related bits be transferred out of the DeviceFarmer namespace, into my company DryArk namespace.

The reason is because no one in the DeviceFarmer namespace is maintaining any of it or even responding to the issues.

I am the only one who does so, and all I receive is grief from people about not maintaining them myself.

If people are going to complain about my projects, I deserve to be able to respond to them how I see fit. There is no longer any benefit to these projects being in the DeviceFarmer namespace as far as I can tell.

nanoscopic commented 1 year ago

The other associated projects that should be moved are these:

https://github.com/DeviceFarmer/stf-ios-provider

https://github.com/DeviceFarmer/ios_video_stream

https://github.com/DeviceFarmer/ios_avf_pull

https://github.com/DeviceFarmer/osx_ios_device_trigger

koral-- commented 1 year ago

OK, no problem for me.

koral-- commented 1 year ago

All those repositories were transferred. The old links still work.

sgabenov commented 1 year ago

So the only question i have, why @nanoscopic could not be added to a maintainer of devicefarmer repo, so all the code will be located in a single place

nanoscopic commented 1 year ago

@sgabenov The repos are being transferred to the DryArk namespace, which is my company. My personal namespace is only a temporary location for them in that transfer process.

I personally wrote 99.99% of the code in these repos. After having done so, I moved on from this project/repos as far as development and handling PRs etc, in order to focus on making an entire replacement system called ControlFloor.

I donated the repos into the DeviceFarmer namespace at that time, in the hope that the STF / DeviceFarmer community would take on maintenance of these things. That never happened. A few people here and there have made issues and a small handful of PRs, but no one accepted the PRs or ever integrated information about any of this stuff into the main DF documentation.

Despite not actually doing any work on the repos, I have been responding to issues on the project for some time. This all came to a head very recently in the form of a new contributor harassing me about my choices and methods. He began to personally attack me for my strong viewpoints.

I welcome any contributors, but I did not appreciate the harassment and objected and interacted with Karol on having something done about this, as well as reporting one of the responses to LinkedIn as harassment.

After that occurred, I decided that I am tired of these repos getting more and more out of date and non-functional. While I don't have any interest in utilizing this code myself, and personally consider it all deprecated, that is not the view of STF / DF users, and a lot of people ask about what is going on with this stuff periodically.

Having written and abandoned such a project, despite my having no obligation to continue supporting it, looks bad on me personally and on my company. I additionally don't want to see the code rot into obscurity.

As a result of all of the above, I have decided to step back in to taking an active role and respond to all the tickets, get the PRs that exist accepted and merged, and update the set of repos where needed to get them at least functioning again. I am additionally considering changing the license on the repos to something more permissive so that the iOS extension to STF / DF can gain more contributors.

The reason this was all necessary ( transferring the repos out of the DeviceFarmer namespace ), and that I could not do it with the repos in that namespace, is because I insist on it. I insist on it as I was told I must obey oversight of DeviceFarmer namespace owners / leaders, and that if they don't like the way I participate that I could be banned.

It is my code. How I behave is my choice so long as I obey the LinkedIn rules. I refuse to accept additional restrictions on donating my time to work on and maintain a project that I get nothing out of.

Basically, the reason is because I say so.

Despite the repos having been transferred, I don't have any objection or quarrel with the DeviceFarmer namespace folks. I'm not going to hard fork the upstream, and will contribute changes back to DF/stf as necessary to get all this working again. I welcome anyone who wants to contribute, and don't intend to stand in the way of any well-meant improvements, even by people I personally dislike.

I will ask you, @sgabenov , what is your objection to my retaking control of code that I wrote? You've said "so all the code will be located in a single place". Why does that matter?

I will also point out that nothing that has just happened actually restricts DeviceFarmer folks in any way. If they decide that I am behaving badly, they are still able to fork my code back and continue on without me as long as the license is obeyed. I don't see how that would be helpful, as I don't see anyone there stepping up to do the work necessary to maintain this stuff, but the only thing that has really changed is me saying "I'm going to maintain this stuff, and I want to do it in a space I control."

sgabenov commented 1 year ago

My team wanted to make some PR's to the Mac provider, but did not found the code, that was several weeks ago in the devicefarmer repo. For me it is quite a pitty situation, when a working project begin to split on multiple parts. It looks lite it won't be developed in future and very likely may die. At the moment it is the only good open source alternative for managing android\mac at same time. Wish you all the best and hope the project will continue to develop

nanoscopic commented 1 year ago

@sgabenov No one from the DeviceFarmer namespace ever stepped up to become maintainer of stf_ios_support.

I myself intentionally abandoned and deprecated this repo and its associated pieces as they are quite a mess and don't really work that well. I've created much better equivalent code that can be used.

Despite that, people do still want to use this project. I am changing my tune in that instead of just turning people away and leaving this project to rot I am taking control of it again and will make it viable once more.

I do still think it goofy to continue using and supporting this code, but I don't feel the need to dictate what the community wants. If the community is interested in using and maintaining this old STF iOS support code, I am willing to act as maintainer to get it up and running again.

The "code splitting up" is nothing to worry about. The code was already very much dead. By stepping in and maintaining the project and accepting PRs again etc I am bringing it back to life.

It will be a bit messy at first getting it up and working again, and I am going to have to struggle with which newer features and methods I want to contribute into it, but there is no need for this project to die.

den-patrakeev commented 1 year ago

@nanoscopic hi Thanks for your work!