avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen McConnell <mcconn...@apache.org>
Subject Re: [RRT] Getting back to the basics (long)
Date Wed, 30 Jul 2003 21:08:02 GMT

Berin Loritsch wrote:

> Stephen McConnell wrote:
>> Included in your RRT was the subject of a "Community Agreement 
>> Process". In that description you suggested that Jakarta rules are 
>> insufficient (a point I would contest). Within those guideline you 
>> proposed something that in my view attempts to engineer the direction 
>> of the community.
>> Berin Loritsch wrote (original post):
>>> * Once all _questions_ have been answered about the differing 
>>> proposals, and
>>> the proposals are finished with any modifications due to the questions,
>>> we place it up for vote. The proposal that wins, wins. No exceptions.
>> This set up rules - it changes the scope of what people here can do. 
>> I states that the community must follow without exception. That is a 
>> equivalent to modification of the charter. What happens if someone 
>> does something inside the scope of existing Avalon charter but 
>> outside the scope of the "plan". Are they expelled from Avalon? Are 
>> they coerced into doing things they don't want to do? Or will they 
>> simply be pushed out by a select few. These are fundamental issues 
>> that impact the community and our freedom to work within the charter 
>> that has been established by the Apache Board.
> Gee, here is a radical idea: instead of wondering what happens to them,
> just take it for what it was meant. A way to get past stalemates. If
> we all agree to it, then there is no issue. These types of questions
> make me believe you intend on making a big deal out of things.


I'm focussing here on the implications of the procedures and attempting 
to point out that the procedures themselves can be detrimental to the 
community at a social level, and that suggesting that this could have a 
negative impact on how things evolve here at Avalon. But then again I 
don't have a degree in group behavior or social science.

>> The alternative is to respect the community as a process from which 
>> things emerge - promote and support the best of those and learn from 
>> the rest.
> Objections duly noted. However, consider my last attempt to work with you
> on the Avalon meta project in sandbox. Instead of escalating a stalemate,
> we are providing an out. Community rules--whether in your favor or mine
> or someone else's it doesn't matter. 

As you known Berin - I have raised a veto against the changes you have 
proposed. The veto notification was submitted to the PMC yesterday. I 
also mentioned a number of options available to anyone that ensure that 
there is stalemate here. If anyone would like to receive a copy of the 
veto notification - I am quite happy to post it to the list. As far as I 
am concerned - that issue is closed.

Lets move on - I outlined a few ideas towards the end of this email.

>>>> Instead - let thing evolve because this community wants them to 
>>>> evolve. As you know, I'm quite keen on seeing the development here 
>>>> in Avalon of a common containment API but I'm also opposed to the 
>>>> notion of one container. In fact the vision I like is the ability 
>>>> to pull in a container matching your own needs - dynamically. Its a 
>>>> vision with lots of commonality with your own thoughts. But if we 
>>>> put down a rule that said there must one and only one container - 
>>>> we would immediately in conflict. The problem here is that rules 
>>>> force us into directions which we may not want to go. Underlying 
>>>> this is the problem that rules can used to coerce members of the 
>>>> community in unforeseen ways.
>>> Any issues with the vision in general other than the one container 
>>> issue? 
>> * I'm not interested in a start from scratch scenario
>> * Instead build on what we have based on shared objectives
>> * Opposed to the Community Agreement Process in general
>> There may be other issues - but these these leap out at me!
> Again. Your issues are duly noted. As to point two, I believe
> that is the main reason why we are stalemated and not moving
> forward. We don't seem to have shared objectives.

I think we do. In fact I think you hinted at this earlier in the week 
when you mentioned that the work on the meta-info framework represents 
90% of what you wanted. I figure that 90% represents a lot of shared 
space - and that's a good result.

>>>> Another approach is to encourage and foster the contributions of 
>>>> developers here at Avalon based on shared objectives - and through 
>>>> this, facilitate the evolution of best-of-breed solutions. To 
>>>> enable adventure, good times, and great results.
>>>> There are some things we can do to facilitate this:
>>>> * get rid of the notion of managing the community (less stress)
>>>> * introduce a vibrant release process (frequent releases)
>>>> * encourage experiments (more surprises)
>>>> * capture and promote the best of breed (recognition)
>>> I could have swarn that I had 3 out of 4 of those nailed. As to
>>> managing the community, I believe this is largely a misconception. 
>> If you want to propose a project for sandbox - then cool - from there 
>> you can work towards what you have in mind. It does not really fit 
>> within my own view of where we are heading so I guess I want be an 
>> interested observer. But if you introduce the notion of rules - your 
>> kind of twisting my arm to work within the context of something I 
>> haven’t bought into. Remember - you said - "No Exception". That's 
>> attempting to engineer community direction and that's simply not what 
>> we should be attempting to doing.
> Thank you for putting words in my mouth, and implying motivations I
> don't have.

