John Plocher wrote: > [I've updated http://www.genunix.org/wiki/index.php/ExpectationTaxonomy] > > Stephen Hahn wrote: >> * John Plocher <John.Plocher at Sun.COM> [2008-04-16 04:30]: >>> Wiki: >>> >>> http://www.genunix.org/wiki/index.php/ExpectationTaxonomy >> >> I don't actually agree that expectation is the architectural axis we >> should be pursuing. I'm much more concerned with people building on > > There may well be other axis that are important as well. While I'm > not addressing them, you certainly can :-)
Having looked at the genunix webpage to see what you're defining, I agree with Stephen. To approach this problem from a different angle, what is the architecture that matters when something like wireshark is integrated? As originally submitted, it wanted to be completely self contained, only exporting the application itself. It ended up being derailed because of the lack of a rights profile and packaging (make the GUI separate.) Somewhere in the vicinity of 80 emails to arrive at that point. And we still haven't solved world hunger. 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 whom these things do matter. Question is, was the effort involved in approving wireshark worthwhile and what would have been acceptable? 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 In addition, what we need to enable them to say is: - yes/no on cooperation with smf - yes/no on auditing - yes/no on rights profile - yes/no on localisation - yes/no on FMA - yes/no on Sun support/bug fixing ...and whatever other special things solaris has... 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. 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 But that presupposes that people install from a fixed sense of a distro - a DVD or other media that contains all of the qualifying material. If a project wants to only target Indiana and the requirements of Indiana are lower than those for Solaris, why does the project team need to deliver for Solaris in project review? Maybe this is one of the new axis we need: target distribution If the target distribution is Solaris then we know how to review those projects but if the target is Indiana, well, is the review criteria the same? Is PSARC review even marginally appropriate? How does someone integrate into OpenSolaris to target Indiana but not Solaris? (Lets ignore the post-ARC problems, such as where the package is stored, built, committed to, etc, and focus squarely on what should or should not happen with ARC review.) I'll even venture to say that we need a completely different process to the fasttrack process for things like wireshark that consist of a web page that asks a bunch of questions (such as the above), records the data somewhere and gives you an approval number or something. Or maybe its even simpler- you run a program of some sort, giving it a list of deliverables and it works the rest out. If there are library linkages between the project and some other project, dependency is identified and the connection made. Or maybe that model doesn't get used at all. Maybe we should just allow a project to declare its architecture in a file (that is inside the package) and have software look at that to decide if the answers declared therein match what the distro/install wants? If we adopt that model, what role does the ARC play, if any? If I install JPix and I say I'll accept any type of package, if I then go and grab bash from Stephen's repository, shouldn't the question of whether or not it gets installed (because it matches up with JPix's package requirements) be made then and not in some ARC review? Or to put it a different way, maybe PSARC needs to have a PSARC text form that is included in files that makes statements about what the package claims to conform to (or not to.) It then is up to a repository to decide whether or not to include packages based on what answers are in the PSARC file. No review is required, the trust is laced in the producer of the package to correctly answer the questions. This might actually scale as it doesn't require any ARC to review 19000 packages. And is there any reason that this model couldn't be applied to ON and OpenSolaris and Solaris today? Another important point is that we need to focus on making it easy for the project team to deliver what it is they need to deliver, not to do other things, even if they seem related (like the question about removing snoop in the wireshark case.) While it might be an appropriate question to put to someone integrating a new packet sniffing program that is developed at Sun, we can't ask every project that wants to integrate a program that does X, and we have something that also does X, to investigate whether the something that already does X should be removed. So what if we end up with 10 different programs that all do X; the number "10" is beside the point and we're missing the reality: that people obviously want to be able to do X in 10 different ways. I know I've digressed but this seems important as something that PSARC must get over. I think the important message I've tried to convey here is that ARCs need to consider giving projects more autonomy about what level of compliance they meet and to let distributions or consolidations or installers decide what level of compliance they accept from the packages that they then use. And at perhaps an extreme level, PSARC stops reviewing packages for eligability: everything is self review where we are not the OEM and are not doing any maintainance. 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. That said, we need to work out what all of the important parts of that spectrum are and I believe documents such as the 20 questions will be a part of determining that. Darren p.s. sorry for picking on wireshark, it just seemed like a good poster-child.
