I've forked an app I use myself to add what I thought would be a (relatively) small fix. I then realised it was sort of left in the middle of a redesign/rewrite caused by dependency updates changing / breaking things and decided I needed to finish that if I wanted to see my code on a release. Along the way I got carried away and now the fork feels too large to pull request.

The changes I made don't meaningfully change the app structure but they required multiple refactorings/rewrites and extrapolation of what the redesign was trying to do.

The original developer is active but haven't committed to the repo in a long time. What should I do? I just want people to use the code I wrote. Do I PR and see what they say? Do I make another branch of its main and try to add my changes in more digestible chunks? Do I change the package name and release a build myself? I don't want to figure out a new name / logo etc, especially since the app is largely the same.

There are issues on the original repo about bugs I fixed. I'd like to point them to my fork, but that feels like shilling an unnecessarily made fork. And it doesn't feel right to drop a huge PR on the dev and expect them to accept it or even reply neither.

What do?

  • Anna@lemmy.ml
    ·
    12 hours ago

    The general rule of thumb is, if a single PR changes lots of things then it won't be accepted.

    I'd suggest breaking it into multiple PRs and possibly reaching out to someone on the core team to explain what you were trying to do and how you've done it kinda like RFC. Ideally this would've be done before you started with a major change but still.

    I see you also mentioned original devs are no longer active. In that case you can send PRs but don't expect them to get merged but instead if you are still using it, try to update and fix other things as you see fit and people will see it and start using your repo and if at any time original devs comeback maybe they can official handover project to you or accept all your PRs. And this is totally OK as long as you are not breaking any license original devs had, that's what forks are for. If you want you can rename and do rebranding but that is not necessary unless original devs had trademarked the logs and stuff and that original repo is completely dead.

  • catloaf@lemm.ee
    ·
    2 days ago

    If you can, fork it again but this time only fix the one bug with minimal changes and submit that as a PR. Then ask the maintainer about submitting more to fix the other bugs, and doing some refactoring.

    • propter_hog [any, any]
      ·
      1 day ago

      Yep, this is the way. A PR should have a single focus. So your updates may end up being multiple PRs.

  • doeknius_gloek@discuss.tchncs.de
    ·
    2 days ago

    I'd say ask the original developer directly. Getting your changes merged upstream should be the preferred option for you, the original dev and the users. If everything goes right, you both could figure out a way to do this, maybe by re-introducing your refactorings and fixes one by one in smaller pull requests. Maybe you could become a maintainer in the process and support the original dev long term so everybody wins.

    If the original developer doesn't respond or declines you could think about bringing your own fork forward. Think about the consequences though, the original dev might get frustrated by a competing fork and abandon the project completely. The users on the other hand might be confused or insecure about which version to choose. Your fork must offer a lot for them to jump ship and switch.

    Generally I'd say open source is about working together, not against one another, so just shoot them a message and see where it goes.