[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).