[I changed the subject and put the case ID back in because I believe 
Bruce's points and questions related more directly to the case]

Bruce Rothermal wrote:
> There has been numerous mentions about OpenSolaris vs. Solaris.next 
> and /release and /contrib. That OpenSolaris belongs to the community 
> whereas Solaris is controlled by Sun. I really don't much care if this 
> package is in Solaris but I do need it in OpenSolaris. So from my 
> experience I only know of this one path offered to get packages into 
> OpenSolaris's /release repository and that is to go through a Solaris 
> consolidation. If anybody knows of some other way I would like to hear 
> it. So far all I'm hearing is a bunch of philosophying. Is there 
> anything technically wrong or harmful about this package. I have a 
> task assigned to port this package for a project to create a product 
> which we intend to sell and make money for Sun. I don't see what the 
> fuss is. It is a simple layered application which helps the user, 
> should they want to use this, to manage some environment for a 
> project. I don't see anything in this that makes it mandatory, 
> compulsory or in any way changes the Solaris or OpenSolaris 
> architecture. Nothing about Environment Modules is started 
> automatically or done hidden.
>
> So please advise if there is a different process for getting this 
> package into OpenSolaris /release repository or for that matter how 
> this simple little application will be destroying the 
> Solaris/OpenSolaris architecture?

For what it's worth coming from an "external" contributor, I'm pretty 
sure you're safe with the heading you were on.  The de-facto standard 
practice is to target /release for your type of project (Sun funded 
integration work), and near as I can tell, targetting /release means 
integrating into a consolidation.  I'm not personally happy with some of 
the particulars of that standard, but I don't think that should or could 
stop Sun's project teams from continuing to integrate in this fashion.  
I'm pretty sure you can safely ignore the bikeshedding tangent for now 
-- I doubt any possible resolution there would be of help to you or your 
team.

The question of where you integrate aside, best I can tell there are 
four (possibly) outstanding questions relating to your case:
1) Does it introduce a fundamentally new way to manage environments?
2) If so, is this mandatory or merely optional?
3) If mandatory, is this OK as a new Solaris "standard", or is this more 
like a Linuxism creeping in under the banner of familiarity?
4) If mandatory, is the footprint too big? (i.e. TCL coming along for 
the ride)

I don't deign to say what advice I would give if the answer to the last 
couple is yes.  As I consider that possible answer, concern raises in my 
mind about possible continued dilution of the Solaris brand, which I'll 
admit is probably an overreaction and maybe not even a valid 
architectural concern.  I believe the answer to #1 is already clearly 
"yes".  If the answer to #2 is "mandatory", or perhaps "optional, but it 
should be mandatory!", then you may have something here not completely 
obvious.  If the answer to #2 is clearly "optional", perhaps you can 
highlight that and I believe #3 and #4 probably fall off the page (and 
you can probably sail on under the familiarity wind, where many ships 
have already sailed).



Reply via email to