[Sorry for the length. Executive Summary:
There are several things that a project needs to be able to articulate
to themselves, their CG and to the ARC:
What do you intend to do (problem statement, scope),
How will it impact existing promises and expectations (what does it change),
What new expectations does it set (interfaces & their stability), and
How will we/you know when you are done (goals)?
In this case, I think that it might be good for the Packaging and Install CG
core contribs to weigh in on where in the packaging system evaluation process
they are, including what decisions (if any) they have made in this area.
-John]
Brian Gupta wrote:
> My understanding is that ARC is the forum for guidance, as well as
> informing the community of intended projects.
You asked for advice as to what the ARC would look for; my response was
an answer to your question, not a prerequisite of stuff to be done before
you could start interacting with the ARC. Consider it a serious place to
start preparing now for the architectural commitment review at the end of
your ARC interactions; if /you/ don't have good, focused answers to these
types of scope and intent questions, how can you expect the /ARC/ to be
able to even start to understand the potential impact of your project?
ARC review is, at its simplest, simply a review of your problem statement
and project charter:
What do you intend to do (problem statement, scope),
How will it impact existing promises and expectations (what does it change),
What new expectations does it set (interfaces & their stability), and
How will we/you know when you are done (goals)?
I'll try to elaborate inline below.
> 1) Why are we doing this?
> ...
> We as a community must however understand what we wish to accomplish.
Bingo. This is the exact question the ARC expects every project to answer:
"What do we (the community) wish to accomplish?"
> 2) What is the intended usage scope?
[lots of 'it could' and 'it can' deleted...]
The ARC is less interested in potentials than in understanding specifics.
What specifically do you intend to have /this/ project do - as opposed to
future followon efforts? Possible answers that come to mind might be
A) We want to port conary to Solaris, package it in systemV pkgs,
and deliver the bits into the SFW consolidation.
B) As in A, plus use it to build and maintain some set of stuff in
a conary repository (sortof like pkg-get's relationship to
blastwave)
C) As in B, but targeting the OpenSolaris ON consolidation as
a specific example
D) ...
I don't think "A" would be controversial at all, while "C" could end up
requiring a lot more effort on the part of a lot of people. Without
knowing the scope of what you have in mind, it is like asking me
what you should cook for dinner, without telling me whether you are
thinking of a romantic evening for two, or a big party bash for the
entire NYC OSUG :-)
[ceder plank salmon fillets on the grill over a bed of basmati rice,
steamed asparagus tips with Hollandaise, a big California Cab or medium
Pinot, finishing with bread pudding for desert for the one; grilled BBQ
pork ribs and bulk Costco potato salad with lots of beer for the other :-) ]
> 3) Does it actually work for the use cases and scope called out
> above?
> What sort of proof do you need?
I'm not asking for the proof *now*; I'm asking you to scope your proposal,
and then - as part of the ARC review and community acceptance effort - show
that your project can indeed do what you claim it will be able to do.
As above, "A" is a trivial exercise - it compiled, it runs, it is able
to deploy & load an example application, QED. On the other hand, if your
scope is to convert ON to a new build system, the community will probably
require you to prove (thru a pilot exercise, perhaps) that it is in fact
possible to host, deploy and install something as complex as ON in conary.
> Agreed. How should any prospective packaging system handle legacy SVr4
> packages?
It is up to each individual project to say how their architecture will support
them. SysV pkgs have their own metadata, dependencies, install and uninstall
contexts, rules and expectations, all of which will be "different" from the
norms of the packaging system being reviewed. The easy part is saying "it
should handle it", the hard part is architecting a system where it and all
its corner cases *actually* work (think zones, jumpstart, xVM...).
I would expect this to be the hardest part of evaluating *any* alternative
packaging system...
> You say "not might or could but does", yet at the same time
> you say to "ARC, early and often".
By ARC Commitment time, you need to have these answers; now at the
beginning, I am simply asking you to start thinking about them. This
is part of the "early"; your response becomes part of the "often" :-)
> 5) What is the relationship between this project and the others being
> done in the install/packaging CG? This sounds like a design choice;
> what has the CG itself said about it? ... have you asked?
>
>
> I was told by Stephen Hahn that Conary had been evaluated for use but
The sparse mail log shows a slightly different perspective; it also seems
to show that all the conary evaluation has happened behind your own closed
doors. In some sense, it doesn't matter; the community rules are clear
that design decisions like conary -vs- IPS need to be made at the CG level
with some sort of formal vote among core contributers. [TIME FOR THE
P&I CG TO CHIME IN...]
IMO, it seems that the result of an "evaluate foo" project is simply
an evaluation that leads to discussion at the CG level, especially
as it pertains to other "evaluate bar" efforts also being done. It
also seems to me to be scope-creep in the extreme to jump from an
"evaluate" charter to an "endorse me first" one without some
indication that that community that chartered you is in agreement.
(Please define ABICT)
As Best I Can Tell, Google doesn't always have all the answers :-)
> Finally this request
You are right - your ARC request wasn't a diss, but the other email from
Martin and you on the topic of the distro community and conary on ogb-discuss
that same day came across that way. I apologize for painting both discussions
with the same brush.
> Hopefully, as a
> result of this the OpenSolaris community will be able to come to a comon
> set of requirements that any packaging system must meet.
I would expect the install and packaging CG to come up with those
requirements, and to pass them on to the ARC community in the form
of policies, best practices and endorsed projects. As a project
lead in the install & packaging CG, I would hope that you are one
of those helping drive consensus in that community.
> As I am aware there are no other proposals before the ARC for guidance
> in creating or adopting an OpenSolaris packaging system. Please
That is somewhat immaterial - the packaging and install CG is known
to be in the process of evaluating and developing packaging and
repository tools such as conary, ips and others.
This is why I asked whether or not your project's sponsoring CG had
discussed your evaluation of conary and if they had been asked to make
(or had in fact made) a design decision about a packaging system.
I looked at the mail archives and could find no indication that such a
design discussion had in fact been had recently for conary, but I could
have missed it. (Don't worry, I am also beating up Stephen, David, Danek
and the rest on a regular basis for not having "walked the ARC walk" for
IPS, repositories and the rest of the Indiana effort; to their (and your)
defense, architecture review usually happens only after enough prototyping
has been done so that the project leads have a good clue as to what their
architecture /should/ be...)
In the same way as when two LSI drivers popped up before the holidays,
when the ARC is aware of multiple overlapping efforts in a single
architectural area, it usually asks all the parties to coordinate
and cooperate to develop an architecture that works for both, since
having two overlapping somethings without any rhyme or reason between
them tends to spell confusion and chaos for users. In this case, since
there is a CG that is sponsoring all the various packaging projects, it
is reasonable to ask that you engage there as well as here.
> We are currently working with the IPS folks to try and understand their
> design criteria behind IPS now.
This is great news.
As Bill F has just said over on ogb-discuss, Sun has a strong interest in
forming an ecosystem of compatible software package and services. This
implies that, while it may be desirable to /evaluate/ many packaging options,
we all are best served by choosing one and focusing our efforts on making it
a robust and successful infrastructure piece. The desired end result isn't
having several competing packaging systems to distract everyone, but in
building a vibrant ecosystem around things that *presume the use* of a
common packaging system. Anything else IMO simply sets us up for death by
a thousand different package formats, which is almost as bad the fabled
Linux Distro Hell we are also trying to avoid :-)
> One observation right now, is that
> many of the requirements for IPS seem to be very SMI-centric, and as
> external community members, we can not always fully relate.
Any "new" packaging system will need to be able to handle "SMI legacy"
needs; however, the probability that any of those legacy needs will rate
high on external developers checklists may be vanishingly low :-)
-John
