Patch for Plugin "No Output"

[Andreas Ericsson]

Ton Voon wrote:
> 
> On 1 Nov 2006, at 12:06, Andreas Ericsson wrote:
> 
>> That's what I do with nagiosplug as well, btw, but we're facing quite a
>> bit of problems with merging our changes since we forked with the
>> changes in upstream.
> 
> Bingo!
> 
> Juggling patches is horrible. We do it in a manual way (I think it is 
> similar to how Debian uses dpatch) and publish all our patches 
> (http://source.altinity.org/source/ under patches/). It is a pain the 
> arse, it is slow, it is hard to patch a patch, etc, etc, etc.
> 

So you would prefer that everyone who made patches set up a webpage 
where you would have to look for them? What happens when you have 20+ 
developers hacking away on the plugins? Will you check all pages each 
day, or will you ask them to send them to you by email?

> But we keep doing it this way because then it is in *our interest* to 
> get our patches back upstream to the main core code. It stops us doing a 
> complete fork. In short, it keeps us honest.
> 

I completely and utterly fail to see what honesty has to do with it. In 
my experience submitting patches goes like this:

Find the bug.
Possibly post info on the bug on mailing list or, if it's easy enough, 
on the project bugtracker.
Fix the bug if you can.
Send the patch to the proper email list, or attach it to the 
aforementioned entry in the bugtracker.
Time passes...
If patch still isn't applied (or commented) upstream, nudge the 
maintainer and possibly re-send it.

Posting patches on websites don't work, because it doesn't scale beyond 
two or three contributors.

> Use of git or whatever local SCM system you use, makes it easier *for you*.
> 

In this case git also makes it easier to exchange patches, as patches 
sent by git can be applied by regular patch while I don't have to worry 
about the order in which they should be applied, as they already ordered 
nicely by the DAG in my repo (the patch-sending tools makes the order 
obvious to the recipient). They can also be fetched from the web 
completely automagically by the simple expedient of visiting a gitweb 
page, without us having to do anything manually apart from developing, 
or anyone can fetch all our changes with one simple command and get 
everything we've done in one go, even if they don't have the code-base 
from nagiosplug earlier.

The merge-back problems we're facing wrt nagiosplug has nothing to do 
with us not juggling patches manually, but everything to do with the 
fact that we did development completely separate from nagiosplug for 
several months and didn't bother merging in the changes made upstream. 
We weren't (and aren't) interested in localization fixes which, 
unfortunately, took up much of the nagiosplug developers time when the 
fork occurred.

It's also worth noting that "make it easy for the contributor" is a 
highly prioritized task by most maintainers of opensource projects, as 
no programmer will jump through hoops to get a couple of lines of code 
accepted upstream. Otoh, if contributing is as easy as "code, commit,
run the send-patches command", you'll see an endless stream of 
contributions which, in the end, brings *your* project forward much 
faster than if you had to do all the coding on your own.

-- 
Andreas Ericsson                   andreas.ericsson at op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642