Nicolas Williams wrote: > On Tue, Sep 01, 2009 at 10:46:55AM -0700, Garrett D'Amore wrote: >>> >>> - /contrib is a not good place for Sun projects to integrate into -- >>> aim for /dev & /release if you can; >> Why? I think /contrib is perfectly reasonable for projects that just >> want to enable something, and don't want to make support guarantees. We >> have no other way to deliver 'caveat emptor' bits that I can see. If >> /contrib works for the rest of the community, why not also Sun?
I agree. > Precisely because there's no commitment to keep anything in /contrib > working. That's fine for: a) random third parties, b) as a stepping > stone to /dev and /release (e.g., for alpha and beta testing purposes). I think that generalization limits us. The contrib repo is a community driven place to put OpenSolaris software packages and serves multiple needs. Some packages are well maintained some aren't. Some packages may be destine for /dev and /release, and some may live in /contrib indefinitely. /contrib gives us a lot of options that we can leverage. >>> - What is the architectural status of /contrib? IMO: none. /contrib >>> is for third party contributions that are not yet ready to integrate >>> into /dev & /release; It's more than that. Many /contrib packages have no interest in moving to /dev or /release nor can Sun support an infinite number of packages. Also, /contrib packages can take advise from ARC and meet most if not all the Solaris architecture rules, and the community can decide how closely ARC rules are followed. The /contrib repo in conjunction with the Source Juicer and Package Factory is primarily a mechanism to quickly increase the software content of OpenSolaris to better satisfy the needs of OpenSolaris end users and developers. Beyond this we have a lot of room to grow and the ARC teams can provide a lot of guidance. >> I'd really like to have something like "External", which would mean that >> Sun (or the Solaris org) makes no guarantees about interface stability, >> we just follow the upstream. Caveat emptor sort of thing. > > Yes, I agree with this. We need an adjective that indicates that > something is of third party origin and that advertised interface > stability is advisory only, not necessarily reliable. Yes. A clearer tie with reality would be good. >>> We might even need to deliver more than two versions of some FOSS. >> This way generally lies madness. There are some specific counter >> examples were it has worked out (multiple perl versions for example), >> but doing this generally for shared libraries will cause huge kinds of >> problems. We need to have this flexibility on a case by case basis. We need to keep our options open, so we can continue to evolve. Some parts of the architecture need to be static and some parts can bend and evolve into new taxonomies. There are too many approaches to open source code and code releases to blindly apply one set of architectural constraints to all packages. > We will have these choices when the upstream community breaks > compatibility: > > a) don't update; > b) warn, update and break compatibility and oh well; > c) deliver multiple versions, risk DLL hell; > d) fund an effort to restore backwards compatibility and contribute the > fixes back upstream; > e) fund an effort to restore backwards compatibility and fork; ... >>> The practically inescapable conclusion is that we should just allow out >>> of cycle backwards incompatible changes (after some teeth gnashing, >>> perhaps), >> This has already happened for specific cases. I think its OK but it >> needs to be an exception and such cases carefully reviewed for impact. Right. Review allows us to engage with the specific case and consider the bigger picture and see what fits and what doesn't, and do our best to meet the needs of current and future users and developers. Cheers, Jim
