On Thu, 2002-10-31 at 12:16, Stephen McConnell wrote:
> I read through your email and to be frank, I felt somewhat angry and sad
> all at the same time. I felt sad because what your wrote about is the
> "playground syndrome" that is so prevalent in Avalon. What I felt angry
> about is that it's not a passive syndrome, its an active syndrome.
that's the "negative POV". I think _formal_ separation of voting and
commit priviledges is neither doable, nor desirable. It'd create
bureacracy, as the other Leo said :)
While I'm not sure I agree it is a good idea to informally/morally
seperate the two, I do think most of the avalon community looks at it
that way.
I also think this is not the same as the "playground syndrome". I also
don't think you should be calling it a "syndrome". A level of
playgrounding/sandboxing is healthy.
> What happened was that I was that I was assigned my own playground -
> avalon-apps/enterprise - lots of freedom to do what I wanted and no
> constraints. But what I wanted was to get involved in a real process
> about delivering real components that would deliver real value to Avalon
> "the Community". That never happened. When I joined up as a committer
> the last thing I wanted was to be shuffled of to a playground.
Now here's a problem. Why did you feel "shuffled off" to a private
little playground? Where exactly did that happen? (perhaps pointing to
mail archives would help) It was never our intend to shuffle you off.
I think that avalon isn't about private playgrounds at all. I think that
the goal is to find a lot of common ground (ie avalon framework), and
have a way to exchange thoughts, discuss software architecture (this
list), and work on the 'ultimate container'.
Until we come up with the 'ultimate container' though, no solution will
always work and we will have multiple codebases.
> It's two years later and what is the impact outside of my delegated
> playground ... I've managed to push though the deprecation of the
> Component interface through the work on the service package (not a lot
> of code but a lot of effort to handle the volume of email at the time).
...and a lot of added value to avalon-framework. Finding more common
ground in there is extremely tough. The fact we scrutinize every tidbit
of that package makes it so valuable!
> I've also contributed to
> Avalon the Merlin story - something positioned somewhere between ECM and
> Phoenix. I look at this work as achieving two objectives - an expression
> of interest from myself in where I would like to see Avalon going in the
> future, and secondly, and concrete attempt to resolve the
> technical/community divide in Avalon that is reflected by the
> ECM/Phoenix split.
I don't think there's that much of a community divide between ECM and
phoenix developers (we're all on this list, aren't we ;). However,
different people have different needs in their work so they work on
different codebases.
Looking at the enormous amount of effort we as a community are pooring
into crossing the technological gap (all the heated discussion and
flamefest of recent months is just that in the end) indicates to me we
are still a community. As I see merlin, it is also largely an effort to
cross the technological gap.
This is cool!
> Even today, with an order of magnitude increase in the market
> recognition of the value of component oriented programming, the hot
> press coming out of Avalon is the release of incompatible and divergent
> containers (Phoenix and Fortress).
If you think of a compatibility scale between containers, I'd say we are
converging.
Some time ago it was:
ECM Phoenix
<---------------------------------------------------------------------->
compare with:
ECM Fortress Merlin containerkit Phoenix
<---------------------------------------------------------------------->
(didn't fit in stuff like EOB or plexus because it's not
exactly easy)
Fortress takes concepts in phoenix and adds them to ECM. Merlin takes
concepts in ECM and phoenix (and also adds new ones). I think we will
eventually either end up with many containers on the scale, or a single
really cool one that fits everything (if that really is possible).
Either way, I think we're convergent on the technological scale.
> And yet, both address different
> concerns and could really incorporated in a single comprehensive
> solution. Why do these two different solutions exist?
because they address different use cases.
> Why is it that
> they have not merged already?
because that is hard to accomplish, because there is backwards
compatibility, because it takes a lot of effort. Hence, time.
> Why was Merlin even necessary?
because it takes less effort to make something new than it takes to
integrate two existing approaches.
Also because you had some fresh ideas that couldn't just be poured into
phoenix (it'd ment two more years of alpha state), or ECM.
> They exist
> because somewhere in the history of Avalon there was a fundamental split
> - Phoenix went down the direction of static component management, ECM
> went in the direction to dynamic component management - playground
> policies got their first foot in the door. And years later, their
> differences remain unresolved - and yet with only a few months work,
> Merlin 2 manages to bridge both abstractions. What's wrong with this
> story? The problem is the continuation, no! escalation of "playground
> principals" - principals that fly in the face of the needs and interests
> of our end-user.
merlin has contributed towards the convergence of the different
technical solutions. With a "few" more months work, we will hopefully
enter a state where we have converged completely.
> Take Cocoon as an example - Cocoon is on the brink of engaging in a
> process of block based development and moving towards this from an ECM
> legacy position. Where is the "Avalon Project" solution....
in the combination of all existing efforts and in the heads of its
developers.
> block no
> longer exist in Phoenix - Fortress has no notion of blocks or anything
> close to block assembly. Is there something we need to be addressing
> relative to our end user priorities?
the development of all existing containers really is driven by the needs
of users. It's just that different users have different needs, and none
of them aims to satisfy all.
> Why aren't sub/sub projects working
> together - because territories have been marked out - unspoken rules
> that imply territorial restrictions.
again, this is really the negative POV. Try and look from it the other
way around...
> Avalon is in my opinion the most important project in Apache.
err.......I think incubator is "the most important" :)
> But I
> believe that Avalon is only as strong as its community. For the
> community to work together it must abandon playground policies and
> really engage in addressing the difficult issue of bringing all of this
> work together. If the Avalon community cannot do this the Avalon the
> Community has nothing to offer. If the Community has nothing to offer
> that Avalon has nothing to offer its users.
Steve, I hear your frustration! You and many other committers have been
doing hard work in bringing things closer together. The fact we're not
there yet doesn't mean the work is for nothing. The fact the debate got
personal (which everyone regrets) doesn't mean the community as a whole
doesn't have the same goal.
I also think playgrounds are cool. The innovations you put in merlin
couldn't have been put into phoenix and still get a release (I'm sooo
happy we have a release! ;), but allowing merlin into the playground has
sparked useful debate and has given many people useful thoughts. If we
we're to dissallow playgrounds that'd never happened!
> This community *must* be totally committed to its core and its own
> integrity.
nah. I think allowing a little bit of side effort is nice. The fact that
apache as a whole is now changing to allow sandboxing, and set up for
cross-pollination, etc, means avalon as a product won't have to anymore.
But the community can be about diversity.
> Any suggestion of the departmentalizing/separation of voting
> and commit privileges is simply reinforcing a cancer that will only lead
> to further fragmentation of interests.
hmm. I don't like associating cancer with avalon or our community at
all. Bit harsh, isn't it?
> Avalon will only evolve if its
> community evolves.
Avalon "the product" will enjoy having a clearer scope and focus. This
is now possible without giving up all the really cool parts of avalon
"the community" (like providing the sandbox, the incubation, the mailing
lists), because apache (and I mean the community) as a whole is changing
to support that.
This is a cool opportunity!
> From this perspective I'm very strongly in support of Avalon "the
> community" taking up the challenge and leveraging the opportunities for
> real evolution offered by escalation to a top-level project.
A top-level project should be about a product. A community can be built
around a product, or around multiple products (like the avalon
community).
A community, however, is not intended to be a top-level project. This is
what was done with Jakarta, and apache is not happy with that. Hence,
the avalon community should focus on separating its products and work to
make those into top-level projects.
more thoughts on that later....
cheers,
Leo
--
To unsubscribe, e-mail: <mailto:avalon-dev-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@;jakarta.apache.org>
