Patch etiquette?

djberg96 on 2002-03-13T19:32:25

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?


patches welcome

jmm on 2002-03-13T20:58:07

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 other patches get merged in ahead of yours.

So, it's not unreasonable for a module maintainer to hope for changes to be submitted as a patch, maybe even including test cases to prove that the patch works.

However, unless you're maintaining a huge project like perl or Linux, it is somewhat rude to expect patches.

Re:patches welcome

pudge on 2002-03-13T21:50:09

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, in some cases I expect patches. But I feel the response as given in the journal entry above was rude; I'd try to say it more nicely than that. Then again, we're all fallible and most of us are prone to rudeness on occasion. I don't find any problem with what he said, aside from the tone, though.

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?

So to answer these questions directly:

Firstly, yes, it would be a patch; patches are not just for bugs, it is any modification.

Secondly, no, it is not enough; 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. This also means following his style of coding and documenting etc. as closely as possible. Is that a lot of work? Maybe, but it would be a lot of work for him, too. Maybe less for him than for you, but you're the one who wants the feature.

Thirdly, as noted above, what is expected is really up to the author; what I usually do is say "this is a feature I like; I can supply a patch if you would accept it." Usually, if they respond, they either say no, they wouldn't accept it, but thanks anyway; yes, they will accept it; or they like the feature, thanks for the idea, they'll look into it themselves.

Re:patches welcome

djberg96 on 2002-03-14T00:14:26

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 author's own FAQ heavily suggests that he's been asked about adding this feature before. Hmmm...now that I think about it, maybe that's why he was snippy. He's been asked *so many times* that he's tired of answering it.

Ah, well. No big deal I guess. Besides, I'm just waiting (and yes, I can wait) for Ben Trott to implement Net::SSH::Perl::SCP at which point this whole topic becomes moot. :)

Re:patches welcome

pudge on 2002-03-14T04:50:57

If it's trivial, then there's no reason not to!

Re:patches welcome

djberg96 on 2002-03-14T13:55:47

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 exclude comments & POD. Besides, I'm ultra paranoid about trusting other people's code, or their documentation. I'm probably a bit of a control freak in that regard, but if something goes wrong it *is* my name listed as *author* (well, co-author at that point I guess).

Well, anyway, this whole thing has inspired me to write Net::SCP::Expect, coming soon to a theatre near you. And I see there's a new release of Expect today. Perfect.

Re:patches welcome

pudge on 2002-03-14T17:15:56

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 whatever you can -- if not in actual patches, in an offer of patches, including all relevant documentation and tests -- when you request a change and are capable of doing it yourself.

Re:patches welcome

Matts on 2002-03-14T10:17:12

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.

Sounds pretty rude

autarch on 2002-03-13T21:16:02

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 send a patch if they say yes.

For the record, the term "patch" has nothing to do with whether it's a bug fix or not. A patch, in theory, is working code. A suggestion is nice but much less useful than a patch (well, at least than some patches).

Re:Sounds pretty rude

pudge on 2002-03-13T21:51:20

Oops, autarch had already posted what I posted, much of it. Oh well. :) I guess that's consensus!