Sebastien Roy wrote:
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.
Its just an hg update of a clone if the clone sits alongside. hg merge
on the other hand, pollutes the revision history, and is something I'd
like to avoid.
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).
Not sure how large the number will be. Many of these interfaces are
reasonably unchanging.
My intention here would be to do regular builds (biweekly binaries),
doing pulls of numbered ON binaries. That's what I meant by
build-for-build equivalence.
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.
Okay, that sounds somewhat like wordsmithing to me, but whatever.
- Garrett
_______________________________________________
opensolaris-code mailing list
opensolaris-code@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
