There will always be packages that we don't want to include in the oscar tarball. In fact, we want to encourage developers to make oscarized packages, and have them be available through opd outside of oscar. It was decided for a number of reasons to put ganglia into this category, and I for one would never want to see it move back to the included category.

At 10:35 AM 3/12/2003 -0500, Benoit des Ligneris wrote:
What is the exact definition of included & third-party ?
How is this choice make ?
How a package can change its type ?

Core and included packages are decided on by a consensus of the core group. All other packages are 3rd party.


According to their config.xml files, there are only two third-party packages:
documentation & ganglia in the OSCAR CVS repository.

Documentation is always needed as part of oscar, if it shows up as a package, it should certainly be set to "included". Ganglia is as it should be, and as it was decided.


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 :

Under no circumstances do I want to see anyone that wants to make an oscar package have the right to automatically include it in the oscar tarball. This needs to be decided on a case by case basis.


[
The particular solution to Neil's problem is simple : all third-party packages will
be deselected by default...
]

That is not the problem. The problem is that a 3rd party package is still in the cvs tree when it shouldn't be, the package sometimes doesn't work on my configurations, and I shouldn't have to "deselect" it, it's not supposed to be there in the first place.


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.

No, oscar is not going to turn into a mini-sourceforge within sourceforge. 3rd party packages can easily make their own arrangements for development space outside of oscar.


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.

That's up to the 3rd party developers.


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 ;-)

We are not seperate groups. but the core and included package developers are a subset of the overall oscar community. Being in the core is by invitation.




-------------------------------------------------------
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

Reply via email to