You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Stephen McConnell <mc...@apache.org> on 2003/07/29 15:06:15 UTC
limiting the scope of avalon
Berin Loritsch wrote:
> ?! The only things we officially have in place are ECM, Fortress, and
> Phoenix. It should be limited to that function set.
Berin:
I would like to draw you attention to the following:
* The excalibur-lifecycle package is released and is a part of the
Avalon toolkit.
* The meta-info package is in sandbox and is certainly ready for release
as is.
* The Merlin container is also ready for release.
I don't think we should ignore our responsibilities with respect to
released packages, and I don't think we should promote an artificial and
self-serving discrimination against the contributions that exist in the
sandbox.
Steve.
--
Stephen J. McConnell
mailto:mcconnell@apache.org
http://www.osm.net
Sent via James running under Merlin as an NT service.
http://avalon.apache.org/sandbox/merlin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: releasing merlin
Posted by Berin Loritsch <bl...@apache.org>.
Stephen McConnell wrote:
>
> I am not trying to attack you. I am protecting the integrity of the
> Merlin product and the interests of Merlin users. I am trying to hold
> together something that is complete. I am trying to prevent your
> introduction of fractures to an object model arising out of you lack of
> understanding. Finally, I am questioning the validity of the process you
> are using to coerce this community into a decision that would conflict
> with my rights as an Apache committer.
>
The Merlin product and Merlin users need to be Avalon users. It should not
need protecting. Let the rest of the community put in their voices. I have
said enough already.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: releasing merlin
Posted by Stephen McConnell <mc...@apache.org>.
Berin Loritsch wrote:
> Stephen McConnell wrote:
>
>> Berin Loritsch wrote:
>>
>>>
>>> I think I eloquently stated my position, and I believe my goal is
>>> compatible with yours.
>>
>>
>> I agree completely. You elequantly confirmed that you don't
>> understand the problem. You eloquently described your *fear* of the
>> pollution of the avalon namespace. You eloquently described you
>> *uncertainty* as to technical applicability, and you eloquently
>> described your *doubt* with respect to utility. This is common
>> referred to *FUD*.
>
>
> Is this how you define "working with others"? I put forth my concerns in
> as simple and unconfrontational method as I could. I would appreciate it
> if you would return the favor. I would also appreciate it if you would
> meet halfway on this which you seem to be unable to do, and cannot
> express
> why.
Berin - I asked a simple question addressing the technical issues that
you had. You replied with an that confirmed that in fact you have no
technical issues. Instead you presented the basis of your agreement for
the modification to avalon-meta package on the grounds of fears,
uncertainties and doubts. I would appreciate it if you could go back to
the technical issues - i.e. actually raise a technical issue support you
position. That at least would provide grounds for some sort of
collaboration.
I have objected to you proposal, siting the technical inconsitency you
creating between the object model and the tag model. I have also stated
that this has import ramifications. I consider my rejection of your
attempt at coersion equivelent to a veto against your attempts to change
the codebase in a manner that I consider techincally detrimental.
>
>> The only person who is making a Merlin release a big deal is yourself.
>
>
> Pete Royal just negated your assertion.
I would not say that.
Peter is not making a big deal of of the the release subject.
He expressed a concern - a concern that is completely valid.
http://marc.theaimsgroup.com/?l=avalon-dev&m=105949900927447&w=2
I have replied to Pete message including some thoughts on the subject.
http://marc.theaimsgroup.com/?l=avalon-dev&m=105949993028565&w=2
>
>> You commenced the process by stating that you would block a release
>> unless it fulfilled you preconditions. This statement was grossly
>> misleading simply because you do not have that authority. It is this
>> majority of committers in this community of which you are only one
>> that carry the decision on a release. Secondly, you have argued your
>> FUD agenda using every possible avenue including threats of my
>> dismissal from Avalon. We are not 90% on anything. I moved what is a
>> complete, working and stable sub-system out of Merlin and into
>> sandbox to facilitate collaboration on establishing a common
>> platform. A lot of time has been spent addressing many aspects
>> bringing in in-line. During that process you have launched what can
>> only be described as an attack against me on the subject of
>> extensions. And yet your rationalization comes down to nothing more
>> than FUD arrising from you self proclaimed lack of knowledge. Once
>> you actually take the time to address the technical issues - there
>> will be the potential to reach 100%. In the meantime you have a lot
>> of credibility that you need to recover.
>
>
> Did I EVER threaten to dismiss you from Avalon? Please point out the
> exact message, complete with a link. What you have just done is defined
> as either slander or libel depending on how you interpret emails (written
> or spoken word). It is a serious allegation, and without PROOF which is
> your burden, I demand and appology.
Lets take into consideration the following the following context that
you established yesterday.
Berin Loritsch wrote to PMC:
> Stephen, it is this anti cooperative spirit that is causing most
> of the
> problems. We can continue the discussion of you refusing to cooperate
> on the PMC list. For now, the vote stands, and any publicly released
> Avalon technology *will* be bound by its outcome. I advise you to
> vote.
>
> If you refuse to abide by the decisions of the Avalon team, then I
> highly
> recommend you reevaluate that position.
In a following email on the same day, you clarified your position.
Berin Loritsch wrote to PMC:
> This will hopefully be my last hard-line message, but I want it to
> be very
> clear that the tail will not wag the dog. Either learn to work
> with everyone
> else, and RESPECT THEIR DECISIONS, or leave.
What exactly should I conclude from this. You are telling me that I must
accept your attempt to coerce a decision supporting your idea of a what
a product should be when you have not contributed to that product
(beyond the addition of some test cases). You require that I accept the
outcome of that decision, even though the process is for decision making
is questionable and your own knowledge on the subject (you yourself
said) is insufficient. Irrespective of this, you present me with an
ultimatum - either I respect the outcome or I leave.
My interpretation of these remarks are that if I do not accept your
attempts at coercion (as opposed to following the Jakarta guidelines and
respecting the rights of contributors and policy concerning product
releases), then I presumably will be forced to leave. If have
misunderstood the implications and ultimatums that you have put to me,
then I humbly apologize.
In the meantime, I will seeking formal clarification of my rights as a
Apache committer to protect by veto changes to a product which are in my
opinion detrimental.
>
> I also expect you to come to grips with reality. Take a break if you
> have to.
>
>
>>> All a user needs to know is that if they implement the set of Avalon
>>> tags, their
>>> component will work accross all the containers.
>>
>>
>> Look - you said it here "All a user needs to know is that if they
>> implement the set of Avalon tags" and yet you want to fragment that
>> same namespace in such a way that users of will be obliged to use
>> Avalon tags plus Lifecycle tags. This is simply indicative of the
>> problem you are creating. Your statement reflects the impact of your
>> suggestion - disenfranchising a core subset of a object model simply
>> because you do not understand it.
>
>
> ?! Come again? I don't understand your logic here.
Please take a deep breath - go for a walk around the block - come back,
sit down and reead this carefully.
Your words:
-----------
* "All a user needs to know is that if they implement the set of Avalon
tags".
Logical interpritation:
-----------------------
* "All a user needs to to is implement @avalon"
Result:
-------
* notions of extension management will be sidelined
* attempts at reconsiling container differences will be made more difficult
* Merlin development and users will be prejudiced.
Rational:
---------
* fear of poluting the namespace
* uncertainty with respect to applicabilty
* doubt concerning utility
Solution:
---------
* don't attempt this now - there clearly isn't concensus
* take some time to understand the implications and the consequences
* revist the subject when we have greater user and developer experience
>
>> On one hand you imply support for the meta-info model as it is - with
>> full support for stage and extension declaration. On the other hand
>> you claim that these features are not needed, unsupported, and you
>> even go so far to imply that related products are not released. In
>> the context of all of this - I have zero confidence that you will not
>> continue this process of disruption and fragmentation into the tools
>> and the meta-info API.
>
>
> ?! Come again? I never suggested full support for the stage and extension
> declaration. I suggested support for it as a starting point--that is all.
> I also never said that the features were not needed, but I did correct
> your
> assertions.
What level of confidence can I have in you persistence on this subject?
Do you intend to remove or re-package and non-core, the stage and
extension defintions from the meta-info model type defintion? If yes -
then we can stop this discussion right here. If no - they you need to
explain why you are determined to break apart that model at the level of
tag declarations.
>
>>> Let's start with what we know. We can add in what we don't over time.
>>
>>
>> I suggest we move @avalon.meta -or @merlin - we maintain integrity of
>> the model. And you can sleep at night in the knowledge that your
>> Avalon namespace is clean. In the meantime some up who are much more
>> interested in putting together a complete and integral solution can
>> get on with the things we like doing.
>
>
> Why are you posturing? There is no need.
Please Berin - ths is not posturing. It is being pragmatic. You are
creating obsticle after obsticle. You are suggesting more preconditions
on a Merlin a release. You are now suggesting that a Merlin release
could occur after release Avalon-Meta, after incorporating that into
Fortress and incorporating this into Phoneix. This is completely
unrealistic, totally inconsitent with procedures, and completely
dissassociated with volontary open-souce collaboration.
>
>>> If we release the general Meta Info library with the set of Avalon
>>> tags we have
>>> agreed to up to this point,
>>
>>
>> We haven’t agreed anything of substance. We have an AMTAGS proposal
>> that does not meet requirements. We have you attempt to force a
>> decision from a position of ignorance that not only is biased against
>> the Merlin platform, but will itself lead to fragmentation and
>> confusion.
>
>
> The ONLY thing we have not agreed to is the extension/stage tags. That is
> it. Everything else is ok. So are you saying that unless extension/stage
> are included in the Avalon namespace that we haven't agreed to
> anything of
> substance?
>
> Why respond to kind words with harsh?
Has it occured to you as a result of you sustained assult on a product
that you don't understand, that I can only assume that after you get
what you want - you will not leave it at that. No. I can only assume
that you intend to continue the attack of the notion of extensions such
that you will continue until you isolate this notion to the Merlin
platform.
>
>>> then after we incorporate it into Fortress and
>>> Phoenix, I have no issues with a Merlin release.
>>
>>
>> More preconditions? Perhaps you could do everyone a favor and stop
>> this ridiculous process of preconditioning. While you’re at it -
>> could you pull back on the FUD and drop the threats. In the meantime
>> I'm going back to things that are fun and interesting. In particular,
>> I will continue to move Merlin forward with the support of the user
>> community as a complete and viable solution.
>
>
> How about one more. Unless you stop your own FUD marketing and threats
> no Merlin technology can be released in any way shape or form.
As a committer within Avalon - this is not your decision. As a member of
the PMC - this is not you decision. As chairman of the PMC you could set
a precedent and override the decision of a community.
> As long as you continue to attack those trying to work with you and
> refuse to work
> with anyone else (including me) I definitely cannot support its release.
> It's that simple.
I am not trying to attack you. I am protecting the integrity of the
Merlin product and the interests of Merlin users. I am trying to hold
together something that is complete. I am trying to prevent your
introduction of fractures to an object model arising out of you lack of
understanding. Finally, I am questioning the validity of the process you
are using to coerce this community into a decision that would conflict
with my rights as an Apache committer.
Stephen.
--
Stephen J. McConnell
mailto:mcconnell@apache.org
http://www.osm.net
Sent via James running under Merlin as an NT service.
http://avalon.apache.org/sandbox/merlin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: releasing merlin
Posted by Berin Loritsch <bl...@apache.org>.
Stephen McConnell wrote:
> Berin Loritsch wrote:
>>
>> I think I eloquently stated my position, and I believe my goal is
>> compatible with yours.
>
> I agree completely. You elequantly confirmed that you don't understand
> the problem. You eloquently described your *fear* of the pollution of
> the avalon namespace. You eloquently described you *uncertainty* as to
> technical applicability, and you eloquently described your *doubt* with
> respect to utility. This is common referred to *FUD*.
Is this how you define "working with others"? I put forth my concerns in
as simple and unconfrontational method as I could. I would appreciate it
if you would return the favor. I would also appreciate it if you would
meet halfway on this which you seem to be unable to do, and cannot express
why.
> The only person who is making a Merlin release a big deal is yourself.
Pete Royal just negated your assertion.
> You commenced the process by stating that you would block a release
> unless it fulfilled you preconditions. This statement was grossly
> misleading simply because you do not have that authority. It is this
> majority of committers in this community of which you are only one that
> carry the decision on a release. Secondly, you have argued your FUD
> agenda using every possible avenue including threats of my dismissal
> from Avalon. We are not 90% on anything. I moved what is a complete,
> working and stable sub-system out of Merlin and into sandbox to
> facilitate collaboration on establishing a common platform. A lot of
> time has been spent addressing many aspects bringing in in-line. During
> that process you have launched what can only be described as an attack
> against me on the subject of extensions. And yet your rationalization
> comes down to nothing more than FUD arrising from you self proclaimed
> lack of knowledge. Once you actually take the time to address the
> technical issues - there will be the potential to reach 100%. In the
> meantime you have a lot of credibility that you need to recover.
Did I EVER threaten to dismiss you from Avalon? Please point out the
exact message, complete with a link. What you have just done is defined
as either slander or libel depending on how you interpret emails (written
or spoken word). It is a serious allegation, and without PROOF which is
your burden, I demand and appology.
I also expect you to come to grips with reality. Take a break if you
have to.
>> All a user needs to know is that if they implement the set of Avalon
>> tags, their
>> component will work accross all the containers.
>
> Look - you said it here "All a user needs to know is that if they
> implement the set of Avalon tags" and yet you want to fragment that same
> namespace in such a way that users of will be obliged to use Avalon tags
> plus Lifecycle tags. This is simply indicative of the problem you are
> creating. Your statement reflects the impact of your suggestion -
> disenfranchising a core subset of a object model simply because you do
> not understand it.
?! Come again? I don't understand your logic here.
> On one hand you imply support for the meta-info model as it is - with
> full support for stage and extension declaration. On the other hand you
> claim that these features are not needed, unsupported, and you even go
> so far to imply that related products are not released. In the context
> of all of this - I have zero confidence that you will not continue this
> process of disruption and fragmentation into the tools and the meta-info
> API.
?! Come again? I never suggested full support for the stage and extension
declaration. I suggested support for it as a starting point--that is all.
I also never said that the features were not needed, but I did correct your
assertions.
>> Let's start with what we know. We can add in what we don't over time.
>
> I suggest we move @avalon.meta -or @merlin - we maintain integrity of
> the model. And you can sleep at night in the knowledge that your Avalon
> namespace is clean. In the meantime some up who are much more interested
> in putting together a complete and integral solution can get on with the
> things we like doing.
Why are you posturing? There is no need.
>> If we release the general Meta Info library with the set of Avalon
>> tags we have
>> agreed to up to this point,
>
> We haven’t agreed anything of substance. We have an AMTAGS proposal that
> does not meet requirements. We have you attempt to force a decision from
> a position of ignorance that not only is biased against the Merlin
> platform, but will itself lead to fragmentation and confusion.
The ONLY thing we have not agreed to is the extension/stage tags. That is
it. Everything else is ok. So are you saying that unless extension/stage
are included in the Avalon namespace that we haven't agreed to anything of
substance?
Why respond to kind words with harsh?
>> then after we incorporate it into Fortress and
>> Phoenix, I have no issues with a Merlin release.
>
> More preconditions? Perhaps you could do everyone a favor and stop this
> ridiculous process of preconditioning. While you’re at it - could you
> pull back on the FUD and drop the threats. In the meantime I'm going
> back to things that are fun and interesting. In particular, I will
> continue to move Merlin forward with the support of the user community
> as a complete and viable solution.
How about one more. Unless you stop your own FUD marketing and threats
no Merlin technology can be released in any way shape or form. As long
as you continue to attack those trying to work with you and refuse to work
with anyone else (including me) I definitely cannot support its release.
It's that simple.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: releasing merlin
Posted by Stephen McConnell <mc...@apache.org>.
Peter Royal wrote:
> On Tuesday, July 29, 2003, at 01:10 PM, Stephen McConnell wrote:
>
>> The only person who is making a Merlin release a big deal is yourself.
>
>
> I have reservations about a release, only because I thought the
> roadmap towards a single container coming out of this project that we
> all decided upon included incorporating merlin into a release of that
> container, but not a release of merlin by itself.
Please keep in mind that I don't want to do a release in the classic
Avalon tradition. What I want to see put in place is a frequent release
process with binary drops every months or two (i.e. much like the Maven
approach). This will provide ample opportunity for people to learn and
discover what is important and what isn't. It is absolutely clear to me
that we cannot move forward on a common solution without a greater
level of developer participation and with broader community knowledge of
the issues involved.
As that process moves forward we will gain broader participation and
understanding. And from that, there will perhaps be technologies of
relevance that the Merlin project can contribute to a common Avalon
solution. The difference is that those contributions will have been
more broadly validated and the their value towards Avalon will be more
relevant.
Stephen.
--
Stephen J. McConnell
mailto:mcconnell@apache.org
http://www.osm.net
Sent via James running under Merlin as an NT service.
http://avalon.apache.org/sandbox/merlin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: releasing merlin
Posted by Peter Royal <pr...@apache.org>.
On Tuesday, July 29, 2003, at 01:10 PM, Stephen McConnell wrote:
> The only person who is making a Merlin release a big deal is yourself.
I have reservations about a release, only because I thought the roadmap
towards a single container coming out of this project that we all
decided upon included incorporating merlin into a release of that
container, but not a release of merlin by itself.
-pete
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: releasing merlin
Posted by Stephen McConnell <mc...@apache.org>.
Berin Loritsch wrote:
> Stephen McConnell wrote:
>
>>
>>
>> Berin Loritsch wrote:
>>
>>> Stephen McConnell wrote:
>>>
>>>>
>>>> This really has created an environment where I do not feel
>>>> confident in accepting your statements without a lot a suspicion
>>>> and skepticism. I think it would be better for everyone concerned
>>>> if I simply move the avalon-meta package back into Merlin, moving
>>>> everything into the merlin namespace, and move forward from there.
>>>> This will enable the assessment of Merlin's approach to
>>>> meta-management, tags, tools, extensions, components, etc. - and
>>>> from this, hopefully and more informed decision can be taken at
>>>> some time in the future.
>>>
>>>
>>> Don't do that. We have been making progress, and I would be against
>>> destroying
>>> that progress.
>>
>>
>> In your reply to my request for a checklist of lifecycle extension
>> concerns:
>>
>> http://marc.theaimsgroup.com/?l=avalon-dev&m=105948538408807&w=2
>>
>> You detailed that fact that you concerns are not in fact technical in
>> nature - but instead - concerns related to the inclusion of
>> facilities into the Avalon core namespace without sufficient
>> understanding of these concerns by the development community and
>> without sufficient feedback from t he user community. In fact we can
>> summarize this entire "conflict" as a question of fear of the
>> unknown, uncertainty of applicability, and doubt concerning utility.
>
>
> I think I eloquently stated my position, and I believe my goal is
> compatible with yours.
I agree completely. You elequantly confirmed that you don't understand
the problem. You eloquently described your *fear* of the pollution of
the avalon namespace. You eloquently described you *uncertainty* as to
technical applicability, and you eloquently described your *doubt* with
respect to utility. This is common referred to *FUD*.
>
>> Releasing Merlin would address each and every-one of your concerns.
>> Based on broader user feedback and greater developer experience we
>> will be in a much better position to move forward constructively.
>
>
> Actually, I think it would make things a little worse by diluting our
> already
> thin resources. We have 90% of the equation agreed to. I think it
> would be
> better for us to publish that 90% now, so that we can integrate them
> into the
> other containers. That way, a realease of Merlin won't be such a big
> deal.
The only person who is making a Merlin release a big deal is yourself.
You commenced the process by stating that you would block a release
unless it fulfilled you preconditions. This statement was grossly
misleading simply because you do not have that authority. It is this
majority of committers in this community of which you are only one that
carry the decision on a release. Secondly, you have argued your FUD
agenda using every possible avenue including threats of my dismissal
from Avalon. We are not 90% on anything. I moved what is a complete,
working and stable sub-system out of Merlin and into sandbox to
facilitate collaboration on establishing a common platform. A lot of
time has been spent addressing many aspects bringing in in-line. During
that process you have launched what can only be described as an attack
against me on the subject of extensions. And yet your rationalization
comes down to nothing more than FUD arrising from you self proclaimed
lack of knowledge. Once you actually take the time to address the
technical issues - there will be the potential to reach 100%. In the
meantime you have a lot of credibility that you need to recover.
>
> All a user needs to know is that if they implement the set of Avalon
> tags, their
> component will work accross all the containers.
Look - you said it here "All a user needs to know is that if they
implement the set of Avalon tags" and yet you want to fragment that same
namespace in such a way that users of will be obliged to use Avalon tags
plus Lifecycle tags. This is simply indicative of the problem you are
creating. Your statement reflects the impact of your suggestion -
disenfranchising a core subset of a object model simply because you do
not understand it.
On one hand you imply support for the meta-info model as it is - with
full support for stage and extension declaration. On the other hand you
claim that these features are not needed, unsupported, and you even go
so far to imply that related products are not released. In the context
of all of this - I have zero confidence that you will not continue this
process of disruption and fragmentation into the tools and the meta-info
API.
>
>
> Let's start with what we know. We can add in what we don't over time.
I suggest we move @avalon.meta -or @merlin - we maintain integrity of
the model. And you can sleep at night in the knowledge that your Avalon
namespace is clean. In the meantime some up who are much more interested
in putting together a complete and integral solution can get on with the
things we like doing.
>
> If we release the general Meta Info library with the set of Avalon
> tags we have
> agreed to up to this point,
We haven’t agreed anything of substance. We have an AMTAGS proposal that
does not meet requirements. We have you attempt to force a decision from
a position of ignorance that not only is biased against the Merlin
platform, but will itself lead to fragmentation and confusion.
> then after we incorporate it into Fortress and
> Phoenix, I have no issues with a Merlin release.
More preconditions? Perhaps you could do everyone a favor and stop this
ridiculous process of preconditioning. While you’re at it - could you
pull back on the FUD and drop the threats. In the meantime I'm going
back to things that are fun and interesting. In particular, I will
continue to move Merlin forward with the support of the user community
as a complete and viable solution.
Stephen.
--
Stephen J. McConnell
mailto:mcconnell@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: releasing merlin
Posted by Berin Loritsch <bl...@apache.org>.
Stephen McConnell wrote:
>
>
> Berin Loritsch wrote:
>
>> Stephen McConnell wrote:
>>
>>>
>>> This really has created an environment where I do not feel confident
>>> in accepting your statements without a lot a suspicion and
>>> skepticism. I think it would be better for everyone concerned if I
>>> simply move the avalon-meta package back into Merlin, moving
>>> everything into the merlin namespace, and move forward from there.
>>> This will enable the assessment of Merlin's approach to
>>> meta-management, tags, tools, extensions, components, etc. - and from
>>> this, hopefully and more informed decision can be taken at some time
>>> in the future.
>>
>> Don't do that. We have been making progress, and I would be against
>> destroying
>> that progress.
>
> In your reply to my request for a checklist of lifecycle extension
> concerns:
>
> http://marc.theaimsgroup.com/?l=avalon-dev&m=105948538408807&w=2
>
> You detailed that fact that you concerns are not in fact technical in
> nature - but instead - concerns related to the inclusion of facilities
> into the Avalon core namespace without sufficient understanding of these
> concerns by the development community and without sufficient feedback
> from the user community. In fact we can summarize this entire
> "conflict" as a question of fear of the unknown, uncertainty of
> applicability, and doubt concerning utility.
I think I eloquently stated my position, and I believe my goal is compatible
with yours.
> Releasing Merlin would address each and every-one of your concerns.
> Based on broader user feedback and greater developer experience we will
> be in a much better position to move forward constructively.
Actually, I think it would make things a little worse by diluting our already
thin resources. We have 90% of the equation agreed to. I think it would be
better for us to publish that 90% now, so that we can integrate them into the
other containers. That way, a realease of Merlin won't be such a big deal.
All a user needs to know is that if they implement the set of Avalon tags, their
component will work accross all the containers.
Let's start with what we know. We can add in what we don't over time.
If we release the general Meta Info library with the set of Avalon tags we have
agreed to up to this point, then after we incorporate it into Fortress and
Phoenix, I have no issues with a Merlin release.
From that point forward, we can work on collaborating for that last 10%.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
releasing merlin
Posted by Stephen McConnell <mc...@apache.org>.
Berin Loritsch wrote:
> Stephen McConnell wrote:
>
>>
>> This really has created an environment where I do not feel confident
>> in accepting your statements without a lot a suspicion and
>> skepticism. I think it would be better for everyone concerned if I
>> simply move the avalon-meta package back into Merlin, moving
>> everything into the merlin namespace, and move forward from there.
>> This will enable the assessment of Merlin's approach to
>> meta-management, tags, tools, extensions, components, etc. - and from
>> this, hopefully and more informed decision can be taken at some time
>> in the future.
>
>
>
> Don't do that. We have been making progress, and I would be against
> destroying
> that progress.
In your reply to my request for a checklist of lifecycle extension concerns:
http://marc.theaimsgroup.com/?l=avalon-dev&m=105948538408807&w=2
You detailed that fact that you concerns are not in fact technical in
nature - but instead - concerns related to the inclusion of facilities
into the Avalon core namespace without sufficient understanding of these
concerns by the development community and without sufficient feedback
from the user community. In fact we can summarize this entire
"conflict" as a question of fear of the unknown, uncertainty of
applicability, and doubt concerning utility.
Releasing Merlin would address each and every-one of your concerns.
Based on broader user feedback and greater developer experience we will
be in a much better position to move forward constructively.
Stephen.
--
Stephen J. McConnell
mailto:mcconnell@apache.org
http://www.osm.net
Sent via James running under Merlin as an NT service.
http://avalon.apache.org/sandbox/merlin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: limiting the scope of avalon
Posted by Berin Loritsch <bl...@apache.org>.
Stephen McConnell wrote:
>
>
> Berin Loritsch wrote:
>
>> Stephen McConnell wrote:
>>
>>>
>>>
>>> Berin Loritsch wrote:
>>>
>>>> ?! The only things we officially have in place are ECM, Fortress, and
>>>> Phoenix. It should be limited to that function set.
>>>
>>>
>>>
>>>
>>>
>>> Berin:
>>>
>>> I would like to draw you attention to the following:
>>>
>>> * The excalibur-lifecycle package is released and is a part of the
>>> Avalon toolkit.
>>> * The meta-info package is in sandbox and is certainly ready for
>>> release as is.
>>> * The Merlin container is also ready for release.
>>>
>>> I don't think we should ignore our responsibilities with respect to
>>> released packages, and I don't think we should promote an artificial
>>> and self-serving discrimination against the contributions that exist
>>> in the sandbox.
>>
>>
>>
>> I hear you loud and clear. However, getting back to my question about
>> how to manage the growth of APIs, please let me draw your attention to
>> the
>> following:
>>
>> * I would like meta-info and Merlin released
>> * For those function areas that we have not all had time to digest,
>> namely
>> the extension meta info, I would like a breakin period.
>> * The rest of the meta-info standard is ready for release without any
>> reservations.
>
>
>
> Berin:
>
> I've put a lot of time into the separation of the meta-info package out
> of Merlin and into a avalon-meta. This included documentation, APIs,
> synchronizing on tags, etc. During this process:
>
> * I have been accused by you of being diverse.
Look, maybe diverse was a bad choice of terms. However, the fact remains
that there were different ways of doing things, and we needed to come
together on it. That was my intent. Unfortunately you chose to focus on
the word "diverse".
> * I have been told by you that a release will not happen until your
> issues are resolved
You have the same right to raise issues for things I propose to release.
> * I have been accused of ignoring your views.
You have not recognized them at all. You keep restating your views without
acknowleging mine. Can you blame me for accusing you that?
> * I have been told by you to pull in line or leave Avalon.
Right. You stated that you will choose not to abide by the decision or
outcome of a vote, ignoring your peers. I was well within my rights to
call you on the carpet on this.
>
> This really has created an environment where I do not feel confident in
> accepting your statements without a lot a suspicion and skepticism. I
> think it would be better for everyone concerned if I simply move the
> avalon-meta package back into Merlin, moving everything into the merlin
> namespace, and move forward from there. This will enable the assessment
> of Merlin's approach to meta-management, tags, tools, extensions,
> components, etc. - and from this, hopefully and more informed decision
> can be taken at some time in the future.
Don't do that. We have been making progress, and I would be against destroying
that progress. In fact, do not move anything in the sandbox CVS. Let's hash
out the issues and move forward.
Secondly, Merlin will never get released unless you can work with the rest of
us. You can't run and hide in a corner just because you reached a little
opposition.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: limiting the scope of avalon
Posted by Stephen McConnell <mc...@apache.org>.
Berin Loritsch wrote:
> Stephen McConnell wrote:
>
>>
>>
>> Berin Loritsch wrote:
>>
>>> ?! The only things we officially have in place are ECM, Fortress, and
>>> Phoenix. It should be limited to that function set.
>>
>>
>>
>>
>> Berin:
>>
>> I would like to draw you attention to the following:
>>
>> * The excalibur-lifecycle package is released and is a part of the
>> Avalon toolkit.
>> * The meta-info package is in sandbox and is certainly ready for
>> release as is.
>> * The Merlin container is also ready for release.
>>
>> I don't think we should ignore our responsibilities with respect to
>> released packages, and I don't think we should promote an artificial
>> and self-serving discrimination against the contributions that exist
>> in the sandbox.
>
>
> I hear you loud and clear. However, getting back to my question about
> how to manage the growth of APIs, please let me draw your attention to
> the
> following:
>
> * I would like meta-info and Merlin released
> * For those function areas that we have not all had time to digest,
> namely
> the extension meta info, I would like a breakin period.
> * The rest of the meta-info standard is ready for release without any
> reservations.
Berin:
I've put a lot of time into the separation of the meta-info package out
of Merlin and into a avalon-meta. This included documentation, APIs,
synchronizing on tags, etc. During this process:
* I have been accused by you of being diverse.
* I have been told by you that a release will not happen until your
issues are resolved
* I have been accused of ignoring your views.
* I have been told by you to pull in line or leave Avalon.
This really has created an environment where I do not feel confident in
accepting your statements without a lot a suspicion and skepticism. I
think it would be better for everyone concerned if I simply move the
avalon-meta package back into Merlin, moving everything into the merlin
namespace, and move forward from there. This will enable the assessment
of Merlin's approach to meta-management, tags, tools, extensions,
components, etc. - and from this, hopefully and more informed decision
can be taken at some time in the future.
Stephen.
--
Stephen J. McConnell
mailto:mcconnell@apache.org
http://www.osm.net
Sent via James running under Merlin as an NT service.
http://avalon.apache.org/sandbox/merlin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: limiting the scope of avalon
Posted by Berin Loritsch <bl...@apache.org>.
Stephen McConnell wrote:
>
>
> Berin Loritsch wrote:
>
>> ?! The only things we officially have in place are ECM, Fortress, and
>> Phoenix. It should be limited to that function set.
>
>
>
> Berin:
>
> I would like to draw you attention to the following:
>
> * The excalibur-lifecycle package is released and is a part of the
> Avalon toolkit.
> * The meta-info package is in sandbox and is certainly ready for release
> as is.
> * The Merlin container is also ready for release.
>
> I don't think we should ignore our responsibilities with respect to
> released packages, and I don't think we should promote an artificial and
> self-serving discrimination against the contributions that exist in the
> sandbox.
I hear you loud and clear. However, getting back to my question about
how to manage the growth of APIs, please let me draw your attention to the
following:
* I would like meta-info and Merlin released
* For those function areas that we have not all had time to digest, namely
the extension meta info, I would like a breakin period.
* The rest of the meta-info standard is ready for release without any
reservations.
My idea to grow the API in a controllable and sustainable way is to introduce
new ideas and concepts in a separate namespace. I prefer a functional one as
opposed to a container specific one. This will allow the rest of us to see
how it works with Fortress/Merlin/and possibly even Phoenix. When the rest of
us (including me) are comfortable with the solution, we can vote to include it
in the Avalon namespace.
So far, the only side of the equation that I have asked us to change is the
meta-info gathering tool (meta-tools). That means the rest of the entire
equation (i.e. the XML descriptors and serialized meta info) has not changed.
Those are the container contracts--and for now I am most interested in the
client contracts. The only impact to moving the attributes back into the
avalon namespace is to have the meta-tools recognize both @avalon and
@lifecycle, issuing a deprecation warning for @lifecycle.
I really don't think that is unreasonable, do you?
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org