On Thu, Apr 20, 2006 at 06:10:16PM -0700, Philip Brown wrote: > Addendum: Sun employees should have exclusive access to make changes. > "community" folks can always submit patches, whatever, but someone > at Sun, officially on behalf of Sun, has to approve and integrate > suggested changes.
I disagree. This is arguably the least desirable and most annoying aspect of the temporary process in place for ON: it's slow, it's inefficient, it does not scale, it establishes a clear class distinction between those with Magic Sun Badges and those without, and it imposes tremendous cost on Sun. The way forward for OpenSolaris is the exact opposite - eventually, there will be no distinction at all between Sun and not-Sun with respect to development of the open codebases. Is there some reason you believe this project should operate differently? > 4. Easy to get/update over the net, with no stupid > "sign/click to get access" limitations. > > pkg-get is of course a great way to do this ;-) but no reason sun couldnt > support multiple access methods. Disk is cheap. One of the things we need to think about is the ability to obtain packages from several different distribution points, probably in preference order. Rationale: one of the main distribution points will presumably be opensolaris.org; however, Sun's stewardship of this site imposes unfortunate limitations on the software which can be distributed from it. Packages which are useful but which Sun is unwilling to distribute (i.e., libdvdcss) must be transparently obtainable elsewhere using the same tools. A general solution to this problem will also enable local package repositories, simplify integration testing of new packages, and allow for adaptation to arbitrarily stupid legal domains. > 5. A commitment from sun to keep doing it with at least X number of people, > for at least Y number of years, up front. This is unrealistic. We're running a business here; if, and only if, Sun decides it's in Sun's interest to allocate resources, it will do so. Given that no one is paying Sun for support of this product, Sun would be foolish to enter into a written contract promising that support. Like all companies, Sun does not have fixed staffing, so the person who makes such a verbal commitment today may not be with the company tomorrow. Frankly, I consider Sun's (at least occasional) lack of interest in the Companion or its successor in spirit to be a given; fortunately, OpenSolaris offers us an opportunity to bypass Sun management's priorities in favour of our own. One of the key benefits of decoupling the development process from Sun's business priorities (see response to 'Addendum' above) is that the work can continue at perhaps a slower pace but without any degradation of quality, efficiency, or scalability if Sun decides to withhold funding. With the entire package repository and tools open to development and no defined role for Sun in the development process, Sun's support for ongoing improvements is of little import to the project's success. > [the reason for this verbiage being that sun can (and has) committed to > "supporting" things, while in reality shelving the product and leaving > just an empty, dead shell to poke at] This is somewhat different in that Sun has always explicitly disclaimed any level of support for this product. I believe this practice should continue; if there is sufficient demand for support, a company like TWW could elect to enter the market, and/or Sun could begin offering support contracts for a fee. > 6. The software should be provided as binary packages that are usable by > every single "currently supported" version of solaris recognized by Sun. > This may mean separate packages, for separate versions of the OS, > if extra-special compile options are desirable > fine by me. But no leaving Solaris 8 out in the cold, until it is > officially EOL'd by Sun. > If blastwave can do it, Sun sure as hell should be able to do it :-P I continue to contend that this is a 'desirable' rather than 'mandatory' feature. I have yet to see any proposal for how to accomplish this in a way that does not penalise users of the most current OpenSolaris-based distributions. > 7. The software packages need to be freely redistributable in and of > themselves. Anyone should be able to take one of the sun packages, and > put it on a website/ftp site/cdrom/dvd/bittorrent/WHATEVER, without > having to go through extra legal hoops. If this is not already the case, you're absolutely correct that it needs to be. Some licenses do not allow restrictions on the distribution of binaries, so I'm quite sure the existing package collection is already redistributable. Do you have information to the contrary, or is this requirement instead an attempt to constrain the set of software which may be accepted for inclusion? > One thought here, being that it is critical that someone who compiles > software using those sun-provided freeware libraries, should be > able to redistribute both their binaries, and the sun ones, on the > same media, without a legal agreement with sun. I don't understand why this is important (after all, the system libraries are already a part of OpenSolaris) but I don't see anything that would prevent it. -- Keith M Wesolowski "Sir, we're surrounded!" Solaris Kernel Team "Excellent; we can attack in any direction!"
