On Fri, 16 Mar 2001 [EMAIL PROTECTED] wrote:
> On Fri, 16 Mar 2001, Morgan Delagrange wrote:
>
> > 1) Costin, Ignacio, etc. are concerned that the
> > Commons committers will incorrectly shoot down
> > legitimate components.
>
> No, the concern is that the "commons" will "aprove"
> or vote on decisions made by jakarta projects.
>
It seems to me that this concern is not justified based on the proposal as
currently documented (prop02.html). The only things that the Commons
committers vote on are (numbers in parentheses are points in the
guidelines):
* "General oversight" (16).
* "Accept new packages" (17).
Where does the set of commons committers as a whole, have anything to do
with technical direction, release versus not-release, or anything else
that is concerning you?
The only grey area I can see is what "general oversight" means. I
understood that to be concerned with initial acceptance criteria (is the
component really reusable, or does it drag along dependencies that hinder
this? does, or will, the component conform to the packaging
guidelines? does the component have an initial set of committers willing
to support it?).
These decisions have nothing to do with technical direction, whether the
component is ever actually "released" as a package, or anything else you
have been expressing concern over, as far as I can tell.
> And the other concern is that the code developed by
> jakarta projects in the shared workspace is treated
> in the same way as experimental code that
> is not supported by any jakarta entity.
>
Depends on which workspace we're talking about. I objected to code in the
"sandbox" (i.e. playground/experimental area), which is not visible to the
public, being included in released products (and you agreed with this
point, if I remember right). Before it's part of a product, I don't have
any problem with "experimental" or "unsupported" code being here -- it's
just a whiteboard for people to work on things that *might* turn out to be
generally useful.
For released components, or code used in a different subproject release,
it seems to me that you can have Agora-style development using the Commons
workspace as proposed. Which specific parts of the proposal lead you to
believe that this is not the case?
>
> > 2) Craig, David, Gier, etc. believe that we need
> > oversight, or subprojects may introduce components
> > that don't meet the Commons charter.
>
> I do believe we need oversight - but not commons
> oversight over code aproved and supported by projects.
> And the "commons" charter is to provide support
> for projects and facilitate development of common components,
> not to supervise the component developed in projects
> ( it's the PMC who can do that ).
>
If I believe that my component (currently part of my favorite
subproject) is potentially reusable, and others agree, I'm going to
propose it for Commons. Assuming acceptance -- and that's mostly
concerned with things like not dragging along dependencies on frameworks
that hinder reusability -- I, and the other committers who want to share
this component, will be the maintainers of record in the status file
(point 15).
Now, I can use that code in my subproject in (at least) two ways:
* Create "releases" of the component, and treat it
just like any other external dependency (i.e. like
the fact that I might need an XML parser and download
a particular version of Xerces).
* Tag the component classes that I need with my subproject's
version number, and assemble it as an integral part of my
subproject build (essentially the same as any source file
inside my subproject repository).
If this is all according to the rules of Commons, where does it say,
specifically, that you cannot have the development style you like? Or,
where does it *not* say something that would prevent the kind of
interference you are worried about?
>
> Costin
>
Craig
