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
