On 06/ 8/10 01:50 PM, Suhasini Peddada wrote:
Hi James,
On 06/08/10 10:35 AM, James Carlson wrote:
I'm not opposed to the project, but I do think it'd be much simpler if
we had a higher-level (say, "architectural") review of the delivery
mechanisms themselves.
In reviewing the Brownian motion of little open source packages from one
repository to another, I think we're really missing the big picture of
what the repository inclusion rules are, what things depend on what
other things, and ultimately what bits constitute "the system." With
that part sorted out, I suspect that we won't need any of these
confusing 's/SFW/contrib/' project reviews, because the answers become
quite obvious self-reviews (with zero paperwork). Without the big
picture, we're down to repeating the same discussion over and over, and
producing uneven results when some things fall through without
substantial review and others get nit-picked.
We went through this trouble once before, back when we larded up SFW
with random bits. And when (not "if" but "when") there's another
realignment of repositories, we'll have another flurry of confusing and
disjoint little projects that really have very little architectural
content in themselves.
Are you suggesting that we should make it as a project review?
Having an umbrella case that covers the overall architectural issues
associated with the entire SFW cleanup effort is something that I
suggested to this team back in April:
http://mail.opensolaris.org/pipermail/opensolaris-arc/2010-April/021083.html
The umbrella case review would be a full review (in a meeting), and that
would, hopefully, clear the air for the underlying individual cases such
as this one (fast-track or self-review).
Is there any reason that all of these "FOSS" projects need to be done
piecemeal?
The only reason I can think of is that not all the pieces involved are
owned by one project team member.
I don't believe that the composition of the project team nor the
schedule of the integrations for these removals is a factor here. There
are architectural issues associated with the greater goal associated
with these individual projects, and we're not utilizing our time
effectively by rehashing these same issues repeatedly. Things like:
* Why is /contrib relevant at all to these cases (it's not part of the
system's architecture at this moment...)?
* Is there a greater goal to integrate /contrib somehow with the system
that is relevant to this overall project?
* What are the key common criteria for removing things from SFW as part
of this greater effort? Let's establish those once and not discuss it
again.
-Seb
_______________________________________________
opensolaris-arc mailing list
[email protected]
