• dgkf@lemmy.ml
    89·
    6 months ago

    I’ve been there, but over the years I’ve gotten better at avoiding being in this situation.

    If you are implementing something for yourself, and merging it back upstream is just a bonus, then by all means jump straight to implementing.

    However, it’s emotionally draining to implement something and arrive at something you’re proud of only to have it ignored. So do that legwork upfront. File a feature request, open a discussion, join their dev chat - whatever it is, make sure what you want to do is valued and will be welcomed into the project before you start on it. They might even nudge you in a direction that you hadn’t considered before you started.

    Be a responsible dev and communicate before you do the work.

    • CosmicTurtle@lemmy.worldEnglish
      11·
      6 months ago

      Yeah…but even then they may not get to you.

      Over the holidays, I had a good back and forth with the maintainer of a project that I started using. The documentation needed updating and created a PR.

      Then I went almost 10 comment rounds on why it was necessary, why I wrote it the way I did, and all this bullshit.

      I just left it saying “merge it or whatever. I’m moving on.”

      It’s still open.

  • caseyweederman
    22·
    6 months ago

    Somebody please fork reprepro, there’s a super useful bugfix in one and a super useful feature in the other but I want both.

    The bugfix is the zstd decompression-cancel race condition bug and the feature is multiple versions per package but they’re both super stale.
    Maybe…
    Maybe I can fork it…

    • djtech@lemmy.world
      13·
      6 months ago

      Fork the feature one, get the diff of the commit that patches the bug and apply the diff to your fork.

      Now compile and test.

      • caseyweederman
        9·
        6 months ago

        I don’t have a lot of experience with merging but then again, this is a great opportunity to learn.

    • kelseybcool@lemmy.world
      8·
      6 months ago

      Only after a fork of the original project takes off and due to some new dependencies no longer supports the suggested feature.

  • rwhitisissle@lemmy.ml
    17·
    6 months ago

    And this is why I don’t contribute. Or at least I’ll ask a question about whether or not something would be a desired feature and if I don’t get a clear yes or no by someone who can actually approve a PR, I. ain’t. coding. shit.

    • JDubbleu@programming.dev
      2·
      6 months ago

      Fair enough, but as someone who has worked closely with the Decky Loader maintainers and contributed my own stand alone plugin I get it. We basically all have day jobs as devs and it can be mentally taxing to do more PRs at home. Not to mention sometimes there’s just not enough time in the day, and I don’t even have kids.

      Maintainers are ultimately volunteers doing work with hundreds of dollars an hour for free. I’ve had some PRs take 20+ days to be looked at, it’s just how it goes.

    • nightm4re@feddit.de
      1·
      6 months ago

      You’re framing this as if it were something unusual. Unsolicited PRs are a no-go in my opinion. It’s just basic communication and collaboration to align with the maintainers whether a change is actually required or not.

  • Praise Idleness@sh.itjust.worksEnglish
    111·
    6 months ago

    I once made a PR changing a = f(b) from a = "" if b == "" else f(b). About six months later still in pending review. I get that people have their own shit but damn.

    edit) Sorry. Clarified the code.

    • emptiestplace@lemmy.ml
      3·
      6 months ago

      It seems like you are implying this is an obvious optimization, regardless of context. Why do we not care what’s going on with b?

      • orgrinrt@lemmy.world
        6·
        6 months ago

        Yeah, the two aren’t equivalent and the original has more conditions than the new one, so without context this just doesn’t make sense in this example.

        A is “” only when B is also “”, otherwise we return f()

        In the new one we simply say that regardless of what B is, we’ll just call f(), entirely skipping the case where B == “”.

        Probably this specific condition checking was moved to the inner scope of f(), but this example does not tell us (who don’t know the context) that. Or maybe the check is redundant, but that also isn’t signaled in any way.

        Or then maybe I’m just oblivious to the optimization, in which case I can see why the maintainer would take their time figuring that out. It’s not anything obvious based on that alone, at least to me, and I would say I have some experience in this field.

        Edit: But yeah this is basically just semantics, I’m sure they gave apt description in the PR, so the context would be explained there and none of this really matters. I just like to ruminate about little things like this for some reason. Didn’t mean to imply they didn’t do a good PR, just that this specific example was either confusing or confused.

  • famfo@social.dn42.us
    9·
    6 months ago

    Even better when someone makes the exact same PR and it gets merged a few days after being opened and yours left unreviewed.

  • mumblerfish@lemmy.world
    9·
    6 months ago

    It is a bit sad that reviewing takes a long time. I have had the same thing for a project, someone on the team pings someone to do a review, 2 years later you get a review saying you should rebase because the PR is too old. I get why; it takes people and time to review. It is sad though.

  • spaphy@lemmy.ml
    4·
    6 months ago

    If that’s happening to you that’s crazy. GitHub is way too noisy though. I get 30 notifications on that apps notification widget though for just bullshit I didn’t even know I signed up for or snyk or some other garbage.