Patch for Plugin "No Output"
Andreas Ericsson
ae at op5.se
Wed Nov 1 16:57:15 CET 2006
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
More information about the Developers
mailing list