At 08:48 AM 3/12/2003 -0500, Benoit des Ligneris wrote:
Hello,
I think this question is linked to the modularity of packages and to the fact that we have no rules for allowing or not a package in the tree.
Technically, there are a large number of packages that are not core packages and that are in the OSCAR tree.
autoupdate cachingns disable-services documentation ganglia hdf5 ...
Well, as you see (ls -l oscar/packages), the list is very long.
I will not take ganglia as an example because lots of people are emotionaly involved ;-) but I think we should try to develop a politic relevant to all the packages that are not core packages.
Proposed rule 1 : =================
1) core packages are in the CVS OSCAR tree :
I think everyone agree on this one ;-)
Proposed rule 2: two versions ! ================
If we keep the classification (core packages and packages) then only two possiblities remains for the packages :
a) packages are not developped in the OSCAR CVS tree
- Move all the packages elsewhere - Reduce OSCAR activity *(splitted in several projects)* - When doing tarball with all packages : * need to download numerous packages * making a tarball will become more and more complicated - OSCAR developpers won't be able to fix the packages, only the maintainer and/or co-workers will be able to modify a package + Access to the OSCAR core component can be controlled more strictly
b) packages are developped in the OSCAR CVS tree
- Offer CVS access to all the contributors + Easy tarball ! + In case of emergency packages can be fixed by any OSCAR developper. + OSCAR activity higher
I find very few negative points for the 2-b approach and a lots of negative points for the 2-a approach. Please contribute to the discussion.
Of course, a middle way is still possible that will have this kind of formulation :
c) Packages can be developped anywhere but, if requested, an account and a
directory in oscar/packages/package_name/ will be created for this
package.
This last formulation seems interesting as it gave the freedom of choice to the package author and it is the less restrictive of the three propositions. Moreover, it corresponds to the actual state of OSCAR tree (most of the packages are developped in the OSCAR tree and a few (clumon, thin-oscar) have their own development infrastructure.
Ben -- Benoit des Ligneris Etudiant au Doctorat -- Ph. D. Student Web : http://benoit.des.ligneris.net/ Mydynaweb Developpe(u)r: http://mydynaweb.net/ Centre de Calcul Scientifique http://ccs.USherbrooke.ca/
OSCAR Symposium-May 11-14 http://oscar2003.ccs.USherbrooke.ca/
------------------------------------------------------- This SF.net email is sponsored by:Crypto Challenge is now open! Get cracking and register here for some mind boggling fun and the chance of winning an Apple iPod: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en _______________________________________________ Oscar-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/oscar-devel
-------------------------------------------------------
This SF.net email is sponsored by:Crypto Challenge is now open! Get cracking and register here for some mind boggling fun and the chance of winning an Apple iPod:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en
_______________________________________________
Oscar-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/oscar-devel
