[companion-discuss] open code for fundamental libraries

[Jeremy Teo]

Hello Liane,

IMHO, there are no obvious issues with your points. The key difficulty
up to now is getting everyone to agree on a central repository.

The problem is social, not technical. If we could just all agree, and
get something rolling, that would be ideal. :)


On 5/3/06, lianep at eng.sun.com <lianep at eng.sun.com> wrote:
>
> Dennis, sorry for the delay in response (I was taking a hiatus from
> mailing lists for a bit).  I think this is an important discussion to have,
> and thank you for kicking it off.
>
> "Dennis Clarke" writes:
> >     I want to take the lead here and bring a topic to the table that needs to
> >   be focused and precise.  What I would like to discuss is how we may create
> >   a set of libraries that are open source.
>
> You also said in another thread:
>
> >   So the dream is still a common set of libs that are up to date and able
> > to be compiled and dropped ( repeatedly and consistently ) into some
> > LIBPATH somewhere on Solaris 8 and upwards.
>
> Cool.  I'm in complete agreement with your dream.  Indeed, I consider this
> to be a fundamental area of potential collaboration.
>
> Generally, one of the biggest points of contention seems to be about the
> environment at compile time: i.e. built on S8 versus built on Nevada.
> If we could all share one source base and allow different distributions
> (where I count Blastwave, Sun, and many others as distribution owners) to
> compile according to their requirements, we'd be in great shape.  Then
> we don't need to argue about who builds on what release.  It's up to the
> individual typing make. :)
>
> Sharing a source repository that we could all build according to our
> own whims would give everyone the biggest value for a contributor's
> time, as we could all share the work that a contributor did to get a
> piece of OSS building.
>
> To that end, here's the list of requirements that I've come up with
> for such a source repository.  Note that there's nothing in the
> requirement set that would restrict the proposal to libraries at this
> point.  It's not organized in any particular order, so apologies for
> lack of obvious flow or duplication.
>
>   - All source in the tree must work together.  If updating a component
>     that other parts of the tree depend on, should test the dependents
>     before integrating the update.
>
>   - Individual components in the tree must be individually buildable
>     for distributions who want to cherry pick components and for ease
>     of development for contributors.  Restrictions on build environment
>     (e.g. must have current tree installed at a well-known location) are
>     acceptable.
>
>   - Must build SystemV packages.  We could/should talk about how to enhance
>     the structure to allow component or distribution owners to
>     contribute support for other package types (e.g. SPS, etc.), but
>     components must at least support a SystemV package build
>     environment.
>
>   - Must support components which are targettable during build time
>     to a specific release.  That is, should be able to specify that
>     gnome libraries are built and linked against *only* on on old
>     releases which don't deliver them via a separate consolidation.
>
>     Put a different way, components shouldn't be duplicated for a
>     single release branch among multiple consolidations.  But, that
>     doesn't mean that can't be included in the source repository.
>
>     (What build environment is required for initial integration may
>      be up for debate at a later point.)
>
>   - Components built on multiple releases should be able to take advantage
>     of better/newer/more performant features through build time choices.
>
>   - Source code of component must be included in the tree.  No binary
>     objects, as they're unauditable.
>
>   - Divergence from the main trunk of the OSS component is strongly
>     discouraged.  Component owners are encouraged to establish a
>     relationship with the upstream component providers and contribute
>     back OpenSolaris portability changes directly.  Where divergence
>     is required because the upstream component can't/won't take the
>     changes back, the differences must be easily auditable.
>
>   - Install location for the built packages should be settable at build
>     time.
>
>   - For OpenSolaris releases that support Zones, packages should work
>     in Zones.
>
>   - Contributions must be reviewed.  (The mechanics of this should be
>     debated at a later point.)
>
>   - Build environment requirements must be clearly documented so that
>     builds are 100% repeatable.  (Different releases may have different
>     build environments, obviously.)
>
>   - Only Open Source Software may be included.
>
> So, what points do people disagree with?  Which ones need clarification
> (I know my writeups suck on a number of them)? What points would be
> missing in order to offer a solution that could easily be built on by
> people who want to offer binary packages?  Is the entire idea crazy and
> unworkable (if so why)?
>
> (I haven't run these ideas past anyone else at Sun, so please don't
> take my proposal as anything except for a set of discussion points by
> an individual engineer.  I don't speak for anyone except myself in this
> mail.)
>
> liane
> --
> Liane Praza, Solaris Kernel Development
> liane.praza at sun.com - http://blogs.sun.com/lianep
>
>
> _______________________________________________
> companion-discuss mailing list
> companion-discuss at opensolaris.org
> http://opensolaris.org/mailman/listinfo/companion-discuss
>


--
Regards,
Jeremy