On Thu, 2009-10-29 at 07:17 -0700, Garrett D'Amore wrote: > Sebastien Roy wrote: > > On Thu, 2009-10-29 at 06:54 -0700, Garrett D'Amore wrote: > > > >> Edward Shu wrote: > >> > >>> +1. I would like the package for the "community supported hardware" > >>> will be self contained. That is, > >>> ON tree is not necessary to build the package. > >>> > >> It would be nice, but we'll need the ON headers at least, I think. > >> > > > > Logistically speaking, to make this work at all, I would think that your > > repository would need to be a child of a snapshot of the ON gate. This > > very much seems to me to be a project (rather than a consolidation) that > > perpetually synchronizes with ON by regularly pulling and merging from > > some snapshot of the ON gate (just like any other ON-based project). > > > > Copying a collection of header files from the ON gate seems like a poor > > man's way of simply doing development in a snapshot of ON itself. > > > > I don't think a child will be as easy to work with, if only because I'll > constantly be doing merges.
This seems like a fallacy. You only need to merge when you decide that you want to base your software on a newer snapshot, much like you'd need to do the same "merging" if you were to grab new versions of the random collection of header files you mention above. > I'm thinking this will be more like other > consolidations handle interconsolidation dependencies.... they keep a > local clone of the ON (or whatever their dependency is) around and build > against that. But you're dependent on using a large number of ON consolidation private interfaces. The only sane way to do development using such interfaces is to develop within ON. In addition to that, the resulting code won't be guaranteed to work on any version of the OS other than a specific build from which the "header files" came from (i.e. ON snapshot). > Being a child would make more sense if we thought at some point we were > going to integrate this stuff upstream, or wanted to use the rest of the > ON build infrastructure. Neither of these are the case -- we have no > plans to directly merge with ON, and we certainly do not want to use > ON's byzantine build architecture. > > As I said, I have experience doing this kind of thing before. Its > really not bad. I'm merely providing my input. In the end, if you're leading this project, then it's your decision. FWIW, I don't believe that the term "consolidation" applies at all here, as consolidation applies that it's one of the pieces of the WOS, the collection of consolidations that comprises the Solaris product that Sun provides. This, to me, is simply a proposal to create a software repository managed by an OpenSolaris project. -Seb _______________________________________________ opensolaris-code mailing list opensolaris-code@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
