John, > This means that, depending on their release taxonomy > bindings, changes that are allowed in OSCE might not > be allowed in OSM or OSEE. (duh! :-)
One of the questions I'd like to answer with the new plan is to find a way to get stuff into some form of OpenSolaris which are not on a roadmap to be in a supported version -- the same way that Linux distros do, such as Fedora and Debian-unstable. There should be a way for things to get into an Opensolaris edition which do not go though the full ARC process; we just check that their file paths are acceptable, flag them as "unsupported" and leave it at that. As an example, it's probably in the future that Sun Solaris will not support every single release of PostgreSQL; they are too frequent and users are too reluctant to upgrade, so we will probably skip some releases. But we want to offer the "cutting edge" versions in an unsupported, rapid-release fashion for the users who care more about the latest features than they do about API stability. I'd like a way to do that which is more mainstream than the current Blastwave <-> Solaris relationship. So if that's OSCE then I'm for it. > When I read your comments above, I get the impression that > there will be two rather disjoint communities - the Sun- > dominated OSM/OSEE one and the non-Sun dominated OSCE. > If this is how it works out, what would motivate the OSCE > crowd to do the backport work, especially since it would > undoubtedly involve more work? Frankly, I don't see the opensolaris community doing backport work at all. Why would we? Backporting is for supported versions, where (presumably) support customers will pay for someone to do the boring backporting work. I guess I'm not seeing why this is a problem? -- Josh Berkus PostgreSQL Lead Sun Microsystems San Francisco 01-415-752-2500 _______________________________________________ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
