How to properly fork an unmaintained github package?












2















There is a github php library which is used quite a lot, but the problem is the original author seems to have gone AWOL and despite myself and other members of the dev team (who themselves are not particularly active due to time constraints) trying to contact him many times over a long period (several months now) he has been totally unresponsive.



Meanwhile there is a very large backlog of open PRs and issues for this repository, and it is used by many people.



I want to make a "hard fork" of it - with the following requirements




  • Must start from the latest code that's there now


  • Must be able to be used by other people with a simple package name change in the composer file (so should be distinguishable from the original package in packagist without having to override repo source)


  • Ideally, would be possible to merge it back into main repo if the author ever wakes up from his slumber



I am looking for any other tips from people who may have been in the same situation.



I am quite happy to continue maintaining this repo as I use it in many personal projects as well as at work in commercial projects.



As far as I understand my main 2 avenues would be:




  • Change the composer.json file in my fork of the repo (up to date) to rename the package to coincide with my GitHub user and register it on packagist;


  • Create a new repository with a different name, using latest code as starting point, and register it on packigist.



Any advise appreciated, thanks.










share|improve this question





























    2















    There is a github php library which is used quite a lot, but the problem is the original author seems to have gone AWOL and despite myself and other members of the dev team (who themselves are not particularly active due to time constraints) trying to contact him many times over a long period (several months now) he has been totally unresponsive.



    Meanwhile there is a very large backlog of open PRs and issues for this repository, and it is used by many people.



    I want to make a "hard fork" of it - with the following requirements




    • Must start from the latest code that's there now


    • Must be able to be used by other people with a simple package name change in the composer file (so should be distinguishable from the original package in packagist without having to override repo source)


    • Ideally, would be possible to merge it back into main repo if the author ever wakes up from his slumber



    I am looking for any other tips from people who may have been in the same situation.



    I am quite happy to continue maintaining this repo as I use it in many personal projects as well as at work in commercial projects.



    As far as I understand my main 2 avenues would be:




    • Change the composer.json file in my fork of the repo (up to date) to rename the package to coincide with my GitHub user and register it on packagist;


    • Create a new repository with a different name, using latest code as starting point, and register it on packigist.



    Any advise appreciated, thanks.










    share|improve this question



























      2












      2








      2


      1






      There is a github php library which is used quite a lot, but the problem is the original author seems to have gone AWOL and despite myself and other members of the dev team (who themselves are not particularly active due to time constraints) trying to contact him many times over a long period (several months now) he has been totally unresponsive.



      Meanwhile there is a very large backlog of open PRs and issues for this repository, and it is used by many people.



      I want to make a "hard fork" of it - with the following requirements




      • Must start from the latest code that's there now


      • Must be able to be used by other people with a simple package name change in the composer file (so should be distinguishable from the original package in packagist without having to override repo source)


      • Ideally, would be possible to merge it back into main repo if the author ever wakes up from his slumber



      I am looking for any other tips from people who may have been in the same situation.



      I am quite happy to continue maintaining this repo as I use it in many personal projects as well as at work in commercial projects.



      As far as I understand my main 2 avenues would be:




      • Change the composer.json file in my fork of the repo (up to date) to rename the package to coincide with my GitHub user and register it on packagist;


      • Create a new repository with a different name, using latest code as starting point, and register it on packigist.



      Any advise appreciated, thanks.










      share|improve this question
















      There is a github php library which is used quite a lot, but the problem is the original author seems to have gone AWOL and despite myself and other members of the dev team (who themselves are not particularly active due to time constraints) trying to contact him many times over a long period (several months now) he has been totally unresponsive.



      Meanwhile there is a very large backlog of open PRs and issues for this repository, and it is used by many people.



      I want to make a "hard fork" of it - with the following requirements




      • Must start from the latest code that's there now


      • Must be able to be used by other people with a simple package name change in the composer file (so should be distinguishable from the original package in packagist without having to override repo source)


      • Ideally, would be possible to merge it back into main repo if the author ever wakes up from his slumber



      I am looking for any other tips from people who may have been in the same situation.



      I am quite happy to continue maintaining this repo as I use it in many personal projects as well as at work in commercial projects.



      As far as I understand my main 2 avenues would be:




      • Change the composer.json file in my fork of the repo (up to date) to rename the package to coincide with my GitHub user and register it on packagist;


      • Create a new repository with a different name, using latest code as starting point, and register it on packigist.



      Any advise appreciated, thanks.







      php github






      share|improve this question















      share|improve this question













      share|improve this question




      share|improve this question








      edited Jan 1 at 5:26









      VonC

      845k29426783233




      845k29426783233










      asked Jan 1 at 4:26









      user2627591user2627591

      111




      111
























          1 Answer
          1






          active

          oldest

          votes


















          0














          To avoid any future issue, you should create a new repository in an organization, because there:





          • you can fork a fork (in an organization): if that new repo is no longer (later on) the active one, you can fork it.

          • you can make it depend on a theme, represented by the organization, as opposed to an author (which is problematic today)


          In both instances, you do need to register a new reference to packagist.






          share|improve this answer























            Your Answer






            StackExchange.ifUsing("editor", function () {
            StackExchange.using("externalEditor", function () {
            StackExchange.using("snippets", function () {
            StackExchange.snippets.init();
            });
            });
            }, "code-snippets");

            StackExchange.ready(function() {
            var channelOptions = {
            tags: "".split(" "),
            id: "1"
            };
            initTagRenderer("".split(" "), "".split(" "), channelOptions);

            StackExchange.using("externalEditor", function() {
            // Have to fire editor after snippets, if snippets enabled
            if (StackExchange.settings.snippets.snippetsEnabled) {
            StackExchange.using("snippets", function() {
            createEditor();
            });
            }
            else {
            createEditor();
            }
            });

            function createEditor() {
            StackExchange.prepareEditor({
            heartbeatType: 'answer',
            autoActivateHeartbeat: false,
            convertImagesToLinks: true,
            noModals: true,
            showLowRepImageUploadWarning: true,
            reputationToPostImages: 10,
            bindNavPrevention: true,
            postfix: "",
            imageUploader: {
            brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
            contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
            allowUrls: true
            },
            onDemand: true,
            discardSelector: ".discard-answer"
            ,immediatelyShowMarkdownHelp:true
            });


            }
            });














            draft saved

            draft discarded


















            StackExchange.ready(
            function () {
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53992998%2fhow-to-properly-fork-an-unmaintained-github-package%23new-answer', 'question_page');
            }
            );

            Post as a guest















            Required, but never shown

























            1 Answer
            1






            active

            oldest

            votes








            1 Answer
            1






            active

            oldest

            votes









            active

            oldest

            votes






            active

            oldest

            votes









            0














            To avoid any future issue, you should create a new repository in an organization, because there:





            • you can fork a fork (in an organization): if that new repo is no longer (later on) the active one, you can fork it.

            • you can make it depend on a theme, represented by the organization, as opposed to an author (which is problematic today)


            In both instances, you do need to register a new reference to packagist.






            share|improve this answer




























              0














              To avoid any future issue, you should create a new repository in an organization, because there:





              • you can fork a fork (in an organization): if that new repo is no longer (later on) the active one, you can fork it.

              • you can make it depend on a theme, represented by the organization, as opposed to an author (which is problematic today)


              In both instances, you do need to register a new reference to packagist.






              share|improve this answer


























                0












                0








                0







                To avoid any future issue, you should create a new repository in an organization, because there:





                • you can fork a fork (in an organization): if that new repo is no longer (later on) the active one, you can fork it.

                • you can make it depend on a theme, represented by the organization, as opposed to an author (which is problematic today)


                In both instances, you do need to register a new reference to packagist.






                share|improve this answer













                To avoid any future issue, you should create a new repository in an organization, because there:





                • you can fork a fork (in an organization): if that new repo is no longer (later on) the active one, you can fork it.

                • you can make it depend on a theme, represented by the organization, as opposed to an author (which is problematic today)


                In both instances, you do need to register a new reference to packagist.







                share|improve this answer












                share|improve this answer



                share|improve this answer










                answered Jan 1 at 5:24









                VonCVonC

                845k29426783233




                845k29426783233
































                    draft saved

                    draft discarded




















































                    Thanks for contributing an answer to Stack Overflow!


                    • Please be sure to answer the question. Provide details and share your research!

                    But avoid



                    • Asking for help, clarification, or responding to other answers.

                    • Making statements based on opinion; back them up with references or personal experience.


                    To learn more, see our tips on writing great answers.




                    draft saved


                    draft discarded














                    StackExchange.ready(
                    function () {
                    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53992998%2fhow-to-properly-fork-an-unmaintained-github-package%23new-answer', 'question_page');
                    }
                    );

                    Post as a guest















                    Required, but never shown





















































                    Required, but never shown














                    Required, but never shown












                    Required, but never shown







                    Required, but never shown

































                    Required, but never shown














                    Required, but never shown












                    Required, but never shown







                    Required, but never shown







                    Popular posts from this blog

                    android studio warns about leanback feature tag usage required on manifest while using Unity exported app?

                    SQL update select statement

                    'app-layout' is not a known element: how to share Component with different Modules