RAD Game Tools License Concern - Immediate Action Required

CyanWorlds.com Engine Project Management
User avatar
branan
Member
Posts: 84
Joined: Wed Apr 06, 2011 11:35 pm

Re: RAD Game Tools License Concern - Immediate Action Requir

Post by branan »

Hoikas and I are happy with the results of CW's current script. Barring any issues found by others we'll push the results of that script to the H-uru master as soon as the simplified script exists for all our forks to use.
Skoader
Member
Posts: 29
Joined: Fri Jul 01, 2011 2:27 am

Re: RAD Game Tools License Concern - Immediate Action Requir

Post by Skoader »

Different result here with Git 1.7.4 on Windows.
Expected result after updating to 1.8.0.

Thanks for all the work.
User avatar
branan
Member
Posts: 84
Joined: Wed Apr 06, 2011 11:35 pm

Re: RAD Game Tools License Concern - Immediate Action Requir

Post by branan »

I just tried the git-only conversion script on a clone of the H-uru/Plasma repo. I got a message about "possible duplicates", but the HEAD SHA is b3976524ee406256655183fd25a49d984138dfb0, which matches the expected output according to binkbegone.sh. Looking at the logs those 'duplicates' might actually be correct (a closed PR and then a reopened one after a rebase).

It does look like github refuses to let me push up changes to the refs for PRs. I'll ask Hoikas to poke them about how to ensure the old history isn't accessible through closed pulls.

EDIT: the new history is presently live on H-uru/Plasma. I have a backup of the old one in case we decide more tweaks are needed.
EDIT2: I just converted the Gehn fork without getting the duplicates warning. It's quite possible that issue only affects H-uru repo, and if so I'm not going to worry about it.
User avatar
Hoikas
Member
Posts: 344
Joined: Fri Jun 03, 2011 8:38 pm

Re: RAD Game Tools License Concern - Immediate Action Requir

Post by Hoikas »

Github support has been notified. They intend to make all unfiltered repositories private for us and pass along an explanation.
Image
Christian Walther
Member
Posts: 317
Joined: Sat Dec 13, 2008 10:54 am

Re: RAD Game Tools License Concern - Immediate Action Requir

Post by Christian Walther »

branan wrote:I just tried the git-only conversion script on a clone of the H-uru/Plasma repo. I got a message about "possible duplicates", but the HEAD SHA is b3976524ee406256655183fd25a49d984138dfb0, which matches the expected output according to binkbegone.sh. Looking at the logs those 'duplicates' might actually be correct (a closed PR and then a reopened one after a rebase).
Trying this too (I hadn’t before – I used the GehnShard fork as a test case, which as you note causes no warnings), I can reproduce some duplicate warnings, and I concur that they are most likely harmless. They all have to do with pull requests in addition, so owners of repos that have no (incoming) pull requests should be fine.

In detail:

Code: Select all

commit b687ab3cc01a10c79bf25c661308e46f536ba277
Author: a'moaca' <none@none>
Date:   Sun Mar 27 16:22:32 2011 -0700

    Import modified jpeg-8c library. The library is modified to provide the
    RGBA color space expected by plMipmap.
commit 4b7bb2f344cd06149907b665245d5295f7b81c5e
Author: a'moaca <none@none>
Date:   Sun Mar 27 16:22:32 2011 -0700

    Import modified jpeg-8c library. The library is modified to provide the
    RGBA color space expected by plMipmap.
This is an actual duplicate – the second version is from a preliminary filter-branched version that still has the broken a'moaca author name. It was pulled in by refs/pull/230/head (though, interestingly, not refs/pull/230/merge). Since PR 230 is still open, I hope this will automatically rectify itself once someone does something with PR 230 (e.g. update or merge it). The pull request page at least shows it with a correct head of 5cb8f3b.

Code: Select all

commit be165f281b5025a691870440643f71415c7d1bf8
Merge: 86de0d4 5beda0a
Author: GitHub Merge Button <merge-button@github.com>
Date:   Thu Apr 5 23:17:04 2012 -0700

    Merge efeaaa60e6d9bb974b207273dafd5f29f4f0d6e7 into 4d56e49453ab94d4d4ade799a27b2353f0df0005
commit 49629b25d347a6203519672b652975a16094f299
Merge: 86de0d4 1fa981d
Author: GitHub Merge Button <merge-button@github.com>
Date:   Thu Apr 5 23:17:04 2012 -0700

    Merge b31f1fa72c4cdcdc9acefe8208e938d9139fd6f1 into 4d56e49453ab94d4d4ade799a27b2353f0df0005
This is a false positive – GitHub just happened to merge two different pull requests in the same second (I don’t know exactly what causes the creation of these “GitHub Merge Button” commits). Nothing to worry about.

Code: Select all

commit b219c3c3cc7f33cb9c5e33de33469647ad58a1dc
Author: Michael Hansen <zrax0111@gmail.com>
Date:   Tue Nov 13 01:02:23 2012 -0800

    Alright, this _TEMP_CONVERT_ stuff was a stupid idea
