Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

djberg96 (2603)

djberg96
  (email not shown publicly)

Journal of djberg96 (2603)

Wednesday March 13, 2002
02:32 PM

Patch etiquette?

[ #3492 ]
Recently, I politely suggested to the author of Net::SCP that he use the Expect module so that passwords could be passed automatically. Unsure of the author's familiarity with Expect, I provided a small demo program to show him how it would work.

His response? A short email that said only, "No patch? Oh, well. Take care".

I was like, WTF? What does *that* mean? First of all, it's not technically a patch, since I'm not *fixing* anything - just extending the functionality. Second, given how *incredibly easy* it would be to implement this, why wasn't the demo program enough? Lastly, even if it *was* a patch, should I be *expected* to provide it? What is the general consensus on this?


List all Journal entries
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

Patch etiquette? 9 Comments More | Login | Reply /

 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.

  • patches welcome (Score:1, Informative)

    by jmm (276)
    It's been a few years since I read p5p, but a common expression there was "patches welcome". It was shorthand for "I'd like to see this fixed/changed but if you wait for me to get around to it, it'll probably be a while. If this matches someone else's itch to scratch, go right ahead and figure it out for me."

    The Linux kernel project is especially bad in this way - if you want a change, you need to not only put together a patch to implement it, but also keep updating the patch to keep it up to date as oth
    • I think a better translation is, "If you want it, you do it." Sometimes it may be something the author/maintainer wants, as you note, but often it is something he will accept, but doesn't particulary care about, and will probably never do.

      I rarely expect patches, although if it is some new feature that isn't needed, that no one has previously expressed a need for, and is not a bug in any way ... you can file a feature request, but I won't do it, most likely, unless it is something I also want. So yeah, i
      • Firstly, yes, it would be a patch; patches are not just for bugs, it is any modification

        Oh, all right...

        ideally, you would provide not only a working patch that he could just use, but also patches for the documentation and for the test suite

        There is no test suite. The documentation change would be so trivial, I didn't bother. The 'scp' command would remain unchanged. The 'login($user)' would change to 'login($user,$passwd)'. It's *that* trivial.

        ...what is expected is really up to the author

        The

        • If it's trivial, then there's no reason not to!
          • Hmmm...difference of philosophy here, I think. If someone were to submit a patch to one of my modules that extended its functionality, I wouldn't expect documentation. I don't even expect code - for me just an idea is good enough - though I would ask for coding help if I needed it. To me, it feels like doing someone else's homework.

            Now, my attitude would be different for a large project with a large patch proposal. But for this? I figure the entire module is somewhere around 100 lines of code, if you

            • Maybe you wouldn't expect documentation, but that's irrelevant. You are asking for someone else's time and effort for your needs, and just to be nice you should make his job as easy as possible. If you are unwilling to do that, then it is odd that you would be offended when he is unwilling to help you.

              Again, I think his response was rude, but you can't expect help or code or action of any kind. To expect those things from someone not obligated to you is similarly rude. You should therefore provide what

        • Re:patches welcome (Score:4, Insightful)

          by Matts (1087) on 2002.03.14 5:17 (#5882) Journal
          I agree with pudge (and autarch). If it's all *that trivial*, then go ahead and do it. I never could get my head around the attitude of *not* giving back to open source projects where you can. I write lots of open source perl modules. One of them, XML::XPath, took me intense working on nothing but that module for about 6 weeks. That was about $20,000 worth of work compared to what I was charging out at the time. But never did I ask for that money back - just that people appreciate the work and GIVE BACK, although perhaps more importantly PAY IT FORWARD. I'm not saying you don't pay it forward (I see you have open source modules of your own), but many people don't.

          Maybe the author is really busy, or bored with the project, or is sick, or has other commitments. Also, even though it's trivial for you, it may not be trivial for the author who may not have worked on the module for some time, to start up the whole development process for that module once again.
  • I sometimes do respond to feature requests for my modules with something along the lines of

    "That sounds like a good idea, but it doesn't scratch my itch all that much so I probably won't get around to it anytime soon, if ever. Patches are always welcome ;)"

    I think that's polite enough.

    And of course, sometimes it's better to not work on a patch unless you think the author will accept it. If I plan to offer a big patch I usually ask the author if they want to implement feature X _and_ tell them I will se
Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.