[Asterisk-Dev] "contrib" directory?

[John Todd]

A Sourceforge site sounds like a good idea, if there is no final 
momentum to get something added to the Digium CVS for inclusion into 
the main Asterisk distribution.  This may be the only option for 
people who wish to submit elements that are strictly GPL'ed (or 
otherwise licensed outside of the Digium disclaimer) for political 
reasons within their development effort.  This is not a minor point; 
some firms have no problem with "pure" GPL, but those same managers 
may hesitate to sign the Digium disclaimer due to FUD.  Note that I 
am not volunteering myself to manage the Sourceforge site; I have 
plenty of other things on my plate right now.


I think, however, that more people will participate and use projects 
that are included in ../src/asterisk/contrib  if they are a standard 
part of the distribution with Asterisk.  The submissions to the 
contrib directory could be under the same rules as regular 
submissions to Asterisk, except that they won't be compiled 
automatically and might be a little more geared towards the expert 
user.  Direct write to the CVS tree can still be controlled 
exclusively by Digium folks, if that's what they want, or individual 
sub-packages in ./contrib may be able to be update'ed by those 
outside of Digium if they have signed the appropriate disclaimers and 
are clueful enough to be given those permissions.

Other options are making contrib an optional download (i.e.: not part 
of the main asterisk directory tree, like gastman is) or a tarball.

JT





At 3:03 PM -0400 9/2/03, Jeremy McNamara wrote:
>
>I setup http://asterisk.sf.net (http://www.sf.net/projects/asterisk) 
>quite some time ago and it is not being used for much.  If someone 
>wants to mange that site I would be willing to give them admin 
>access.
>
>Jeremy McNamara
>
>John Todd wrote:
>
>>I've seen a few very interesting but very specific patches and apps 
>>released here on the list over the last few months.  Quite a few of 
>>these are very vendor-specific, or they would be little used by the 
>>general population but very handy for certain small sub-sets of 
>>users.
>>
>>In the path to releasing "versioned" updates, perhaps it would be 
>>worthwhile to consider a "contrib" directory, which would contain 
>>all these nice (but narrow) features and scripts.  These may or may 
>>not even be built with the main tree when compiled, but their 
>>inclusion and usefulness are such that they should not be relegated 
>>to the abyss of the mailing list archives.
>>
>>Thoughts?
>>
>>JT