in reply to Re^5: GitHub PR (was: Re^4: CPAN Ratings...)
in thread CPAN Ratings...

Yes, it's getting complex...

Maybe so...but with help we've got there :)

My fork of the module now exists locally, it's been updated so it doesn't reference CPAN Ratings in POD or README. It's been tested locally so it's ready to go...

How do I...

  1. Get the local copy back to GitHub?
  2. Do the PR?

Update...
Reading this article makes me think that I perhaps should have cloned instead of forked. I guess it doesn't matter for this simple case but am I right that I should have cloned the repo?

Another Update...
I *think* I have done the PR...is it now a case of waiting for the maintainer?

  • Comment on Re^6: GitHub PR (was: Re^4: CPAN Ratings...)

Replies are listed 'Best First'.
Re^7: GitHub PR (was: Re^4: CPAN Ratings...)
by hippo (Archbishop) on Jun 01, 2023 at 21:49 UTC
    I *think* I have done the PR...is it now a case of waiting for the maintainer?

    You have and it is here and it looks good to me. Yes, just wait for a response now - there is nothing more for you to do at this point other than reflect on a job well done.


    🦛

      Huge thanks to hippo and choroba for the hand-holding through this...it feels like a big step forward :)

      Was I right to 'fork' the disto or would a 'clone' have been a better option?

        I *think* what Github calls "fork" is more or less a clone, just using a different Github account. Technically, what "we" (whoever that may be) call a "fork", usually starts out from a clone anyway.
        Edit: with "we", I meant something like the "prevailing view"

        I agree with soonix that it's mostly a matter of terminology.

        However, if you are asking whether you should have forked the original repo at github as was done or instead should have directly cloned the original repo to your local machine, then I would say the former. You need somewhere on github to store the branch with your amendments because you don't have rights to push to the original repo. If you want a local copy for testing (which is usually wise) then what you have done is the usual approach. You can either make your changes in the github editor as has happened here or perhaps more usually, clone your untouched fork and then do all the work on your local copy only pushing back up to your fork when happy. I generally find it easier to work locally using my own tools. YMMV.

        Obviously, there's an awful lot more to it and this is just scratching the surface but you are on your way now so the sky's the limit.

        It is also important to realise that github is just one SaaS repository. Others have their own ways of doing things so it would be wise/prudent to see how the process happens elsewhere. By all means leverage the tools which github provides but don't become dependent on them as they could change at any time (or you may become unable to use them for other reasons).


        🦛