My comment was not directed towards your motivation nor do I want to put 
words into your mouth. I am simply making an observation of other 
approaches you could take, and noting implications of a "No Exception". 
It's probably fair to make the assumption that my approach is going to 
be somewhat more liberal than own. But that's just a reflection of who 
we are.

>> Instead – think about shared objectives.
> Please list these, because every time I think I know what they are,
> you come along and blow away my view of what the shared objectives are. 

Like I said above - we see eye-to-eye on 90% in one particular example. 
I'm confident that there will other examples with equally high levels of 
mutual interest. That does not mean we need to agree right down to the 
last 1% - its just a case of leveraging the things that are mutually 
useful while maintaining a respect for the right of each and everyone 
here to hold differing options.

>>> I want to focus on something here. I want to move toward something
>>> good. I have a ton of ideas, but if I am the only one with them then
>>> what's the use? 
>> Not a lot.
>> Why not try working with some of the other actives going on and see 
>> what you could contribute?
> Tried that, got yelled at. Not interested in getting yelled at anymore.
> So. Promise not to yell, and I will help you out. Otherwise we need to
> look at other activities.

Your help is always appreciated and I encourage you and everyone else 
here in Avalon to get involved in the things that are going on that 
interests them. I confident that with a little more relaxed atmosphere 
we will make great progress. I have a bunch of things that I would love 
to talk to about on the subject of the Merlin activation package with 
respect to thread management events and so on.

>>> Also, it is clear that status quo of little islands operating to 
>>> themselves
>>> is not working. That requires some management. I am looking for a 
>>> way that
>>> lets us to kick-A stuff with the minimal amount of friction/management
>>> necessary. It is important to realize that you as a PMC member are 
>>> equally
>>> charged with managing this community as I am.
>> Yep - and in my capacity as PMC member I have already put forward 
>> some recommendations. Notable amongst those recommendations was the 
>> issue of community engineering and the negative impact this has on 
>> members of the community. I also addressed priorities facilitating 
>> community growth and development. Underscoring that proposal is my 
>> firm belief that this community does not need the type of management 
>> your describing.
> I think I've said enough on the subject--everything I say keeps getting
> twisted somewhere between where I put the suggestions down and you 
> respond.
> I'm tired of that, so I'm not rehashing it anymore.

I'm not trying to twist anything - I sorry if I gave impression.

I understand what you trying to do and we have very similar aims. The 
means to get there are the subjects I'm addressing. We do have different 
views on things - and honestly - that's what makes us interesting as 
people and as a community.

>>> As to the community guidelines I put forth in the RRT, I thought 
>>> that they
>>> encouraged best of breed recognition. The idea for the container 
>>> outline
>>> encouraged experiments--some of them could be quite wild. And all of 
>>> this
>>> would require a vibrant release process.
>> So in effect what exists here in Avalon today is what you are aiming 
>> for. We have experiments - some of which are wilder than others. But 
>> I must confess - our release process is rather stale. But I'll be 
>> getting on to that ASAP.
> Not exactly. What we have in Avalon is a fairly disjointed picture so 
> far.
> There are some common points, and we should be very happy about that. 
> What
> we don't have is a model where a component developer can freely go 
> between
> all Avalon containers and expect everything to work properly. That has 
> been
> my cheif short-term goal. However, every time I attempt that goal I meet
> opposition. SOmething is wrong. What is wrong is not technical in nature,
> but management related. Tell me, what do I have to do... and "live and 
> let
> live" isn't the answer.

I can tell what I think would be absolutely terrific.

Well, I think I've mentioned this before - I've been working away on a 
separation of meta-model from the assembly and deployment layers in 
Merlin. This is all groundwork for Merlin 3.0. In the CVS the 
composition package is all about bringing together meta-info descriptors 
with meta-data directives to create a formal deployment model. Focus 
here is to provide a model that can be managed via JMX. Above the 
composition package is the activation package - but that's local on my 
machine and is only dealing with assembly at this stage. In fact under 
Merlin 3.0 there is nothing supporting actual deployment. What I was 
planning on was to bring in an improvement of model in Merlin 2.1, but I 
wanted to get your ideas in about async. management into the picture 
before going to far.

Well - is something to think about.



Stephen J. McConnell

Sent via James running under Merlin as an NT service.

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

View raw message