Darren Reed wrote:
> To approach this problem from a different angle, what is the
> architecture that matters when something like wireshark is
> integrated?
It all depends on what you mean when you say "integrated".
For the vast majority of things out there, it makes no sense
at all to integrate them into the OpenSolaris source tree.
They /are/ /not/ OpenSolaris. They are add-ons.
This does not mean that they should not be written to work
well on OpenSolaris, or that they shouldn't use the various
features found in OpenSolaris, or that others might not wish
to build on it to make better things, or even that "we"
shouldn't play a role in compiling, packaging and delivering
them.
Just, that in the hand waving cloud and arrows picture of the
system, they do not belong in the cloud marked "OS core".
>
> If I download and use wireshark today, I typically neither care
> about what is or isn't in the package (just give me the GUI, damnit!)
> nor about the rights profile. And for a good number of people,
> I'm going to assume the same is true. But there are people for
My point exactly.
> whom these things do matter. Question is, was the effort involved
> in approving wireshark worthwhile and what would have been acceptable?
It depends on what you want to do with wireshark.
If all you wanted was an add-on wireshark, then no, we wasted
everyone's time.
If you wanted a replacement for snoop and the other core OpenSolaris
network diagnostic tools, then yes, and we probably didn't go far
enough.
If you don't know what you wanted, or if you wanted both, but for the
cheaper price of the first, then you probably were disappointed :-)
> I imagine that what wireshark and many other things want to say is:
> - here is a list of binaries and libraries i want to install
> - i will be linking against these other libraries
> - this is where they're going
> - some man pages are being included
> - they will be in packaged up as XYZ
This is the "simply record the footprint" concept.
> For the sake of this email, let Indiana be a release of OpenSolaris
> that accepts "no" as an answer to all of the above and let Solaris
> be a release of OpenSolaris that requires "yes" to an answer to all
> of the above.
I don't believe we can do that and maintain our sanity.
Where would you put those "no" things? There *is* no Indiana
consolidation or gate, so today they are going into ON, SFW, JDS
and other "Solaris" gates.
> If we're going to allow different distro's then we need to:
> - allow different distros to require different levels of integration
> - let the project team decide which distro(s) they want to be in
Given the organizational structure we have today (CGs, Ps on OS.o,
C-Teams, P-Teams and PACs in Sun), we have no way of actually
doing that level of discrimination - not to mention the astronomical
resource cost of having each and every project team manage N+1 distro
integrations.
> If the target distribution is Solaris
Maybe the real answer here is that there isn't a Solaris target any
more, that Indiana *is* the only release, that Nevada really *is*
a Major release targeted consolidation, and we all are making a
false distinction between Indiana and Solaris. Maybe the world has
changed drastically and we are the ones who are behind the times.
> What we know and do today fits the "Integrated" expectation that you've
> used but there is a large spectrum below that, much larger than the 3
> levels you've proposed.
What benefit is there here (in ARC-land) to having more than 3 buckets?
Review-level = high
Review-level = low
Review-level = none
Fine tuning how thatlast level works is really outside of the scope
of the ARCs - by definition :-)
-John
