[Nagiosplug-devel] check_udp
Andreas Ericsson
ae at op5.se
Fri Mar 24 10:34:01 CET 2006
Ton Voon wrote:
>
> On 24 Mar 2006, at 10:44, Andreas Ericsson wrote:
>
>>> I'm trying to commit my changes but SF cvs seems to be out at the
>>> moment.
>>
>>
>> Migrate to git and I'll host it for you at ghost.op5.se (no, I won't
>> keep nagging. ;) )
>
s/keep/stop/
>
> Thanks for the offer, but I can't see this happening. The hosting of
> the source code should be in the public domain. I'm not prepared for my
> own company to host the source code, so I wouldn't want to move it
> anywhere else.
>
You're thinking the one hosting the repo will control the source-code,
which is true for CVS but not with a distributed repo model. Since all
developers' individual repositories are complete replications of the
public one, including full commit-history, there is no single person
controlling the source-code. Each developer just controls his/hers clone
of it, with one or some of them having write-access to the public
repository that end users clone and pull from. This has several benefits:
1. It's a lot easier for new developers to start hacking on the
source-code. They don't need CVS access to keep their changes small and
they don't need to juggle patches.
2. Trust can be distributed. Very few people should have write access to
the public repo, but those few can pull from other users they trust
(this is how Linux development works) or apply patches sent as email
(enormously simple with git, tricky with CVS). F.e., I could have
several patches to check_icmp in my repo. When you or Sean think it's
time to incorporate them into the public distribution you simply pull my
repo into yours and then push the resulting merge upstream. If you don't
like the code you pulled from me you can easily undo them, add fixes on
top of them or revert them completely before making them public.
3. Experimental development can be done inside the scm tool, using a
separate branch (in git'ish this is called a "topic branch"). This is
completely impossible with CVS (or any centralized repo model) but
highly useful since it enables developers to rapidly experiment with
various approaches *inside* the scm rather than beside it (or, again,
juggle patches).
> (Snapshots are a different matter - I'd be up for offers from anyone
> that wants to host those)
>
Snapshots is what sourceforge is good at, but keeping up to date and
actually doing work with the sourceforge repo is just plain murder for
me (a simple cvs diff takes in the vicinity of 30 seconds when it works
at all - clearly unbearable).
The fact that I couldn't branch it and apply our changes on top of what
was in the trunk while continually merging the changes was the main
reason I once forked the plugins completely, and now I can't go back
without a significant (too much) effort, which is bad for both of us. :(
An SCM with a distributed repository model would do a world of good. I
just happen to think that git has the best email-patches /
apply-from-email tools of the distributed scm's, which is why I so
adamantly keep suggesting it (the Sourceforge tracker thingie is another
thing that's too slow and cumbersome to work with imo). Then development
could be done largely on the mailing list, meaning instant peer review
(and thus bugfixing, since 10000 eyes see more than two) and user
feedback from knowledgeable people. There's also another benefit from
this: When code is in the open people get an urging to correct what's
wrong, meaning a bigger chance of getting more developers.
> In fact, the only way I can see that the Nagios Plugins would be moved
> off Sourceforge is if there was a Nagios company/foundation that was
> independently run, ala the Mozilla Foundation.
>
> Actually, there is the possibility of hosting it on Savannah...
>
That doesn't help with the centralized repo model though, unless
Savannah can host repositories for arbitrary scm tools.
--
Andreas Ericsson andreas.ericsson at op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
More information about the Devel
mailing list