avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leo Simons <leosim...@apache.org>
Subject Re: [PMC:VOTE] release process for cocoon deps
Date Fri, 20 Feb 2004 11:37:39 GMT
Stephen McConnell wrote:
> Don't be preoccupied with the idea of having everyone on board - you won't. 

At the core of the ASF development process is the idea of having 
everyone on board. It's called consensus-based development. I might be 
inclined to say that preoccupation with the idea of having everyone on 
board is a requirement for doing anything here at the ASF.

 > Yes - I have some issues.

so fix them. Or don't fix them. But don't put the burden of fixing them 
on others and make their life hard.

> it would probably help me if I had more information 
> about the real Cocoon/Avalon dependencies

Re: gump.

http://lsd.student.utwente.nl/gump/cocoon-2.1/cocoon_details.html#Project+Dependencies

use any IDE to search the cocoon codebase for "org.apache.avalon" and 
org.apache.excalibur" imports for more detailed information.

 > I also think there are some
> improvements that should be undertaken before a release.

another thing at the core of the ASF development process is the idea of 
meritocracy. You should not talk about "SHOULD" if you will not be a 
part of it. Make that a "COULD".

Example: I think that merlin SHOULD be built successfully using gump, 
but that has nothing to do with releasing it or not. So we COULD do that 
for the next release, but if it doesn't happen, let's not complain about 
that, shall we?

> excalibur-component
> 
> Do any of the changes impact Fortress?

no. These are seperate codebases.

> excalibur-store
> 
>    This component is a small persistence utility. It provides
>    a memory store, a file store, and a store based on JISP
>    2.5.1 (license details concerning 2.5.1 are not clear but
>    JISP 3.0 is GPL).

2.5.1 has a compatible license:

http://cvs.apache.org/viewcvs.cgi/*checkout*/avalon-sandbox/excalibur-old-materials/store/lib/Attic/jisp.LICENSE.txt?content-type=text%2Fplain&rev=1.1

>    Aside from the javadoc there is no
>    supporting documentation and IMO would benefit a lot from
>    some simple usage docs.

so scratch your itch.

>  There is some work to be done to
>    bring a few classes in line with @avalon tag spec

so scratch your itch. The value of the @avalon tag spec for cocoon atm 
is zero since the container(s) they use don't support it.

> excalibur-sourceresolve
> 
>    This component is pure ECM specific.

nope. It is quite generic. It is a generic source resolver.

> [the documentation] is insufficient for someone to actually jump in
>    and use the product in anything other then a ECM specific
>    scenario.

there are people who have jumped in and done just that. And even you 
were correct, I don't think this is a big issue.

> excalibur-xmlutil
> 
>    In its current
>    form the package is dependent on excalibur-store, sourceresolver
>    (and by implication ECM/Fortress).

nope. Parts of the library are usable seperate from any of those.

> moved to avalon/util

please, no more moves! AAARGH!! :D

>    and the remaining
>    ECM specific content managed as a ECM specific resource (possibly
>    bundled with Fortress).

it is not ecm-specific. Nor is it fortress-specific. Materials that are 
shareable between ecm and fortress should be released independently of 
those two, because fortress and ecm are codewise unrelated to one another.

> fortress-container and fortress-tools
> 
>    Primary issues to be addressed before a release is to get the
>    basic @avalon tag support in place.

disagree. There is no support for that now, if a new release fixes or 
improves other areas, the release makes sense. You're saying something like

    "The primary issue to address before a merlin release is to get
     support for the ServiceSelector semantics in place"

(ie it makes as little sense and is similarly unreasonable)

everyone is welcome to implement functionality like that, in merlin, and 
in fortress. But if no-one does, that doesn't mean we should just halt 
the development of other functionality.

> Currently both the maven and ant based builds for all of the above 
> products are broken - some housekeeping to be done here to get 
> respective packages in order before the subject of content release is 
> pertinent.

of course.

-- 
cheers,

- Leo Simons

-----------------------------------------------------------------------
Weblog              -- http://leosimons.com/
IoC Component Glue  -- http://jicarilla.org/
Articles & Opinions -- http://articles.leosimons.com/
-----------------------------------------------------------------------
"We started off trying to set up a small anarchist community, but
  people wouldn't obey the rules."
                                                         -- Alan Bennett



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org


Mime
View raw message