On Wed, Apr 12, 2006 at 01:30:17PM -0500, James Dickens wrote: > Sounds like it will be impossible to get rolling. /opt/sfw is allready > owned by CCD group. That group is about as closed as it gets, just
This is news to me. I wasn't aware that such a 'CCD group' exists at all. One possibility is that your assertion regarding its closed nature is even more accurate than I would have imagined, and this group is so secretive that even I'm unaware of it. Another is that you're incorrectly assuming that because there has been silence regarding updates to this content, it must be that the people responsible for doing so are operating in a closed manner; in reality, the reason for silence is that no such group exists. > this morning i wrote a response to an email about how CCD and > Blastwave can co-develop I think its also on topic for this mailing > list so i'm including it here as well. > > The CCD and Blastwave are two projects that aim to do the same thing, > but in totally different ways. They have totally different > construction methods, focused on totally different audiences, and > basically are incompatible. CCD has spent the better part of a year > working on its current release, totally closed off from the OpenSource > community. No mention of progress, no public alpha or beta releases. Ah, so you are equating the SFW C-team with this mythical 'CCD group.' In fact, the SFW C-team has been focusing its energies on the SFW consolidation rather than the CCD. That focus has paid off with a release of that consolidation to open development. I can't pretend I'm happy about how long it's taken us to get to this point. The project proposal is evidence that we are about to start making the kind of progress you're looking for, and wish to do so in an open manner. > No community input as to what packages are included. The source code > and modifications are supposedly made available sometime after release > but it certainly isn't out in the open. Made by one person for a > select crowd that is willing to use one to 2 year old versions simply > because it was blessed by a team at sun and the "Sun" name is placed > on it. The CCD project is about as closed as an "open source project" > can get. CCD is the only distribution that makes Debian stable seem > fresh and new. These are exactly the aspects of CCD development which are to be corrected by this project. I read a great deal of bitterness in your assessment of the CCD's status; while it may be justified by past decisions, the individuals responsible for those decisions are no longer in control. It would be more constructive for you to recognise that: (a) a tiny team of volunteers within Sun is working to open the CCD to the kind of development and community-focused decision-making processes which have historically been absent, (b) Sun has not had resources allocated to improving the CCD for well over a year and still does not, (c) all of your criticisms would have applied to Solaris itself prior to the OpenSolaris program, and that this program has already been the vehicle for major changes of exactly the type you seem to desire. > How can CCD and Blastwave co-develop anything? CCD is hidden, and > Blastwave is public and moving towards being more public, CCD installs > its libraries in a different location and most likely use different > arguments and goals in building its distribution. Even 6 months after > release CCD packages will on average of one or two releases behind. Let's consider these concerns one at a time. First: "CCD is hidden; Blastwave is public" Both parts of this assertion are misleading. I believe I have already explained that the purpose of the proposed (and now approved) project is precisely to open the CCD. Blastwave's "source" (essentially the type of materials released with the SFW consolidation and the type which will be opened to the world through this project - the scripts, makefiles, and other infrastructure for turning source tarballs into SVR4 packages) is entirely hidden even from its users. If, for example, I wish to alter the build parameters for a certain component and produce my own packages, there is no way for me to do so. I recognise that this may be undergoing change as well, so the correct phrasing here would be closer to: "Historically, both the CCD and Blastwave were completely closed. Both are currently undergoing changes to make development more open, centralised, and visible both to contributors and users." Second: "CCD installs its libraries in a different location." True. But then, Solaris installs its libraries into yet a third location. Does this mean those libraries are useless? Of course not. The real problem I suspect you're trying to describe here is that each of these stacks contains different and probably incompatible versions of the same software. Intermixing libraries from the two stacks in the same address space would likely lead to application failure. This absolutely is a problem, but it is not directly related to your stated concern. Indeed, segregating these two stacks is not only not a bug, it's downright necessary as a workaround for the real bug, which is that there are two separate stacks in the first place. Third: "The CCD software will always be out of date." This argument really exposes your desire to attack rather than cooperate. You have assumed, incorrectly, that the CCD will always be "a CD shipped with Solaris." Nothing could be more wrong. We have not committed to delivering any hard media into Nevada or subsequent releases. The Java-based installer has been removed from the S10U2 and Nevada companion products, and the integration into the Solaris installer as a co-bundled option has been removed as well. Instead, we envision a distribution model much closer to Blastwave's (or to any number of similar systems with which you may be familiar, such as Gentoo or the BSD Ports systems). The specific mechanisms and policies for this distribution model remain to be developed - and will be openly contemplated under the auspices of this project. Thus, once this is in place, there will be no reason for this "Companion Software" to be out of date. Even in the absence of such a comprehensive network-based distribution scheme, regular biweekly builds will be run to make packages available, and the source itself will be available in realtime. Thus components should be out of date only for one of the following reasons: (a) it has no owner - since you care that it's out of date, you should volunteer to become the owner! (b) its owner has been remiss in his or her responsibilities. Consider contacting that individual. This works in exactly the same way as in other software distributions. (c) there are sound technical reasons to continue using an older release of the component. > Thus all of its libraries will be useless to Blastwave. Most of the > non Sun OpenSolaris distro's are about being new, fresh, and > inventive, Blastwave embraces them and helps to extend them; CCD > probably won't be compatible with them so once again CCD will be > useless for those communities as well. More groundless assumptions here, I'm afraid. > I guess if you have the "magic pass key" into the CCD project aka > being a Sun ID holder, so that you actually have input and can > actually see what is happening you can get excited about the totally > secluded project, for me even if it has the latest everything on > release date, it will be a non issue because the project goes against > every OpenSource principle, just the way that the Sun people that are > pushing the project like it. If they didn't want it that way, the > process would have been opened years ago, or at least post OpenSolaris > launch date. The only thing my "magic pass key" has entitled me to see is the extent to which the CCD has been neglected by Sun. That neglect is responsible for both the stale nature of the content itself and the lengthy delay in opening this project (put another way, the lengthy delay in enabling non-Sun contributions to CCD development). Instead of castigating the dedicated volunteers who are contributing our personal time to making the very changes you so bitterly demand, you would do well to discard your mistaken assumptions and participate in the steps we're trying to take. In the next 1-2 months, we expect to: - offer a means for individuals both within and without Sun to become owners of any Companion Software component, - provide direct realtime access to the source base, including the ability to make changes without a Sun sponsor, - expose an inventory of software, with owners, similar to that provided by Blastwave and other products, - document the steps necessary to contribute a Companion Software component, the steps necessary to build and deploy Companion Software, and the tools used in developing the source base, - become an early prototype for realtime collaborative development processes and tools which will later be used by OpenSolaris consolidations, including SFW and ON. Long-term success for this project would (in my personal view) include all of: - voluntary and cooperative incorporation of all other third-party companion software stacks, including both Blastwave and Sunfreeware, and - at least as importantly - their stewards, maintainers, and contributors, - agreement on a single unified distribution model, - innovation in areas of interest to all software distributions, such as improvements to autotools and pkg-config, - a meaningful and reasonable solution for support of multiple distinct Solaris releases, and possibly distinct releases of other OpenSolaris distributions as well, without the maddening and wasteful duplication of (usually incompatible) software, - a dramatic increase in the size and scope of available software even beyond the union of the SFW, CSW, and Sunfreeware offerings. We welcome most enthusiastically contributions from individuals associated with other efforts in this space, and invite an open and constructive debate concerning solutions to any or all of these important problems. And we'd like all of this to take place on the project mailing lists, not opensolaris-discuss. -- Keith M Wesolowski "Sir, we're surrounded!" Solaris Kernel Team "Excellent; we can attack in any direction!" _______________________________________________ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
