this post was submitted on 24 Dec 2024
38 points (97.5% liked)

Open Source

31737 readers
133 users here now

All about open source! Feel free to ask questions, and share news, and interesting stuff!

Useful Links

Rules

Related Communities

Community icon from opensource.org, but we are not affiliated with them.

founded 5 years ago
MODERATORS
 

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?

you are viewing a single comment's thread
view the rest of the comments
[โ€“] catloaf@lemm.ee 20 points 2 days ago (1 children)

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.

[โ€“] isVeryLoud@lemmy.ca 6 points 1 day ago

This respects the PR atomicity principle.

This should be done anyway. One commit per fix, one PR per issue.