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.
Berin:
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.
--
Stephen J. McConnell mailto:[EMAIL PROTECTED] http://www.osm.net
Sent via James running under Merlin as an NT service. http://avalon.apache.org/sandbox/merlin
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
