<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 6.5.7651.59">
<TITLE>Re: [Nagiosplug-devel] Forking the contrib section?</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->

<P><FONT SIZE=2>Thomas,<BR>
<BR>
I think your proposal is a good one. As a person who had patches caught in<BR>
the contrib / no author trap I think it would help. I'm happy to volunteer<BR>
time to help dig up old patches and get them submitted.<BR>
<BR>
It would be helpful if there was some mechanism to build a<BR>
nagios-plugins-experimental package from the mob branch, of course without<BR>
any guarantees about the behaviour of the result. Is that similar to what<BR>
you were proposing with the "/contrib git submodule" comment?<BR>
<BR>
-Simon<BR>
<BR>
<BR>
On 7/16/09 8:11 PM, "Thomas Guyot-Sionnest" <dermoth@aei.ca> wrote:<BR>
<BR>
> -----BEGIN PGP SIGNED MESSAGE-----<BR>
> Hash: SHA1<BR>
><BR>
> I was looking at some repository clone that included patches to /contrib<BR>
> and that got me an idea. The policy right now is to encourage authors to<BR>
> move away contrib plugins to Nagiosexchange. However many need the<BR>
> Nagios-plugins tree to compile, and most lost their original authors.<BR>
> Meanwhile some useful plugins in there get patches from time to time<BR>
> that we don't really want to apply because we don't really want to<BR>
> support that unsupported section.<BR>
><BR>
> I'd like to fork /contrib to a separate git repository and add a "mob"<BR>
> user (unrestricted check-in access to the "mob" branch) for people to<BR>
> commit things­, then we can do a short review from time to time and<BR>
> merge changes from the mob branch.<BR>
><BR>
> Think of this as a service to help the community maintaining these<BR>
> plugins without any guarantee regarding the quality and safety of these<BR>
> plugins from the Nagios-Plugins team. I believe that it would relieve us<BR>
> of that plugins section and help the community getting patches in.<BR>
><BR>
> /contrib could then become a git submodule that can be included for<BR>
> compiling the plugins.<BR>
><BR>
> Any comments  or objections?<BR>
><BR>
> - --<BR>
> Thomas<BR>
> -----BEGIN PGP SIGNATURE-----<BR>
> Version: GnuPG v1.4.6 (GNU/Linux)<BR>
> Comment: Using GnuPG with Mozilla - <A HREF="http://enigmail.mozdev.org">http://enigmail.mozdev.org</A><BR>
><BR>
> iD8DBQFKX+vb6dZ+Kt5BchYRAmr0AJ4/tJWKBoRzU6tsfLbilWNjP0/kjQCgiFuk<BR>
> n0H45WHiIEkKp3pA4od1M+k=<BR>
> =AOcL<BR>
> -----END PGP SIGNATURE-----<BR>
><BR>
> ------------------------------------------------------------------------------<BR>
> Enter the BlackBerry Developer Challenge<BR>
> This is your chance to win up to $100,000 in prizes! For a limited time,<BR>
> vendors submitting new applications to BlackBerry App World(TM) will have<BR>
> the opportunity to enter the BlackBerry Developer Challenge. See full prize<BR>
> details at: <A HREF="http://p.sf.net/sfu/Challenge">http://p.sf.net/sfu/Challenge</A><BR>
> _______________________________________________________<BR>
> Nagios Plugin Development Mailing List Nagiosplug-devel@lists.sourceforge.net<BR>
> Unsubscribe at <A HREF="https://lists.sourceforge.net/lists/listinfo/nagiosplug-devel">https://lists.sourceforge.net/lists/listinfo/nagiosplug-devel</A><BR>
> ::: Please include plugins version (-v) and OS when reporting any issue.<BR>
> ::: Messages without supporting info will risk being sent to /dev/null<BR>
<BR>
--<BR>
Simon Bennett<BR>
Sr. Director of Product Management<BR>
GROUNDWORK Open Source, Inc.<BR>
139 Townsend Street, Suite 100<BR>
San Francisco, CA 94107<BR>
415-992-4577 (direct)<BR>
415-947-0684 (fax)<BR>
sbennett@gwos.com<BR>
<BR>
</FONT>
</P>

</BODY>
</HTML>