> In most of the Open Source projects I've worked on there is a fairly
> lengthy period of "just send us patches" before a developer gets direct
> CVS access.
Ethan. forgive me if I put a word or two in your mouth. Feel free to
recant.
That is the case here, or certainly has been in the past. Ethan does
more on his own than most teams. That's his style. And basically, I
agree. The plugins are so modular that they lend themselves much more to
CVS style development. Nagios itself is much more monolithic and
intertwined. And if you look at the CVS changes going on now, you can
see that Ethan is much more free to progress by virtue of not
coordinating with a whole team, and not keeping the CVS always runnable.
It suits the scale of the project.
In fact, if you look at my nagios commits, you'd probably not find
anything outside of the the contrib directory and the RPM build
requirements. That was the agreement and I stick to it.
That being said, if you work out timing with Ethan, I've never had a
problem getting him to accept patches. Even for the original change to
autoconf, which was fairly big. You do need to respect the fact that not
all times are good for adding patches and Ethan will know very well when
is good and when is not.
> Since Nagios doesn't use the patch manager on Sourceforge, getting patches
> put in can be a bit tricky. Karl has been pretty responsive on getting
> patches covered, but a whopper like a variable rename across all the
> source files might take a bit to evaluate.
Again, I don't do that for nagios. Only the plugins.
> Nagios appears to be a bit more closed than most projects in that there
> are only two people with CVS access. Your chances are probably not
> good. I wasn't even going to ask...
>
> All of your goals can be accomplished via patches, and you get the bonus
> of running the exact version of Nagios you want locally, even if the
> patches don't get put in for a while.
That is the big advantage of CVS. Track the CVS tree. Keep your patches
working locally. Talk to Ethan about when is good to merge. Then feed
him a reasonable stream of manageable, reviewable patches. We'll all
have a better product, and you'll have the satisfaction of having
contributed.
BTW - I like some of your ideas very much. I have piloted automake on
the plugins. It's generally quite good. If Ethan feels we are getting to
the right time to start using automake, I could possibly help.
As far as #5, mirroring a server data off the status.log, I was just
thinking about that today - completely independent of your note. That
would be a great thing for me.
--
Karl
> On Fri, 7 Feb 2003, Andrew Meredith andrew-at-anvil.org |Nagios| wrote:
>
> > 1 - Are you guys open, in principle, to me doing some work on the
> > source tree. If the answer is that it is very complex cod and that you
> > would prefer it if the core developers were the only ones doing the
> > work then I would quite understand. If the answer is no, then please
> > take the following as RFEs rather than requests for permission for me
> > to do the work.
This post was automatically imported from historical nagios-devel mailing list archives
Original poster: [email protected]