commit 230c43b143fed4f9d473e0fca6098edc24782e32
Author: Michael Hansen <zrax0111@gmail.com>
Date:   Tue Nov 13 01:02:23 2012 -0800

    Alright, this _TEMP_CONVERT_ stuff was a stupid idea
commit a3ba5c5bbe8c5c114d393be4febe7358ed1cb1bc
Author: Michael Hansen <zrax0111@gmail.com>
Date:   Tue Nov 13 01:02:23 2012 -0800

    Alright, this _TEMP_CONVERT_ stuff was a stupid idea
The first and third of these are actual duplicates (by the criteria considered by the script – same parent and same author date), but they came about by the fact that PR 228 is a rebased replacement for PR 227, so including them is correct. The middle one is erroneously output by the script (it has the same author date but not the same parent), it is part of the preliminarily-filter-branched history mentioned above and should disappear with it.
branan wrote:I'll ask Hoikas to poke them about how to ensure the old history isn't accessible through closed pulls.
Hoikas wrote:Github support has been notified. They intend to make all unfiltered repositories private for us and pass along an explanation.
Very good. If I read the network graph correctly, that would be AtlantisShard, TheEggman, NadnerbD, philippelatulippe, RPLawrence.

I’m going to do some experiments to see if we can achieve the same thing (bring closed pull requests onto the new history) on Bitbucket. May require help from support as well.
User avatar
Lyrositor
Member
Posts: 156
Joined: Sun Feb 05, 2012 10:58 pm
Contact:

Re: RAD Game Tools License Concern - Immediate Action Requir

Post by Lyrositor »

Houston, we have a problem: https://github.com/Dhelayan/plLayerBink :|

Notice the addition of this comment:

Code: Select all

//Failure to remove this file could result in prosecution of Cyan Worlds by RAD Game Tools
//for releasing copyrighted code, which would be A Bad Thing(TM).
Lyrositor
Explorer #16601888
To D'ni, or not to D'ni. There is no question.
Image
User avatar
branan
Member
Posts: 84
Joined: Wed Apr 06, 2011 11:35 pm

Re: RAD Game Tools License Concern - Immediate Action Requir

Post by branan »

Oh Dhelayan. What would we do without him. I think the best thing is just to notify Cyan and/or RAD and have them send a DMCA takedown request to github for that repo. It's just not worth anybody's time to bother talking to him.
User avatar
JWPlatt
Member
Posts: 1137
Joined: Sun Dec 07, 2008 7:32 pm
Location: Everywhere, all at once

Re: RAD Game Tools License Concern - Immediate Action Requir

Post by JWPlatt »

Christian Walther wrote:I’m going to do some experiments to see if we can achieve the same thing (bring closed pull requests onto the new history) on Bitbucket. May require help from support as well.
I am working on the Bitbucket support side of things. Please contact me with any specifics.
Perfect speed is being there.
User avatar
Hoikas
Member
Posts: 344
Joined: Fri Jun 03, 2011 8:38 pm

Re: RAD Game Tools License Concern - Immediate Action Requir

Post by Hoikas »

branan wrote:Oh Dhelayan. What would we do without him. I think the best thing is just to notify Cyan and/or RAD and have them send a DMCA takedown request to github for that repo. It's just not worth anybody's time to bother talking to him.
I did send another email to github support about that one. That's all the attention I care to give to this trollface.
Image
Christian Walther
Member
Posts: 317
Joined: Sat Dec 13, 2008 10:54 am

Re: RAD Game Tools License Concern - Immediate Action Requir

Post by Christian Walther »

JWPlatt wrote:
Christian Walther wrote:I’m going to do some experiments to see if we can achieve the same thing (bring closed pull requests onto the new history) on Bitbucket. May require help from support as well.
I am working on the Bitbucket support side of things. Please contact me with any specifics.
OK, I haven’t found a way of doing it from our side so far. Here’s what I have found in my experiments – it’s all a little strange :? : Updating the destination repo to the new history (i.e. stripping the old and pushing the new), but leaving the source repos on the old history will mark all merged pull requests as open again. (This is halfways expected because the pull request head revisions now in fact are no longer merged into the destination, but is interesting because otherwise there is no way of reopening a pull request.) The pull requests will also become editable again, however the editability will only last as long as the source revision is still available in the source repository – as soon as I strip it from there and push the new history, the edit button disappears again. When I push the new history into the source repository without stripping the old one before, the pull request stays editable, but I still can’t seem to switch it to the new history – the source branch popup only has one entry for the branch (even though it now has two heads in the repository), and it seems to still refer to the old head.

So, the best course of action is probably to ask Bitbucket support what they suggest. If they can switch the PRs around for us without causing any reopening or other permanent changes, that would be best. I can easily compile a list of PR, old revision, new revision for them if that is desired. We’ll probably need exact instructions about what order to push the new history and strip the old one in the source and destination repos, since things seem to be sensitive to that. Fortunately the only source repos are Boq’s, Skoader’s, and mine, so we should manage to contact the owners.

I imagine that this isn’t the first time such a history rewriting has happened on Bitbucket, but I can’t find anything about it in its docs.
Post Reply

Return to “Management”