You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Leo Simons <le...@apache.org> on 2002/10/31 00:13:09 UTC
separation of voting and commit priviledges
All,
following an interesting conversation between PD & Nicola on
general@commons (somewhere in messages 100-200) and also other threads
regarding voting on that list, I figured it might be a good idea to say
some things right here about the moral separation of voting and commit
priviledges @ avalon.
Avalon is a big project where not everyone knows all of the codebase or
works on it (sure as hell I don't know all of it :). Yet every avalon
committer has full access to all the cvs modules. This has many
advantages, like allowing everyone to do useful stuff like applying
patches, fixing language or adding docs.
However, informally, it is considered ill-practice here (I'd assume by
everone...) to participate in voting (other than lazy approval and/or
non-binding :) on pieces of code for which you are not a 'significant'
contributor/maintainer and for pieces of code for which you do not have
sufficient knowledge to make an informed decision.
Of course, 'significant' is something not so easily defined or perhaps
agreed upon when you have as informal a setup as we do (which might be
part of the problem behind our recent flamefests and yet one more reason
to eliminate scope creep and/or setup our own PMC - to be able to make
some things like this more formal); the 'informal' part also makes our
community work less transparantly (well, especially that this moral
guideline is also undocumented ;).
This is not to discourage anyone from participating in discussions where
they don't immediately see all sides of the story immediately or haven't
been involved with a piece of code before......on the contrary! That'd
be a disaster. I'm just voicing some more thoughts on voting behaviour
before heading to bed......if it all sounds silly just ignore me :)
weltrusten (g'night),
- Leo
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: separation of voting and commit priviledges
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Leo Simons [mailto:leosimons@apache.org]
>
> > Avalon is in my opinion the most important project in Apache.
>
> err.......I think incubator is "the most important" :)
Agreed. Finally, an end to the proliferation of
subsub(...)subprojects...
I must admit I never thought Jakarta would pull itself out of
*that* hole.
In addition, you pretty much sum up my view about dissent.
When it is in the open, at least we get what we deserve - nothing
more, nothing less.
(That said, I want *quality* dissent.)
/LS
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: separation of voting and commit priviledges
Posted by Leo Simons <le...@apache.org>.
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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: separation of voting and commit priviledges
Posted by Peter Donald <pe...@apache.org>.
On Thu, 31 Oct 2002 22:16, Stephen McConnell wrote:
> 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). And yet, both address different
> concerns and could really incorporated in a single comprehensive
> solution. Why do these two different solutions exist?
because they serve different needs.
> Why is it that they have not merged already?
I am sure most Avalon developers and users would love to see a unified
approach. Until recently there was no real solid idea about how to do it but
now that there is it is largely just a SMOP. There is (at least) three people
now who are currently developing the bits (and one other guy in my company
who is doing another part) to enable this. I am also working on integrating
their work into a new container. Given recent activity it will take a lot
longer to materialize than originally planned but it will get there and
Avalon will be better for it.
> 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.
Irony.
> Avalon is in my opinion the most important project in Apache. 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.
It is the way Avalon has worked since before I was a part of it. Personally I
have found value in the community and usually am happy and proud to be
associated with it. As far as I am aware, Cocoon does not regret their usage
of Avalon so I assume they have found value in Avalon. Other people/projects
have said much the same thing.
Personally I think Avalon has a lot to offer and it is only going to get
better in time.
With the metadata + interceptor + tools work that is currently underway I
think we will have a significant advance for Avalon - when thats done the sky
is the limit.
> This community *must* be totally committed to its core and its own
> integrity. 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.
Apaches governance system is loosly based on meritocracy. People earn the
privlidge to make decisions on codebases by putting in work to that codebase.
Interests are already fragmented and people work on what they want, when they
want. There is no *must* in opensource.
Some projects manage to achieve a global momentum but that can only occur when
there is consensus and direction. It may be possible to achieve this in
Avalon but it would be a lot of work - it was what was attempted to be done
with ContainerKit until it's continuing development went off list.
> Avalon will only evolve if its
> community evolves. That means that every single member of this community
> must be given the real and tangible potential to contribute his or her
> best in every aspect of Avalon's evolution.
Less talk, more action.
Communitys are based on trust and respect. People work together because they
seem some need or value in doing so. Part of this is that people must be
allowed an unffetted ability to experiment with different approaches and not
fear retribution.
For example, I have serious reservations about design decisions in
ECM/Fortress and Merlin1/2. I have pointed out these problems time but I have
never ever tried to block a change in any of these containers - regardless of
how stupid I thought it was.
People are always given the opportunity to make an impact. Their impact is
proportional to the amount of work and effort they are willing to put in for
the good of the whole project. More importantly it is about the ability to
work with other people to come to a solution.
> 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.
When we are ready we will do it. Scope and purpose are so ill defined at the
moment that there is no value in going to the top level (we would just be
another container project). When we have migrated logkit + most of excalibur
+ apps away (and possibly all their services ala cornerstone). Then we can
tighten our scope and move forward.
It is just going to take time. A willingness to move forward and help will get
it done faster.
--
Cheers,
Peter Donald
*------------------------------------------------------*
| "Common sense is the collection of prejudices |
| acquired by age 18. " -Albert Einstein |
*------------------------------------------------------*
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: separation of voting and commit priviledges
Posted by Leo Simons <le...@apache.org>.
On Fri, 2002-11-01 at 17:15, Paul Hammant wrote:
> Leo,
>
> > + Dissent *must* be allowed and even encouraged.
> > I much prefer those that have a grievance with the project
> > to step right up and say so, than to keep it to themselves.
> > If committer A want to say that Avalon is crap, fine, let
> > him. If he has a point we're good enough to learn from it,
> > if not, we're good enough to refute that statement.
> >
> Actually you are right. We should not be blocked on dissent.
>
> I'll stand by my assertion that the more we do it, the more lengthy it
> is, the more emotive the wordage, the more we shrink our community.
If someone is frustrated and emotional about things that happen or have
happened in a community and doesn't speak up about it, no-one will ever
know and there is no way to learn from (or even of!) mistakes the
community makes.
If things are not happy-go-merry, the community might shrink. But not
putting out in the open the way things are is worse in the end.
as an example: if the avalon developers have a grudge against each
other, that might impact a business decision by an IT manager (because
of perceived stability decrease etc etc), resulting in his company not
basing a project around avalon. But if the avalon developers have a
grudge against each other and the manager making that business decision
doesn't know about that, that's worse because you'll impact the success
of that project (manager gets fired, project killed, avalon
blacklisted....).
I think it is good to voice dissent. But we should all work to prevent
it from happening.
cheers,
Leo Simons
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: separation of voting and commit priviledges
Posted by Paul Hammant <Pa...@yahoo.com>.
Leo,
> + Dissent *must* be allowed and even encouraged.
> I much prefer those that have a grievance with the project
> to step right up and say so, than to keep it to themselves.
> If committer A want to say that Avalon is crap, fine, let
> him. If he has a point we're good enough to learn from it,
> if not, we're good enough to refute that statement.
>
>
Actually you are right. We should not be blocked on dissent.
I'll stand by my assertion that the more we do it, the more lengthy it
is, the more emotive the wordage, the more we shrink our community.
Regards,
- Paul
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: separation of voting and commit priviledges
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Paul Hammant [mailto:Paul_Hammant@yahoo.com]
>
> I'd like to state a new problem we may well disagree on. I am
> deliberately brief here:
>
> The more dissent we repeatedly post here, the more
> community mind share we lose (regular developers &
> committers). I'd really prefer more high-esteem, and
> less 'playground' comments.
>
Just to prove that world + dog has an opinion about all this,
I'm going to give you mine:
+ Voting and commit priviledges stay linked.
Separating them would just create the mother of all
bureaucracies.
+ Dissent *must* be allowed and even encouraged.
I much prefer those that have a grievance with the project
to step right up and say so, than to keep it to themselves.
If committer A want to say that Avalon is crap, fine, let
him. If he has a point we're good enough to learn from it,
if not, we're good enough to refute that statement.
/LS
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: separation of voting and commit priviledges
Posted by Paul Hammant <Pa...@yahoo.com>.
Stephen,
I have been lucky enough to be invited into the Avalon committer
community on a similar timescale to yourself. Since arriving I have
been honored to work amongst the excellent minds here. As I see it the
community focuses on the brilliance of Avalon-Framework and its
patterns. With that focus we are united. It is the goal that draws us
all together. Where the community has differing interests is that we
are maintaining multiple containers. Some like Phoenix & ECM have been
in development for multiple years and have been used in anger over a
similar timescale. Some like EOB are young and yet to be used by a
single organisation anywhere near a live situation!! All our containers
are different in goal, niche configuration and implementation. That is
fine by me. I focus on the A-F commonality and am not upset that my
Avalon buddies show little interest in EOB :-) I am unlikely to make
any money from EOB as I've targeted the magic price point of zero, but
then that characterises all of our containers (not withstanding the
ultra-secret efforts of the lurkers to this list).
Anyway, I am happy with this community. I am happy that we all have
good things to say about all of the containers even the one that we do
not work on. I am happy that we hold all Avaloners in high esteem, all
containers as worthy efforts. I'm happy that we agree that A-F is
Jakarta's most important project (though we know that non-Avaloners take
some convincing).
Where we differ dude, is on the assertion that the community needs to
evolve. I believe it essentially does not. We also differ on sub
projects <not> working together. I think there is plenty of synergy.
There are tens of excalibur libraries used by other excalibur projects
and avalon based containers.
I'd like to state a new problem we may well disagree on. I am
deliberately brief here:
The more dissent we repeatedly post here, the more community mind share
we lose (regular developers & committers). I'd really prefer more
high-esteem,
and less 'playground' comments.
Regards,
- Paul
PS - I'd also like to see more xdocs work, but as is typical with my
experience with xdocs, developers cannot be convinced to work on them
unless they are tied to their computers and make to listen to Janice
Joplin for 72 hours continuously.
>
>
> Hi Leo:
>
> 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.
>
> I got involved in Avalon about two years ago. After figuring out all
> of the Avalon stuff I got to point where the "Avalon Concept" was
> having a real impact on my own development and the development of the
> people I was working with. During that first year my primary
> contribution to the Avalon Community was helping other people
> understand Avalon and Phoenix. One year later was voted in as a
> committer, armed and ready to contribute to the Avalon project with
> some important components.
>
> 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. What I wanted was the opportunity to leverage a bunch of
> people I really respected. I wanted to leverage ideas, beliefs,
> opinions - and through this process, enhance and improve not only the
> content that I committed, but also I to pay-back the confidence that
> the Avalon project had placed in me when they voting me into this
> community.
>
> 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). It's something I really believe will enhance Avalon buy simply
> eliminating the Avalon lock-in (giving people more choice and more
> liberty gets more people engaged). I think this was an important
> contribution to the framework and a contribution reached through a
> solid engagement and participation of the community. 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. Two cultures - two
> communities, that only serve to weaken the real potential of Avalon as
> the complete component solution.
>
> 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). And yet, both address
> different concerns and could really incorporated in a single
> comprehensive solution. Why do these two different solutions exist?
> Why is it that they have not merged already? Why was Merlin even
> necessary? 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.
>
> 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.... 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? Why aren't sub/sub projects
> working together - because territories have been marked out - unspoken
> rules that imply territorial restrictions.
>
> Avalon is in my opinion the most important project in Apache. 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.
>
> This community *must* be totally committed to its core and its own
> integrity. 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. Avalon will only
> evolve if its community evolves. That means that every single member
> of this community must be given the real and tangible potential to
> contribute his or her best in every aspect of Avalon's evolution.
>
> 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.
>
> Cheers, Steve.
>
>
> Leo Simons wrote:
>
>> All,
>>
>> following an interesting conversation between PD & Nicola on
>> general@commons (somewhere in messages 100-200) and also other threads
>> regarding voting on that list, I figured it might be a good idea to say
>> some things right here about the moral separation of voting and commit
>> priviledges @ avalon.
>>
>> Avalon is a big project where not everyone knows all of the codebase or
>> works on it (sure as hell I don't know all of it :). Yet every avalon
>> committer has full access to all the cvs modules. This has many
>> advantages, like allowing everyone to do useful stuff like applying
>> patches, fixing language or adding docs.
>>
>> However, informally, it is considered ill-practice here (I'd assume by
>> everone...) to participate in voting (other than lazy approval and/or
>> non-binding :) on pieces of code for which you are not a 'significant'
>> contributor/maintainer and for pieces of code for which you do not have
>> sufficient knowledge to make an informed decision.
>>
>> Of course, 'significant' is something not so easily defined or perhaps
>> agreed upon when you have as informal a setup as we do (which might be
>> part of the problem behind our recent flamefests and yet one more reason
>> to eliminate scope creep and/or setup our own PMC - to be able to make
>> some things like this more formal); the 'informal' part also makes our
>> community work less transparantly (well, especially that this moral
>> guideline is also undocumented ;).
>>
>> This is not to discourage anyone from participating in discussions where
>> they don't immediately see all sides of the story immediately or haven't
>> been involved with a piece of code before......on the contrary! That'd
>> be a disaster. I'm just voicing some more thoughts on voting behaviour
>> before heading to bed......if it all sounds silly just ignore me :)
>>
>> weltrusten (g'night),
>>
>> - Leo
>>
>>
>>
>> --
>> To unsubscribe, e-mail:
>> <ma...@jakarta.apache.org>
>> For additional commands, e-mail:
>> <ma...@jakarta.apache.org>
>>
>>
>>
>>
>>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: separation of voting and commit priviledges
Posted by Paul Hammant <pa...@yahoo.com>.
Stephen, Leo,
My take is _entirely_ different. I'll reply more fully later, but I don't see that many problems
with the Avalon project and its community.
- Paul
__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: separation of voting and commit priviledges
Posted by Stephen McConnell <mc...@apache.org>.
Hi Leo:
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.
I got involved in Avalon about two years ago. After figuring out all of
the Avalon stuff I got to point where the "Avalon Concept" was having a
real impact on my own development and the development of the people I
was working with. During that first year my primary contribution to the
Avalon Community was helping other people understand Avalon and Phoenix.
One year later was voted in as a committer, armed and ready to
contribute to the Avalon project with some important components.
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. What I
wanted was the opportunity to leverage a bunch of people I really
respected. I wanted to leverage ideas, beliefs, opinions - and through
this process, enhance and improve not only the content that I committed,
but also I to pay-back the confidence that the Avalon project had placed
in me when they voting me into this community.
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).
It's something I really believe will enhance Avalon buy simply
eliminating the Avalon lock-in (giving people more choice and more
liberty gets more people engaged). I think this was an important
contribution to the framework and a contribution reached through a solid
engagement and participation of the community. 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. Two cultures - two communities, that only serve to
weaken the real potential of Avalon as the complete component solution.
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). And yet, both address different
concerns and could really incorporated in a single comprehensive
solution. Why do these two different solutions exist? Why is it that
they have not merged already? Why was Merlin even necessary? 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.
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.... 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? Why aren't sub/sub projects working
together - because territories have been marked out - unspoken rules
that imply territorial restrictions.
Avalon is in my opinion the most important project in Apache. 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.
This community *must* be totally committed to its core and its own
integrity. 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. Avalon will only evolve if its
community evolves. That means that every single member of this community
must be given the real and tangible potential to contribute his or her
best in every aspect of Avalon's evolution.
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.
Cheers, Steve.
Leo Simons wrote:
>All,
>
>following an interesting conversation between PD & Nicola on
>general@commons (somewhere in messages 100-200) and also other threads
>regarding voting on that list, I figured it might be a good idea to say
>some things right here about the moral separation of voting and commit
>priviledges @ avalon.
>
>Avalon is a big project where not everyone knows all of the codebase or
>works on it (sure as hell I don't know all of it :). Yet every avalon
>committer has full access to all the cvs modules. This has many
>advantages, like allowing everyone to do useful stuff like applying
>patches, fixing language or adding docs.
>
>However, informally, it is considered ill-practice here (I'd assume by
>everone...) to participate in voting (other than lazy approval and/or
>non-binding :) on pieces of code for which you are not a 'significant'
>contributor/maintainer and for pieces of code for which you do not have
>sufficient knowledge to make an informed decision.
>
>Of course, 'significant' is something not so easily defined or perhaps
>agreed upon when you have as informal a setup as we do (which might be
>part of the problem behind our recent flamefests and yet one more reason
>to eliminate scope creep and/or setup our own PMC - to be able to make
>some things like this more formal); the 'informal' part also makes our
>community work less transparantly (well, especially that this moral
>guideline is also undocumented ;).
>
>This is not to discourage anyone from participating in discussions where
>they don't immediately see all sides of the story immediately or haven't
>been involved with a piece of code before......on the contrary! That'd
>be a disaster. I'm just voicing some more thoughts on voting behaviour
>before heading to bed......if it all sounds silly just ignore me :)
>
>weltrusten (g'night),
>
>- Leo
>
>
>
>--
>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
>
>
>
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>