* Neil Gorsuch <[EMAIL PROTECTED]> [03-03-12 09:50]:
> As I recall, the ganglia package was specifically voted to be moved to 3rd
> party status. There are core, included, and 3rd party packages. The
> tarballs and cvs tree should include "core" and "included", and should not
> include 3rd party packages. autoupdate, caching, disable-services, and hdf5
> were all discussed and agreed upon to be "included" packages.
OK. I miss this point ;-)
Package type :
- core
- included
- third-party
What is the exact definition of included & third-party ?
How is this choice make ?
How a package can change its type ?
According to their config.xml files, there are only two third-party packages:
documentation & ganglia in the OSCAR CVS repository.
I'm not convinced that this is more efficient or more interesting for OSCAR to
move the third-party packages out of the OSCAR tree :
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
- When using oscar directly from the CVS tree, you will have to
deselect one package manually.
+ 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
So the only additional disadvantage is that you have to click one
additional time for each third-party package included in the OSCAR tree
if you don't want to install it.
If I miss some points (- or +), please contribute to the list...
[
The particular solution to Neil's problem is simple : all third-party packages will
be deselected by default...
]
So I think the third propostion is still valid and interesting :
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.
The alternative is to create another SF project called, for instance,
oscar-packages, so that other developpers can easily access ressources,
development tools and remain in the OSCAR developper community.
However, I'm not in favor of this solution that tend to separate the
OSCAR community in two separate groups : "core-developpers" and "others".
I don't think that there is enough developpers to justify this choice.
But this is a personnal opitnion ;-)
Just my .000005$
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
