On Thursday 20 April 2006 06:10 pm, Philip Brown wrote: > 1. Something that is "supported", for *free*. > Anyone can file bugs on related packages, and anyone can see > bugs on these packages
I'm not sure I follow you here. It seem open source software is pretty much unsupported. Are you saying the Sun should support it for free? I agree that anyone should be able to file bugs on these packages, but I'm unclear on what you label "supported", for *free*. > 2. Some kind of standard for keeping versions reasonably up to date with > stable releases of each product/library from the net. Yes, I don't know how to dictate how that happens, but it seems mostly driven by the needs of the software. If package foo needs a new libxml, but package bar doesn't and/or can't function with the newer one, there needs to be some way to determine which version to have in the tree. > 3. In contrast to the above, some kind of QA/release process. > It would not be appropriate to meet #2, by saying, "okay, we'll just > compile and ship em the day new versions are released". > I shouldnt have to say this for a Sun project, but Sun has done some > very unexpected things of late, so thought I'd spell it out :-) There have been a lot of changes and a lot of putbacks into nevada, but is there something specific that you consider "very unexpected things"? Ultimately I think Sun needs to continue to move forward and to be better about working with the community. That is happening, and some things are known and some things are not known in the community. Maybe there's something that is specific that we can try to work internal, is why I ask. > 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. Why would you want that? Seems this is a problem with the current model that we've been using, which I thought was a temporary process. > 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. Sure, I think this is something that needs to happen, one way or the other. There are some limitations to Sun's servers, and in some ways it's better for us to use other external servers if possible, to host the packages. Like genunix.org for instance. > 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. ??? For unsupported software? I think this gets down to how this project unfolds, but I see it as an advantage to have open access and participation from the community and Sun alike, there is no distinction, IMO. > [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] I don't think that is Sun's intention, and I really think that at some point the community needs to give some trust in Sun for what they're doing. AFAICT, Sun is fully committed to having folks work on OpenSolaris, and to liason with the community. There seems to be some misconception that Sun is trying to offload development on the communtiy, at least you made reference to such (i.e., moving away from a support model), and I don't think this is the case as much as that is the way that open source software works. There is no support implied by using it, and there is no liability. What type of support does Red Hat provide for Fedora? What type of support do companies offer for free? I'm sure Sun would support it for a fee, or at least they should, no matter if that fee is very high, they should still offer some support for that. if folks would like to pay. Sun can't support anything for free though, that should be clear. > > > 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 > > 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. > 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. > _______________________________________________ > companion-discuss mailing list > companion-discuss at opensolaris.org > http://opensolaris.org/mailman/listinfo/companion-discuss -- Alan DuBoff - Sun Microsystems Solaris x86 Engineering
