Changing the root project to a fork about apt-cyg

[ilatypov]

BTW I don't get the question. I am not aware about a Github's committee or process that would decide which project deserves a "root" status. The yannick's sorting could benefit from including the number of commits (as well as commits behind and ahead of the root project).

@native-api I would like to add that I was a contributor to this repo, as can be seen on my tag. A fact no one else in this thread can claim.

So I think calling me a troll is not appropriate.

https://github.com/transcode-open/apt-cyg/graphs/contributors

[sn-donbenjamin]

My fork is usable. Its very useful
I will research what your saying/asking and reply asap.

[native-api]

@sn-donbenjamin your fork is "even with transcode-open:master".

[sn-donbenjamin]

thanks these are things I was going to check when I got back to a computer :-)

[ilatypov]

Thanks for asking, I did not have reservations. @kou1okada's development of apt-cyg looks very good to me. (I kept myself stuck to using ash in trying to reduce the number of DLLs locked during package installs. Mind you this helps in using apt-cyg for installing extra packages only for some time after the install/upgrade while the mirror still holds the same or previous version of Cygwin. I wish there was a mirror or an artifactory preserving all versions of Cygwin. That way apt-cyg install PACKAGE would never fail to find the install-time versions of packages and therefore would not require the apt-cyg update invokation. The update command will cause attempts to replace running DLLs during subsequent installs or require a dist-upgrade).

The dist-upgrade implementation looks good to me. (I am still curious how and if and why that avoided terminating the currently running shell).

My clumsy attempt to bypass a Zscaler outgoing filter and "fix" ACLs resulted in a poor man's CMD batch file, https://gist.github.com/ilatypov/5956ae36da8ff0aa2212eb2004def8c4 . Cheers!

[native-api]

@ilatypov Thank you for a timely reply! The issue was created because I remember a controversy about someone aggressively advertising their forked project or something or being accused of deviating from the project's initial goals. So I decided to make extra sure that the process goes smoothly and Github staff is sure they are not being used as a pawn in someone's game.

I believe the feedback received so far is enough and have filed the request to them, referencing this issue as an additional argument.

[RyuDragonRyder]

I have been using the fork that @native-api spoke of because it is usable, unlike this one which i kept getting errors from and found no way to report bugs.

[native-api]

@cup commented on Mar 25, 2019, 9:23 PM GMT+3

I have a similar project here that is up to date

https://github.com/cup/pear

That's better but still off topic for the current discussion and might be in violation of https://help.github.com/en/articles/github-terms-of-service#k-advertising-on-github , too.

[native-api]

Status update:

I filed the request to Github support about a month ago. Strangely, they requested an explicit okay from @transcode-open (I had such requests granted in the past without this). I mailed @transcode-open on the address specified in their profile and, expectedly, got no reply. I followed up the support on this on 19.03 and got no reply from them, either. I sent them a follow-up just now also asking if there's some legal roadblock or something ('cuz it doesn't seem so thanks to the MIT license).

[kou1okada]

Why he erased the first post and came back soon?
Beause I removed my last post?
I will write again, he is the man who killed apt-cyg by evil DMCA takedown!
No way!
He must understand what OSS license is!
I don't want to see tragedy like #73 again.

[native-api]

@kou1okada don't feed the troll. Leaving evidence of his wrongdoings as I did so that it's possible to take action when it piles up will likely work as a deterrent.

[native-api]

GitHub support never responded to my follow-up. Maybe if someone else contacts them, too, it will get things going.

[native-api]

@kou1okada I contacted Github support again (now they have a separate support category for altering project routing) and they offered to disconnect your project from the root (if I understood it correctly). But they required an okay from you.

The only "easy" option they offered is to CC the support e-mail to you -- which I cannot do since you don't publish your e-mail.

So could you contact them at https://support.github.com/contact?tags=rr-forks if you're still interested?

Here's their reply for reference:

Hi there,

Thanks for reaching out to GitHub Support!

We'd be happy to help by detaching that fork (and its children) from the parent, but we'll need approval from kou1okada before we can look into this any further.

If you're personally in touch with them, you can cc them into this thread and ask that they 'reply all' from a verified email address on their GitHub account with something like "I grant permission to detach the kou1okada/apt-cyg fork from the root network."

I hope this helps!

[kou1okada]

Thank you so much to acknowledge the value of my fork.
But I couldn't understand any advantage in disconnecting my fork from the root.
Your original purpose had got to change the root project to the maintained one.
Or maybe it was to assign new maintainers to the root project.
In any case, the goal had got to bring the root project back into a maintained state.
However, If my fork will disconnect from the root, not only leaves the root is still unmaintained, but also makes it difficult to find my fork from the forks of the root.
Maybe, that is losing sight of the original purpose, I think.
How do you think about it?

[native-api]

That's what I think, too. So I suggest you to write to them personally and request specifically a root switch, explaining that just disconnecting won't help much.

(Or will it? If your fork looks like a main project rather than fork, people will treat it as a main project rather than fork. So I guess that'd still be better than the current state of affairs.)

[kou1okada]

So I guess that'd still be better than the current state of events.

I don't think so.
Keep my fork to the highest activity under the root has a large advantage.
That will be a huge clue to find the best fork for the people who knows the announcement.
This can not be done the fork that is disconnected from the root.

There are no way to recover the root activities without the permission of @transcode-open.
But he has kept silence in this place.
I respect his decision-making.

Thank him for his brilliant work.