> I wonder if I'm the only one who feels that you two guys want to > engineer the Avalon charter to route around one another. You are not even remotely the only one. And I honestly don't believe that either of them realizes it. More on that in a message I've been working on. --- Noel -- To unsubscribe, e-mail: <mailto:avalon-dev-unsubscribe@jakarta.apache.org> For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>
> From: Stefano Mazzocchi [mailto:stefano@apache.org] > > Stephen McConnell wrote: > > > > > > Peter Donald wrote: > > > >> On Wed, 4 Dec 2002 15:59, Berin Loritsch wrote: > >> > >> > >>> Stephen has already made clear his dislike of the word > "unanimous", > >>> but before we blindly remove that word, we need to come > to community > >>> consensus. > >> > >> I am +1 on unanimous because it forces consensus for > forward motion. > >> It may mean things take longer to get decided but usually the > >> decisions are better for it. > >> > > > > And thereby grant the right to a single individual to block > progress. > > That takes away the ability of the PMC to function. If when > you take > > away it ability to function you have taken away its ability > to represent > > the comunity and its ability to meet its obligations to the board. > > I wonder if I'm the only one who feels that you two guys want to > engineer the Avalon charter to route around one another. Are you referring to Stephen and I? That is not the case. We both feel burned by events in the past, and neither of us wants the same mistake to repeat itself. I believe we both have valid points, and I proposed what I think is a valid compromise. Hopefully Stephen will agree to that middle ground. -- To unsubscribe, e-mail: <mailto:avalon-dev-unsubscribe@jakarta.apache.org> For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>
> From: Stefano Mazzocchi [mailto:stefano@apache.org] > > I also propose that every committer that will propose an > internal fork > will have to go thru the community vote to be allowed to do that. +1 -- To unsubscribe, e-mail: <mailto:avalon-dev-unsubscribe@jakarta.apache.org> For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>
Berin Loritsch wrote: >>From: Nicola Ken Barozzi [mailto:nicolaken@apache.org] >> >>leosimons@apache.org wrote: >> >>>leosimons 2002/12/04 05:30:25 >>> >>> avalon-sandbox/avalon5 - New directory >> >>Please wait for the vote to end and the results be set in the >>status file. > > > > However, it does seem we are headed for the avalon-sandbox > route. It makes sense, and it would be better for us to > get started than for us to debate the thing till the cows come > home. > > However, I do want to make my feelings clear on this point: > > I do not want to see several avalon5 proposal directories. We > as a community need to work together on one Avalon 5. We can't > do that if everyone is off in their own corner. +1 the rules for revolutionaries should be applied for that: a revolution. Avalon 5 already is one. We don't need more revolutions than one since one is already disruptive enough. I think we are not that braindamaged that we can't see a point without requiring to run the code. Expecially for non-visual things like avalon. We are doing framework design, dudes, if email is not good, send some code here or write some documents and place them on the web. We don't need several implementations or branches. I also propose that every committer that will propose an internal fork will have to go thru the community vote to be allowed to do that. -- Stefano Mazzocchi <stefano@apache.org> -------------------------------------------------------------------- -- To unsubscribe, e-mail: <mailto:avalon-dev-unsubscribe@jakarta.apache.org> For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>
> From: Stepanossov, Kirill [mailto:kstepano@lehman.com]
>
> Sorry for noise here...
Its not noise.
>
> but it looks both Berin and Stephen are right - the existence
> of veto as
> well as majority voting can be abused and both your justification are
> correct. Well... one of you is optimistic the other one is
> pessimistic with
> regards to "ability" of Avalon community and its developers... so why
> wouldn't you just look at what/who you have now in board and
> then based on
> that knowledge come to compromise conclusion... or just assign a
> person("judge"?) who should decide if the veto is valid in arguments ?
Third option is that we agree on 2/3 majority.
I am against blind majority (i.e. with 4 for and 3 against a motion
gets passed even if the objections are really good and showstoppers).
Steven is against unanimous (i.e. with 34 for and 1 against a
motion gets vetoed even if the objection is poorly stated).
With 2/3 majority and a quorum of 9 people, if you have 6 for and
3 against the motion gets passed. I also stipulated that the voting
time is open for a whole week. That leaves room for the nay sayers
to voice their opinion and possibly sway the vote, although at that
point it is more likely that the nay sayers vote will be swayed. It
also leaves room to have time to think thoroughly about a proposal
and have a good feeling after the voting is closed.
--
To unsubscribe, e-mail: <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>
Nicola Ken Barozzi wrote: > > > Peter Donald wrote: > >> Hi, >> >> I think we need to mark sandbox code clearly as being sandbox code. > > > This I agree. > It's in a CVS repository avalon-sandbox, it should have a big WARNING > file in the root and in every codebase, there should never be releases > of that code and it should be downloadable only from CVS. > >> To do this we could require that components in this place are put in >> the package. >> >> org.apache.avalon.sandbox.X >> >> This will make it very clear to users what the status of code is and >> thus they wont be misled into thinking that it is anything it is not. >> >> Thoughts/Votes? > > > This is not done even on Jakarta Commons code, and will effectively make > it more difficult to make the eventual transition. > I do not think that users that download stuff from a sandbox CVS are so > stupid not to know that it's sandbox code. > > -1 I agree -1 as well. -- Stefano Mazzocchi <stefano@apache.org> -------------------------------------------------------------------- -- To unsubscribe, e-mail: <mailto:avalon-dev-unsubscribe@jakarta.apache.org> For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>
Stephen McConnell wrote: > > > Peter Donald wrote: > >> On Wed, 4 Dec 2002 15:59, Berin Loritsch wrote: >> >> >>> Stephen has already made clear his dislike of the word "unanimous", >>> but before we blindly remove that word, we need to come to community >>> consensus. >>> >> >> >> I am +1 on unanimous because it forces consensus for forward motion. >> It may mean things take longer to get decided but usually the >> decisions are better for it. >> > > And thereby grant the right to a single individual to block progress. > That takes away the ability of the PMC to function. If when you take > away it ability to function you have taken away its ability to represent > the comunity and its ability to meet its obligations to the board. I wonder if I'm the only one who feels that you two guys want to engineer the Avalon charter to route around one another. -- Stefano Mazzocchi <stefano@apache.org> -------------------------------------------------------------------- -- To unsubscribe, e-mail: <mailto:avalon-dev-unsubscribe@jakarta.apache.org> For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>
Sorry for noise here...
but it looks both Berin and Stephen are right - the existence of veto as
well as majority voting can be abused and both your justification are
correct. Well... one of you is optimistic the other one is pessimistic with
regards to "ability" of Avalon community and its developers... so why
wouldn't you just look at what/who you have now in board and then based on
that knowledge come to compromise conclusion... or just assign a
person("judge"?) who should decide if the veto is valid in arguments ?
-----Original Message-----
From: Berin Loritsch [mailto:bloritsch@citi-us.com]
Sent: Wednesday, December 04, 2002 3:34 PM
To: 'Avalon Developers List'
Subject: RE: Avalon voting process
> From: Stephen McConnell [mailto:mcconnell@apache.org]
>
> Berin Loritsch wrote:
>
> >I propose that we follow the voting process outlined
> >by Incubator.
> >
>
> It looks good in terms of committer procedures.
> A lot of the loose ends are getting cleaned up.
>
> >It is standard across all the projects
> >I have seen. It addresses voting process of the community
> >at large, but does not address the voting process of
> >the PMC.
> >
>
> Correct.
>
> >
> >I still have yet to see other charters besides the XML
> >one, and voting guidelines do not constitute a charter.
> >I suggest that changes to the charter and voting guidelines
> >be treated as code changes, with the stipulation that only
> >PMC votes are binding.
> >
>
> -1
>
> NO, NO, NO, NO.
>
<snip/>
> I WILL PUT UP WITH THAT SORT OF RUBBISH AGAIN.
>
> NOT EVER - NEVER.
Calm down. Keep in mind what a valid veto is (in another version
of this mail).
> >That allows a PMC member to veto
> >a change with proper justification.
> >
>
> Incorrect - any justification - feeble, profound, fantasy, etc. and
> nothing to fallback on. We have today a majority voting
> process. We can
> change that thought a majority vote. That's it - there are no other
> rules applicable here. Please - just use the structure we
> have and don't
> imply anything different with a PMC vote.
I also don't want to be railroaded again--or did you miss that
when you steamrolled the Avalon PMC through? I want the ability
to say "Hold on, you need to slow down. There are more things
to think through".
With mere majority voting, my call to slow down will likely get
overrun and then I am left holding the bag and trying to clean
up your mess.
Again, I assert that a proper veto as I outlined in another
mail must be supported. A proper veto is not "I don't like it",
that is invalid. A proper veto is accompanied by a reasonable
explanation AND a counter-proposal.
> >Proper justification
> >should also have a counter-proposal so that the rest of
> >the PMC knows *how* to rectify the situation.
>
> Just image for a moment that I really object to something (like your
> ideas about voting on the PMC). And lets assume that your model is in
> place. And lets assume that you and I disagree on something
> similar. And
> lets assume that my arguments and your arguments are both
> well prepared
> and rationale. Your solution creates a deadlock - you have
> destroyed the
> intrinsic value of the PMC - and that it be able to do things
> when such
> need arrives. You don't need to look very far back into
> Avalon history
> to see evidence of this. I'm not ready to bet the form on that not
> happening again.
>
> Today - we have a majority rules on the PMC.
Today, we have not voted on any PMC bylaws, and until I started
bringing up the subject everyone was quiet.
-1 on majority rules. It opens the door to steamrolling through
concepts, ideas, etc. that are in favor of certain individuals but
not the whole of Avalon. I repeat, I will not be left holding the
bag from yours or anyone else's pushing through something before it
is completely thought out. Period. I am just as unyielding on this
point as you are on unanimous votes. I AM open to two-thirds majority
of the PMC with voting open for an entire week. However simple
majority doesn't work either. It's too easy to pull the wool over
someones eyes for the length of time for a quick vote--and then
the community regrets the outcome of the decision. The consequences
of PMC resolutions are far greater than code changes, so I want
something that will *force* us to work together on a solution we
can all live with.
I hope I am very clear on the matter. I am in favor of an Avalon
PMC, but I am against the manner in which it came into being. I
do not want to go through that again.
> In the meantime - please not more assertions of what rules
> apply - there
> are rules already in place. Lets focus on charter - not
> procedure - and
> drop any discussion about policy to apply with result to charter or
> policy evolution. It simple - a majority of the PMC voter to
> change the
> charter - the change gets escalated to the Board, the board does it
> stuff. If that's no ok - then raise a vote on the PMC list.
-1 for the reasons stated above. 2/3 majority is acceptable.
Again, I am against the way things were steamrolled through
to create the Avalon PMC, and I don't want to be subject to that
again.
> ----------ooo0ooo-----------
>
> You may sense a certain aggression/frustration here. That is brought
> about by the inability of this community to deal with the
> problems back
> in July/August - it was complicated by the inability of the
> Jakarta PMC
> to address the issue. Even the board didn't address the issue on the
> table at the time. Nobody took a position - not structure in
> the entire
> Apache organization was willing to step in with a closure. Yes - Pete
> got kicked - but that wasn't the subject of the Jakarta/Board
> discussion
> before - that was probably more of a surprise to me than to
> any of you.
> What I do know is that those types issues MUST be address by
> the Avalon
> PMC. If you continue along the lines your describing - your just
> creating the comfortable environment where you simply isolate
> yourself
> away from the potential of having to take a difficult decision.
Look, I am able and willing to make very difficult decisions.
I have made many more before Avalon was a part of my involvement.
Those decisions impacted myself, my family, and other people. I
am not afraid of standing for what I believe in. I find it a
strength.
The important thing is this: I don't want to be held responsible
for the rash decisions of others. Simple majority opens the door
for that. Mob rule did not work for Greece, and I don't think it
will work here.
> As a PMC member - I REFUSE to let a similar situation arise for other
> members of the community. I will do everything I can to
> ensure that the
> PMC is an instrument that has balls and ability. And I'm
> confident that
> providing those attributes are held up with respect - that we
> will never
> need to use them. Today the PMC has balls - please don't try to take
> that away. Its abilities will evolve through attention and
> consideration
> to the charter and procedures, and progressively, through
> respect from a
> united community.
Also keep in mind that the veto Peter issued you back in August
would not have been valid under my proposed definition of veto.
--
To unsubscribe, e-mail: <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>
------------------------------------------------------------------------------
This message is intended only for the personal and confidential use of the designated recipient(s)
named above. If you are not the intended recipient of this message you are hereby notified
that any review, dissemination, distribution or copying of this message is strictly prohibited.
This communication is for information purposes only and should not be regarded as an offer
to sell or as a solicitation of an offer to buy any financial product, an official confirmation
of any transaction, or as an official statement of Lehman Brothers. Email transmission cannot
be guaranteed to be secure or error-free. Therefore, we do not represent that this information
is complete or accurate and it should not be relied upon as such. All information is subject
to change without notice.
--
To unsubscribe, e-mail: <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>
Thanks Gary, It's funny, I woke up this morning with a similar conclusion. Yesterday, for the first time, I could see both Peter's and Stephen's arguments for a distinction between Container-supplied and Peer-supplied services (or "(non)priviledged" as Stephen is calling the distinction). The problem with both of these distinctions is that they are about Container implementation. My take on it is thus: Peter wants to distinguish Container-provided services, because the person doing the assembly doesn't have to specify them in the assembly file. Unfortunately, it's quite easy to imagine one container which provides a certain service directly, and a different one which requries a user-configured component to provide the same service. So by distinguishing between these in *code*, the component will be inherently non-portable. (Whereas the assembly file can be thought of as container-specific? - At least it's easy to change for a new deployment). Stephen wants to have the notion of priviledged services, so he can implement life-cycle handlers and context providers as components (at least this is what I've garnered from the emails, I don't know the code). While this sounds cool from the design perspective, it seems like this notion should be kept out of Framework, as it's a specific requirement of the Merlin container. Other containers may want to provide extensibility in a completely different way (maybe the "interceptors" Pete has eluded to fall into this). What follows is that regular components which rely just on Framework contracts will be portable, whereas Merlin lifecycle extension components don't need to be, so they can use a Merlin-specific contracts and interfaces. (Who says having competing container implementations is a bad thing? ;) This example is giving me a few troubles: > > getServletContext().isPrincipleInRole( String role, Principle p ); > > getSessionContext().isCallerInRole( String role ); These are container provided services, and it would "feel" right that they would be split out from the provision of other services. But then you realise: - these interfaces are defined as part of a specification. The container can't choose whether or not to provides these things, they are required. And the container can't arbitrarily provide new stuff in this way, since then a component would become non-portable. So I can't see the argument for the Container-provided/Peer-provided divide. But I can see an argument for a logical and code separation of services defined in the spec (and therefore part of the Avalon-Framework contracts), and other services (both container and peer). At the moment, I don't think any such services exist. Maybe we should come up with some, and *maybe* they should be provided in a separate mechanism to regular services. But since they are part of the spec, components won't need to "declare" the context they require, and things like MailetContext and ServletContext are removed from these arguments, since they aren't part of the Avalon-Framework contracts. This is my take on the matter, anyhow. ciao Daz On Thu, 5 Dec 2002 04:05, Gary Shea wrote: > I've been following this thread with a great deal of interest, since I > have the same questions as Adam has been asking. My experience with > using Avalon is that Context is great until you get someone else's > container involved in the picture. At that point it becomes a minor > nightmare, since each container sees it differently. > > My views are from the perspective of a component writer who wants to > avoid container lock-in. > > I've been willing to adopt the data/services distinction, because the > container I want to use (merlin) does so. But the data/services > paradigm turns Context into either a less-capable Configuration or a > declaratively-driven object builder. The idea of Context as an object > builder feels kind of baroque to me, and I can't imagine that all > containers will do it, so in merlin I don't use Context at all. > > The container-provided/peer-provided view is one I'd be willing to adopt > also. In this view, Context is container-dependent, and is simply > anathema to the component writer who wants to maintain cross-container > portability. That's the extent of my interest. I can see how this > view would be useful to someone building a tightly-coupled > component/container system, but my goal is to avoid that at all costs. > > As you can see, I wouldn't use Context under either of the data/service > or container/peer paradigms. I think that's ok. > > If this discussion had to end today, I'd say Context is a red herring > and should be discarded. It would be replaced with two new stages: > ObjectConfigurable and ContainerServiceable. > > Gary > > [2002-12-04 21:56 +1100] Peter Donald (peter@realityforge.org) wrote: > > On Wed, 4 Dec 2002 11:07, Adam Murdoch wrote: > > > These are useful things, no question. Components need some way to get > > > at data and services that are supplied by the container. Again, why do > > > they care that a particular service or piece of data was supplied by > > > the container or a peer? > > > > Components don't care what the origins of the resource are - all of it is > > potentially "contextualized" on a per component basis and all generally > > has certain criteria to adhere to but beyond that it is about it. The > > different resources are separated out for the sake of humans and no other > > reason. > > > > Context is separated from ServiceManager because humans see them as > > different things - especially during the assembly process. > > > > > Yes, I know that they're "different logical things". But so are, say, > > > authentication services and persistence services. We don't use > > > different mechanisms to deliver those services to components. It would > > > be pointless to do so: > > > > I disagree. If persistence were provided to the component and the > > component was effectively made to be an OJB object or something like that > > then we would likely provide persistence/transaction capabilities in a > > very different manner. Most likely via some transparent EJB-like manner. > > > > In the same way if AAA services were provided to a component as part of > > it's environment then it would likely also follow an EJB/Servlet style > > setup where the container does it via interception and allows components > > to access it programatically via something like > > > > getServletContext().isPrincipleInRole( String role, Principle p ); > > getSessionContext().isCallerInRole( String role ); > > (or insert real examples here or JAAS). > > > > If the services are things that the container provides to the component > > as part of it's environment then the user perceives them as different to > > services that the component uses. I can't think of one API that actually > > merges the two concepts. > > > > When we tried to merge the two things together the primary reason we > > separated them out again was because of user complaints. ie If a > > resources requires resources A, B and C and C is container provided. All > > three are accessed in the same way so the person sees them as much the > > same (like the component sees them as much the same). However during > > assembly they are only required to assemble A and B - which creates a > > cognitive dissonance because they are treated as identical in one place > > but different in another. > > > > > So which of these cases do you think offer the most benefit to the > > > component writer? Assume logger, config, params have been split out > > > already: 1. No separation. > > > 2. Separate data and services. > > > 3. Separate container-provided resources and peer-provided resources. > > > > +1 > > > > > 4. Separate container-provided data, container-provided services, > > > peer-provided data, and peer-provided services. > > > 5. Who cares? Why are you bothering me with these questions? > > > > > :) > > > > -- > > Cheers, > > > > Peter Donald > > *------------------------------------------------* > > > > | Those who know how to think need no teachers. | > > | - Gandhi | > > > > *------------------------------------------------* > > > > > > -- > > To unsubscribe, e-mail: > > <mailto:avalon-dev-unsubscribe@jakarta.apache.org> For additional > > commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org> -- To unsubscribe, e-mail: <mailto:avalon-dev-unsubscribe@jakarta.apache.org> For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>
> From: Stephen McConnell [mailto:mcconnell@apache.org] > > Berin Loritsch wrote: > > >One addendum I want to make clear. > > > >In addition to the text on Incubator's voting page, > >I highly recommend the following stipulation: > > > >***** ALL vetoes MUST be accompanied with a reasonable > >explanation of the grievance AND a counter proposal that > >would remedy the situation. Any veto that fails to > >comply with BOTH of those requirements is invalid. > > > > > > +1 > > >Vetoes referring to code must have a _technical_ reason. > >Vetoes referring to PMC modification of the charter and > >bylaws must have a reasonable political/legal reason. > > > > > > -1 > > No vetos on PMC. > Period. > > It this message getting though ? Calm down. I am not your enemy. Is that message getting through? -- To unsubscribe, e-mail: <mailto:avalon-dev-unsubscribe@jakarta.apache.org> For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>
> From: Stephen McConnell [mailto:mcconnell@apache.org] > > Berin Loritsch wrote: > > >I propose that we follow the voting process outlined > >by Incubator. > > > > It looks good in terms of committer procedures. > A lot of the loose ends are getting cleaned up. > > >It is standard across all the projects > >I have seen. It addresses voting process of the community > >at large, but does not address the voting process of > >the PMC. > > > > Correct. > > > > >I still have yet to see other charters besides the XML > >one, and voting guidelines do not constitute a charter. > >I suggest that changes to the charter and voting guidelines > >be treated as code changes, with the stipulation that only > >PMC votes are binding. > > > > -1 > > NO, NO, NO, NO. > <snip/> > I WILL PUT UP WITH THAT SORT OF RUBBISH AGAIN. > > NOT EVER - NEVER. Calm down. Keep in mind what a valid veto is (in another version of this mail). > >That allows a PMC member to veto > >a change with proper justification. > > > > Incorrect - any justification - feeble, profound, fantasy, etc. and > nothing to fallback on. We have today a majority voting > process. We can > change that thought a majority vote. That's it - there are no other > rules applicable here. Please - just use the structure we > have and don't > imply anything different with a PMC vote. I also don't want to be railroaded again--or did you miss that when you steamrolled the Avalon PMC through? I want the ability to say "Hold on, you need to slow down. There are more things to think through". With mere majority voting, my call to slow down will likely get overrun and then I am left holding the bag and trying to clean up your mess. Again, I assert that a proper veto as I outlined in another mail must be supported. A proper veto is not "I don't like it", that is invalid. A proper veto is accompanied by a reasonable explanation AND a counter-proposal. > >Proper justification > >should also have a counter-proposal so that the rest of > >the PMC knows *how* to rectify the situation. > > Just image for a moment that I really object to something (like your > ideas about voting on the PMC). And lets assume that your model is in > place. And lets assume that you and I disagree on something > similar. And > lets assume that my arguments and your arguments are both > well prepared > and rationale. Your solution creates a deadlock - you have > destroyed the > intrinsic value of the PMC - and that it be able to do things > when such > need arrives. You don't need to look very far back into > Avalon history > to see evidence of this. I'm not ready to bet the form on that not > happening again. > > Today - we have a majority rules on the PMC. Today, we have not voted on any PMC bylaws, and until I started bringing up the subject everyone was quiet. -1 on majority rules. It opens the door to steamrolling through concepts, ideas, etc. that are in favor of certain individuals but not the whole of Avalon. I repeat, I will not be left holding the bag from yours or anyone else's pushing through something before it is completely thought out. Period. I am just as unyielding on this point as you are on unanimous votes. I AM open to two-thirds majority of the PMC with voting open for an entire week. However simple majority doesn't work either. It's too easy to pull the wool over someones eyes for the length of time for a quick vote--and then the community regrets the outcome of the decision. The consequences of PMC resolutions are far greater than code changes, so I want something that will *force* us to work together on a solution we can all live with. I hope I am very clear on the matter. I am in favor of an Avalon PMC, but I am against the manner in which it came into being. I do not want to go through that again. > In the meantime - please not more assertions of what rules > apply - there > are rules already in place. Lets focus on charter - not > procedure - and > drop any discussion about policy to apply with result to charter or > policy evolution. It simple - a majority of the PMC voter to > change the > charter - the change gets escalated to the Board, the board does it > stuff. If that's no ok - then raise a vote on the PMC list. -1 for the reasons stated above. 2/3 majority is acceptable. Again, I am against the way things were steamrolled through to create the Avalon PMC, and I don't want to be subject to that again. > ----------ooo0ooo----------- > > You may sense a certain aggression/frustration here. That is brought > about by the inability of this community to deal with the > problems back > in July/August - it was complicated by the inability of the > Jakarta PMC > to address the issue. Even the board didn't address the issue on the > table at the time. Nobody took a position - not structure in > the entire > Apache organization was willing to step in with a closure. Yes - Pete > got kicked - but that wasn't the subject of the Jakarta/Board > discussion > before - that was probably more of a surprise to me than to > any of you. > What I do know is that those types issues MUST be address by > the Avalon > PMC. If you continue along the lines your describing - your just > creating the comfortable environment where you simply isolate > yourself > away from the potential of having to take a difficult decision. Look, I am able and willing to make very difficult decisions. I have made many more before Avalon was a part of my involvement. Those decisions impacted myself, my family, and other people. I am not afraid of standing for what I believe in. I find it a strength. The important thing is this: I don't want to be held responsible for the rash decisions of others. Simple majority opens the door for that. Mob rule did not work for Greece, and I don't think it will work here. > As a PMC member - I REFUSE to let a similar situation arise for other > members of the community. I will do everything I can to > ensure that the > PMC is an instrument that has balls and ability. And I'm > confident that > providing those attributes are held up with respect - that we > will never > need to use them. Today the PMC has balls - please don't try to take > that away. Its abilities will evolve through attention and > consideration > to the charter and procedures, and progressively, through > respect from a > united community. Also keep in mind that the veto Peter issued you back in August would not have been valid under my proposed definition of veto. -- To unsubscribe, e-mail: <mailto:avalon-dev-unsubscribe@jakarta.apache.org> For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>
> Leo Simons wrote: > > Hi gang, > > > > Gump has an entry for excalibur-containerkit, which I've > just moved to > > the avalon-sandbox cvs. The sourcepath for this entry needs to be > > updated, but even after lots of headscratching I can't > figure out what > > to do; the <home/> and <work/> tags probably both need to > change but > > it's unclear to me to what; and I can't find the <module/> > definitions > > at all! > > > > could someone with more gump knowledge take a peek? > > Stephan Bodewig constructed and committed a correct entry - > before you > even posted this e-mail. That'd give him the amazing time window of roughly 10 mins for becoming aware of the (new) problem, creating the solution, _and_ committing it. Astounding! :D There's some mail hiccups atm, I suspect half is the problem of our uni (re those pictures of lots of smoke in the ICT building), the other half is @ apache, but it's having some weird effects.... > Editorial comment: there are people who are actively trying to build > Avalon related components - if for no other reason than to verify the > correct operation of projects they care about (e.g. Ant) or to identify > things that other subprojects (e.g., james) may need to be aware of at > some point. At times, this requires a little bit of cooperation - to > this day, I still have been unable to locate the correct place to find > and build the org.apache.avalon.framework.info classes. Any hints would > be appreciated. These used to be in jakarta-avalon-excalibur/info, and have just moved to avalon-sandbox/info/. Getting avalon "gumped" completely is #2 on my todo list (#1 is charter/community stuff); this is just one of many points to address IIUC. Note it is hardly appropriate for non-alpha non-avalon materials to reference that code as it's somewhat contentious but that's not the point atm :D > In return, you will have nightly builds that are internally self > consistent - each component that depends on the common framework will be > built with the same version of that framework. > > Who knows, this might even foster a bit more cooperation and > communication within the Avalon project. My thoughts exactly! Me and some others have been rather ignorant of Gump and this'll change soon I hope. My POA: - figure out gump from nitter to gritter (I've got it running locally but ran out of disk space ;) - get all avalon bits building using gump - 'normalize' gump usage in avalon - submit patches to gump docs detailing the things I found out but didn't "get" at first cheers, - Leo -- To unsubscribe, e-mail: <mailto:avalon-dev-unsubscribe@jakarta.apache.org> For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>
> > > [The Incubator voting process] addresses voting > > > process of the community at large, but does not > > > address the voting process of the PMC. > > Why can't ASF Bylaws 5.8 be adapted to server the needs of a PMC? > Sounds good. "Section 5.8. Quorum and Voting. A majority of the number of directors fixed in accordance with these Bylaws shall constitute a quorum for the transaction of business. The vote of a majority of the directors present at a meeting at which a quorum is present shall be the act of the Board of Directors." Am I correct in rewriting this as: "Quorum and Voting. A majority of the number of PMC members shall constitute a quorum for the transaction of business. The vote [on procedural issues] of a majority of the members [during some period within] which a quorum [votes] shall be the act of the PMC." This incorporates the ASF Board voting bylaw, exchanges the meeting for a period (TBD), and clarifies that it addresses procedural issues (as discussed by http://incubator.apache.org/drafts/voting.html). --- Noel -- To unsubscribe, e-mail: <mailto:avalon-dev-unsubscribe@jakarta.apache.org> For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>
Berin Loritsch wrote: >One addendum I want to make clear. > >In addition to the text on Incubator's voting page, >I highly recommend the following stipulation: > >***** ALL vetoes MUST be accompanied with a reasonable >explanation of the grievance AND a counter proposal that >would remedy the situation. Any veto that fails to >comply with BOTH of those requirements is invalid. > > +1 >Vetoes referring to code must have a _technical_ reason. >Vetoes referring to PMC modification of the charter and >bylaws must have a reasonable political/legal reason. > > -1 No vetos on PMC. Period. It this message getting though ? Steve. -- Stephen J. McConnell OSM SARL digital products for a global economy mailto:mcconnell@osm.net http://www.osm.net -- To unsubscribe, e-mail: <mailto:avalon-dev-unsubscribe@jakarta.apache.org> For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>
Berin Loritsch wrote: >I propose that we follow the voting process outlined >by Incubator. > It looks good in terms of committer procedures. A lot of the loose ends are getting cleaned up. >It is standard across all the projects >I have seen. It addresses voting process of the community >at large, but does not address the voting process of >the PMC. > Correct. > >I still have yet to see other charters besides the XML >one, and voting guidelines do not constitute a charter. >I suggest that changes to the charter and voting guidelines >be treated as code changes, with the stipulation that only >PMC votes are binding. > -1 NO, NO, NO, NO. Berin: Please throw out this idea of introducing the potential for deadlock - just get it out of your mind. While I am confident that we will reach a good solution just working on the standing majority rules procedures under the PMC - please don't keep poluting this with notions that set precedence of no-majority opinion. Your comment about treating these subjects as code implicitly introduces the potential for veto - and drag us back to a potential environment of unresolved issues. Maybe you have not had to put up with this - but let me be real clear - if the Avalon PMC procedures introduce anything that have the potential to block a qualified majority (i.e. two-thirds) on what and who we are - and simple majority on the rest of the things we have to deal with - then you, I, and the rest of us have learnt NOTHING from the recent past. I WILL PUT UP WITH THAT SORT OF RUBBISH AGAIN. NOT EVER - NEVER. >That allows a PMC member to veto >a change with proper justification. > Incorrect - any justification - feeble, profound, fantasy, etc. and nothing to fallback on. We have today a majority voting process. We can change that thought a majority vote. That's it - there are no other rules applicable here. Please - just use the structure we have and don't imply anything different with a PMC vote. >Proper justification >should also have a counter-proposal so that the rest of >the PMC knows *how* to rectify the situation. > Just image for a moment that I really object to something (like your ideas about voting on the PMC). And lets assume that your model is in place. And lets assume that you and I disagree on something similar. And lets assume that my arguments and your arguments are both well prepared and rationale. Your solution creates a deadlock - you have destroyed the intrinsic value of the PMC - and that it be able to do things when such need arrives. You don't need to look very far back into Avalon history to see evidence of this. I'm not ready to bet the form on that not happening again. Today - we have a majority rules on the PMC. In the meantime - please not more assertions of what rules apply - there are rules already in place. Lets focus on charter - not procedure - and drop any discussion about policy to apply with result to charter or policy evolution. It simple - a majority of the PMC voter to change the charter - the change gets escalated to the Board, the board does it stuff. If that's no ok - then raise a vote on the PMC list. ----------ooo0ooo----------- You may sense a certain aggression/frustration here. That is brought about by the inability of this community to deal with the problems back in July/August - it was complicated by the inability of the Jakarta PMC to address the issue. Even the board didn't address the issue on the table at the time. Nobody took a position - not structure in the entire Apache organization was willing to step in with a closure. Yes - Pete got kicked - but that wasn't the subject of the Jakarta/Board discussion before - that was probably more of a surprise to me than to any of you. What I do know is that those types issues MUST be address by the Avalon PMC. If you continue along the lines your describing - your just creating the comfortable environment where you simply isolate yourself away from the potential of having to take a difficult decision. As a PMC member - I REFUSE to let a similar situation arise for other members of the community. I will do everything I can to ensure that the PMC is an instrument that has balls and ability. And I'm confident that providing those attributes are held up with respect - that we will never need to use them. Today the PMC has balls - please don't try to take that away. Its abilities will evolve through attention and consideration to the charter and procedures, and progressively, through respect from a united community. Cheers, Steve. -- Stephen J. McConnell OSM SARL digital products for a global economy mailto:mcconnell@osm.net http://www.osm.net -- To unsubscribe, e-mail: <mailto:avalon-dev-unsubscribe@jakarta.apache.org> For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>
> From: Noel J. Bergman [mailto:noel@devtech.com] > > > [The Incubator voting process] addresses voting > > process of the community at large, but does not > > address the voting process of the PMC. > > Why can't ASF Bylaws 5.8 be adapted to server the needs of a PMC? Sounds good. -- To unsubscribe, e-mail: <mailto:avalon-dev-unsubscribe@jakarta.apache.org> For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>
Berin Loritsch wrote:
> One addendum I want to make clear.
>
> In addition to the text on Incubator's voting page,
> I highly recommend the following stipulation:
>
> ***** ALL vetoes MUST be accompanied with a reasonable
> explanation of the grievance AND a counter proposal that
> would remedy the situation. Any veto that fails to
> comply with BOTH of those requirements is invalid.
I was writing the same thing when I got this mail.
+1 (actually +infinite for the counterproposal part)
> Vetoes referring to code must have a _technical_ reason.
> Vetoes referring to PMC modification of the charter and
> bylaws must have a reasonable political/legal reason.
>
>
> If the counter proposal is to leave the original code/
> charter alone, then it needs to be explicitly stated.
>
>
> GOOD EXAMPLES
> -------------
>
> -1 The allowing vetoes of any sort block progress. I
> suggest we remove the ability to veto anything.
>
> -1 The proposed "fix" introduces some serious architectural
> defects (please include a list). I suggest we leave
> the code alone until we find a cure that is not
> worse than the problem.
>
>
> BAD EXAMPLES
> ------------
>
> -1
>
> -1 Vetoes block progress.
>
> -1 Your fix sucks.
>
> The differences between the two should be readily apparent.
> I don't want vetoes to be abused as they have been in the
> past. I also want the responsibility placed on the vetoer
> to provide the suitable explanation as to #1 what the problem
> is, and #2 how it can be resolved in a way that would make
> you happy.
>
> It is the PMC's responsibility to ensure that this is happening,
> but we must be on board with a proposal like this. A binding
> veto must comply with the guidelines set forth above.
>
> I do support the ability to veto, esp. on important things.
> If they are used wisely and judiciously, we can learn more
> than simply railroading something through with majority or
> even 2/3 consensus.
+1
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>
> o One of the problems that has plagued Avalon is the result
> of one-man codebases. I propose we remove almost all of these
> withing the next month. They can be moved to jakarta-commons,
> the incubator or to sourceforge as the developer wishes.
>
> [ no votes yet.
> we need to vote on effective codebases one by one ]
I have asked Peter for clarification of some issues (i.e.
just what "one-man codebases" are affected by this), and
since voting has started I want to register my -1 for
now. Motivation is that
1) The proposal is extremely vague, thus opening the
possibility of later conflicts when a project is
told to leave, and the one-man author objects.
I don't want to go there.
2) I think Avalon-sandbox is a suitable place to have
as an alternative.
3) We need to vote on this on a project-by-project basis.
That said, a proposal with a list of affected projects
and suggestions on where they go (Avalon sandbox or out)
would make me withdraw my -1 and change it to a +1 as
the basic idea is good.
Finally, I consider this proposal to be technical, not
procedural, as it involves the codebase, and thus
requiring concensus (instead of majority).
/LS
--
To unsubscribe, e-mail: <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>
> [The Incubator voting process] addresses voting > process of the community at large, but does not > address the voting process of the PMC. Why can't ASF Bylaws 5.8 be adapted to server the needs of a PMC? --- Noel -- To unsubscribe, e-mail: <mailto:avalon-dev-unsubscribe@jakarta.apache.org> For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>
> -----Original Message----- > From: Berin Loritsch [mailto:bloritsch@citi-us.com] > Sent: den 4 december 2002 18:10 > To: 'Avalon Developers List' > Subject: Avalon voting process > > > I propose that we follow the voting process outlined > by Incubator. It is standard across all the projects > I have seen. It addresses voting process of the community > at large, but does not address the voting process of > the PMC. +1 > I still have yet to see other charters besides the XML > one, and voting guidelines do not constitute a charter. > I suggest that changes to the charter and voting guidelines > be treated as code changes, with the stipulation that only > PMC votes are binding. That allows a PMC member to veto > a change with proper justification. Proper justification > should also have a counter-proposal so that the rest of the > PMC knows *how* to rectify the situation. +1 I sent in a couple of questions and suggestions in: http://marc.theaimsgroup.com/?l=avalon-apps-dev&m=103900145220413&w=2 > Regarding Avalon membership, we should follow the Apache > bylaws Article IV (4). Membership meaning committers, and > PMC. +1, though this in some points conflict with the proposed charter (for example, in the bylaws 2/3 majority is enough to kick someone out, in the charter it is unanimous). > In regards to the definition of Quorum, we should follow > the Apache bylaws Article III (3) Section 3.9. +1 > Are we on board with this? Almost. /LS -- To unsubscribe, e-mail: <mailto:avalon-dev-unsubscribe@jakarta.apache.org> For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>
Nicola Ken Barozzi wrote:
> APACHE AVALON PROJECT STATUS: -*-indented-text-*-
> Last modified at [$Date: 2002/12/04 18:22:58 $]
[...]
I've collected current votes and this seems to be the result so far:
> Pending issues:
[...]
>
> o Creation of an "avalon" CVS repository for new Avalon5
> codebase
> +1: nicolaken, mcconnell
> +0: cziegeler
> -0: proyal
> -1: leosimons, leif
>
> o Mark sandbox code clearly as being sandbox code.
> To do this we could require that components in this place are
> put in the package org.apache.avalon.sandbox.X
> This will make it very clear to users what the status of code
> is and thus they won't be misled into thinking that it is
> anything it is not.
> +1: proyal, leosimons,
> +0:
> -0:
> -1: mcconnell, leosutic, nicolaken, bloritsch
>
> o One of the problems that has plagued Avalon is the result
> of one-man codebases. I propose we remove almost all of these
> withing the next month. They can be moved to jakarta-commons,
> the incubator or to sourceforge as the developer wishes.
>
> [ no votes yet.
> we need to vote on effective codebases one by one ]
>
I would really appreciate if voters could add their names to the CVS
file directly, under the item they are voting on, at least now that many
votes are being done, it would greatly simplify the chore and most
important reduce errors in the counting.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>
One addendum I want to make clear.
In addition to the text on Incubator's voting page,
I highly recommend the following stipulation:
***** ALL vetoes MUST be accompanied with a reasonable
explanation of the grievance AND a counter proposal that
would remedy the situation. Any veto that fails to
comply with BOTH of those requirements is invalid.
Vetoes referring to code must have a _technical_ reason.
Vetoes referring to PMC modification of the charter and
bylaws must have a reasonable political/legal reason.
If the counter proposal is to leave the original code/
charter alone, then it needs to be explicitly stated.
GOOD EXAMPLES
-------------
-1 The allowing vetoes of any sort block progress. I
suggest we remove the ability to veto anything.
-1 The proposed "fix" introduces some serious architectural
defects (please include a list). I suggest we leave
the code alone until we find a cure that is not
worse than the problem.
BAD EXAMPLES
------------
-1
-1 Vetoes block progress.
-1 Your fix sucks.
The differences between the two should be readily apparent.
I don't want vetoes to be abused as they have been in the
past. I also want the responsibility placed on the vetoer
to provide the suitable explanation as to #1 what the problem
is, and #2 how it can be resolved in a way that would make
you happy.
It is the PMC's responsibility to ensure that this is happening,
but we must be on board with a proposal like this. A binding
veto must comply with the guidelines set forth above.
I do support the ability to veto, esp. on important things.
If they are used wisely and judiciously, we can learn more
than simply railroading something through with majority or
even 2/3 consensus.
> From: Berin Loritsch [mailto:bloritsch@citi-us.com]
>
> I propose that we follow the voting process outlined
> by Incubator. It is standard across all the projects
> I have seen. It addresses voting process of the community
> at large, but does not address the voting process of
> the PMC.
>
> I still have yet to see other charters besides the XML
> one, and voting guidelines do not constitute a charter.
> I suggest that changes to the charter and voting guidelines
> be treated as code changes, with the stipulation that only
> PMC votes are binding. That allows a PMC member to veto
> a change with proper justification. Proper justification
> should also have a counter-proposal so that the rest of
> the PMC knows *how* to rectify the situation.
>
> Regarding Avalon membership, we should follow the Apache
> bylaws Article IV (4). Membership meaning committers, and
> PMC.
>
> In regards to the definition of Quorum, we should follow
> the Apache bylaws Article III (3) Section 3.9.
>
>
> Are we on board with this?
>
--
To unsubscribe, e-mail: <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>
APACHE AVALON PROJECT STATUS: -*-indented-text-*-
Last modified at [$Date: 2002/12/04 18:22:58 $]
Background:
Apache Avalon is a project started at java.apache.org.
It later became an Apache Jakarta subproject.
It has recently been declared a new top-level project with
its own PMC.
See the bottom of this file for the official resolution/
charter-as-it-stands. See the project website for other information.
Release:
o none scheduled ATM; still defining new container plan and
how to best keep development of current code go ahead
without impacting negatively on the new work.
o past releases available from
http://jakarta.apache.org/builds/jakarta-avalon/
o nightlies available from
http://cvs.apache.org/builds/jakarta-avalon/nightly/
Resolved Issues:
o previously released software needs to be supported,
including but not limited to the avalon framework, avalon
excalibur and avalon phoenix
o existing avalon users must be supported, including but not limited
to the XML Cocoon and Jakarta JAMES communities
o we want to strive for as much consensus on future developments as
possible taking into account the above points
o There is an Avalon repository called avalon-sandbox to contain
all non-released code. It has its own site to make less confusion
with released products.
o Use a unified avalon-dev mailing list
(and avalon-user remains separate)
Pending issues:
o Coming up with a set of bylaws for the project
o Define the terms for serving as a Chair
o deciding on moving or not moving to avalon.apache.org
o discussing and writing medium-to-long term roadmap
regarding containers and possible avalon framework extension
based on consensus development
o discussing and writing short-to-medium term roadmap regarding
unused and/or unmaintained and/or alpha-stage software
packages in current CVSes
o discussing and writing short-to-medium term roadmap
regarding possible relocation of software packages that
could have a better home at another avalon project
o wrap up discussion on licensing headers in sourcefiles
o Existing committers can start new projects without a
detour to the Incubator by using the avalon-sandbox, and
must meet the (TBD) goals of Apache Avalon.
These new components must be approved by the PMC before
being accepted in the endorsed repositories, and must meet the
(TBD) goals of Apache Avalon.
+1: nicolaken
o Voting will follow the "standard Apache voting guidelines"
[ be nice to refer to an Incubator doc here ]
o All code donations [to the ASF, destined for Apache Avalon]
arrive via the Incubator, unless the Incubator states they can
be placed directly into Avalon.
o Creation of an "avalon" CVS repository for new Avalon5
codebase
+1: nicolaken, mcconnell
+0: cziegeler
-0: proyal
-1: leosimons, leif
o Mark sandbox code clearly as being sandbox code.
To do this we could require that components in this place are
put in the package org.apache.avalon.sandbox.X
This will make it very clear to users what the status of code
is and thus they won't be misled into thinking that it is
anything it is not.
+1: proyal, leosimons,
+0:
-0:
-1: mcconnell, leosutic, nicolaken, bloritsch
o One of the problems that has plagued Avalon is the result
of one-man codebases. I propose we remove almost all of these
withing the next month. They can be moved to jakarta-commons,
the incubator or to sourceforge as the developer wishes.
[ no votes yet.
we need to vote on effective codebases one by one ]
Project Mission:
What is the project's mission? Our statement of goals/mission/vision
could arise also from the answers to the following and other questions:
- Should we have a minimum set of requirements before components
are released?
+0: nicolaken
- If yes to above then which things should be part of minimum
requirements?
documentation: require basic overview and user docs
+0: nicolaken
uptodate website: require website be updated to latest release
but may still host previous release docs.
+0: nicolaken
unit tests: (okay so this will never get consensus but ...)
+0: nicolaken
versioning standard: derived from
http://apr.apache.org/versioning.html
http://jakarta.apache.org/commons/versioning.html
+0: nicolaken
release process: derived from
http://jakarta.apache.org/commons/releases.html
http://jakarta.apache.org/turbine/maven/development/release-process.html
http://cvs.apache.org/viewcvs.cgi/jakarta-ant/ReleaseInstructions?rev=1.9.2.1&content-type=text/vnd.viewcvs-markup
+0 nicolaken
deprecation process: (java specific?)
http://jakarta.apache.org/turbine/maven/development/deprecation.html
+0: nicolaken
CVS/Subversion branching:
http://jakarta.apache.org/turbine/maven/development/branches.html
+0: nicolaken
Assets:
Mailing lists: avalon-user@jakarta.apache.org
avalon-dev@jakarta.apache.org
avalon-cvs@jakarta.apache.org
Web site: http://jakarta.apache.org/avalon/
Repositories: jakarta-avalon (framework)
jakarta-avalon-testlet (deprecated testlet)
jakarta-avalon-logkit (logkit)
jakarta-avalon-phoenix (phoenix)
jakarta-avalon-cornerstone (components)
jakarta-avalon-apps (sample phoenix
applications)
jakarta-avalon-excalibur (everything else)
avalon-sandbox (sandbox)
jakarta-avalon-site (the web site)
PMC Members:
Berin Loritsch
Marcus Crafter
Carsten Ziegeler
Jeff Turner
Leo Sutic
Leo Simons
Stephen McConnell
Nicola Ken Barozzi
Paul Hammant
Peter Royal
Note: Nicola Ken Barozzi is the Chair.
PMC Members, pending Board approval:
none yet
[ this may become obsolete; the Board is discussing a way for the
Chair to directly alter the PMC membership; until then, however,
we need PMC members ratified by the board, and this tracks them ]
Active Committers:
bloritsch,colus,cziegeler,hammant,jefft,leif,leosimons,leosutic,
mirceatoma,mcconnell,nicolaken,proyal,vinayc
Inactive Committers (three months without commits):
charlesb,ramc,neeme,giacomo,rana_b,froehlich,lmccay,jrudd,morpheus,
crafterm,huw,ymikulski,mschier,stefano
Emeritus Committers (six months without commits):
jon,fede
Invited Committers:
none yet
Current mission/charter as approved by the board:
RESOLVED, that the initial Avalon PMC be and hereby is tasked
with the creation of a set of bylaws intended to encourage open
development and increased participation in the Avalon Project;
and be it further
RESOLVED, that the initial Avalon PMC be and hereby is tasked
with the migration and rationalization of the Jakarta PMC
Avalon subproject; and be it further
The complete text of the resolution that passed on Monday 18 November 2002
which created this project is:
WHEREAS, the Board of Directors deems it to be in
the best interests of the Foundation and consistent with
the Foundation's purpose to establish a Project Management
Committee charged with the creation and maintenance of
open-source software related to component and service
management, for distribution at no charge to the public.
NOW, THEREFORE, BE IT RESOLVED, that a Project Management
Committee (PMC), to be known as the "Avalon PMC", be and
hereby is established pursuant to Bylaws of the Foundation;
and be it further
RESOLVED, that the Avalon PMC be and hereby is responsible
for the creation and maintenance of software related to
component and service management, based on software licensed
to the Foundation; and be it further
RESOLVED, that the office of "Vice President, Avalon" be and
hereby is created, the person holding such office to serve
at the direction of the Board of Directors as the chair of the
Avalon PMC, and to have primary responsibility for management
of the projects within the scope of responsibility of the
Avalon PMC; and be it further
RESOLVED, that the persons listed immediately below be and hereby
are appointed to serve as the initial members of the Avalon PMC:
* Nicola Ken Barozzi
* Stephen McConnell
* Leo Sutic
* Leo Simons
* Paul Hammant
* Marcus Crafter
* Carsten Ziegeler
* Pete Royal
* Berin Loritsch
* Jeff Turner
NOW, THEREFORE, BE IT FURTHER RESOLVED, that Nicola Ken Barozzi
be and hereby is appointed to the office of Vice President, Avalon,
to serve in accordance with and subject to the direction of the
Board of Directors and the Bylaws of the Foundation until death,
resignation, retirement, removal or disqualification, or until a
successor is appointed; and be it further
RESOLVED, that the initial Avalon PMC be and hereby is tasked
with the creation of a set of bylaws intended to encourage open
development and increased participation in the Avalon Project;
and be it further
RESOLVED, that the initial Avalon PMC be and hereby is tasked
with the migration and rationalization of the Jakarta PMC
Avalon subproject; and be it further
RESOLVED, that all responsibility pertaining to the Jakarta
Avalon sub-project and encumbered upon the Jakarta PMC are
hereafter discharged.
#
# Local Variables:
# mode: indented-text
# tab-width: 4
# indent-tabs-mode: nil
# tab-stop-list: (4 6 8 12 16 20 24 28 32 36 40 44 48 52 56 60 64 68 72
76 80)
# End:
#
--
To unsubscribe, e-mail: <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>
I've been following this thread with a great deal of interest, since I
have the same questions as Adam has been asking. My experience with
using Avalon is that Context is great until you get someone else's
container involved in the picture. At that point it becomes a minor
nightmare, since each container sees it differently.
My views are from the perspective of a component writer who wants to
avoid container lock-in.
I've been willing to adopt the data/services distinction, because the
container I want to use (merlin) does so. But the data/services
paradigm turns Context into either a less-capable Configuration or a
declaratively-driven object builder. The idea of Context as an object
builder feels kind of baroque to me, and I can't imagine that all
containers will do it, so in merlin I don't use Context at all.
The container-provided/peer-provided view is one I'd be willing to adopt
also. In this view, Context is container-dependent, and is simply
anathema to the component writer who wants to maintain cross-container
portability. That's the extent of my interest. I can see how this
view would be useful to someone building a tightly-coupled
component/container system, but my goal is to avoid that at all costs.
As you can see, I wouldn't use Context under either of the data/service
or container/peer paradigms. I think that's ok.
If this discussion had to end today, I'd say Context is a red herring
and should be discarded. It would be replaced with two new stages:
ObjectConfigurable and ContainerServiceable.
Gary
[2002-12-04 21:56 +1100] Peter Donald (peter@realityforge.org) wrote:
> On Wed, 4 Dec 2002 11:07, Adam Murdoch wrote:
> > These are useful things, no question. Components need some way to get at
> > data and services that are supplied by the container. Again, why do they
> > care that a particular service or piece of data was supplied by the
> > container or a peer?
>
> Components don't care what the origins of the resource are - all of it is
> potentially "contextualized" on a per component basis and all generally has
> certain criteria to adhere to but beyond that it is about it. The different
> resources are separated out for the sake of humans and no other reason.
>
> Context is separated from ServiceManager because humans see them as different
> things - especially during the assembly process.
>
>
>
> > Yes, I know that they're "different logical things". But so are, say,
> > authentication services and persistence services. We don't use different
> > mechanisms to deliver those services to components. It would be pointless
> > to do so:
>
> I disagree. If persistence were provided to the component and the component
> was effectively made to be an OJB object or something like that then we would
> likely provide persistence/transaction capabilities in a very different
> manner. Most likely via some transparent EJB-like manner.
>
> In the same way if AAA services were provided to a component as part of it's
> environment then it would likely also follow an EJB/Servlet style setup where
> the container does it via interception and allows components to access it
> programatically via something like
>
> getServletContext().isPrincipleInRole( String role, Principle p );
> getSessionContext().isCallerInRole( String role );
> (or insert real examples here or JAAS).
>
> If the services are things that the container provides to the component as
> part of it's environment then the user perceives them as different to
> services that the component uses. I can't think of one API that actually
> merges the two concepts.
>
> When we tried to merge the two things together the primary reason we separated
> them out again was because of user complaints. ie If a resources requires
> resources A, B and C and C is container provided. All three are accessed in
> the same way so the person sees them as much the same (like the component
> sees them as much the same). However during assembly they are only required
> to assemble A and B - which creates a cognitive dissonance because they are
> treated as identical in one place but different in another.
>
> > So which of these cases do you think offer the most benefit to the
> > component writer? Assume logger, config, params have been split out
> > already: 1. No separation.
> > 2. Separate data and services.
> > 3. Separate container-provided resources and peer-provided resources.
>
> +1
>
> > 4. Separate container-provided data, container-provided services,
> > peer-provided data, and peer-provided services.
> > 5. Who cares? Why are you bothering me with these questions?
>
> :)
>
> --
> Cheers,
>
> Peter Donald
> *------------------------------------------------*
> | Those who know how to think need no teachers. |
> | - Gandhi |
> *------------------------------------------------*
>
>
> --
> To unsubscribe, e-mail: <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>
>
>
>
--
To unsubscribe, e-mail: <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>
Noel J. Bergman wrote: >>And thereby grant the right to a single individual to block progress. >>That takes away the ability of the PMC to function. >> >> > >Please see http://incubator.apache.org/drafts/voting.html and check with Sam >Ruby. The draft document currently states: "votes on procedural issues >follow the common format of majority rule unless otherwise stated." See >also ASF Bylaw 5.8: Quorum and Voting. If that rule applies to the ASF >Board, why should the PMC voting policy be any different? > >I reiterate my earlier suggestion that the PMC Charter draw upon and >incorporate by reference existing ASF policy documents. > > YES, YES, YES, YES, YES.... Thank you Noel! > --- Noel > > >-- >To unsubscribe, e-mail: <mailto:avalon-dev-unsubscribe@jakarta.apache.org> >For additional commands, e-mail: <mailto:avalon-dev-help@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: <mailto:avalon-dev-unsubscribe@jakarta.apache.org> For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>
I propose that we follow the voting process outlined by Incubator. It is standard across all the projects I have seen. It addresses voting process of the community at large, but does not address the voting process of the PMC. I still have yet to see other charters besides the XML one, and voting guidelines do not constitute a charter. I suggest that changes to the charter and voting guidelines be treated as code changes, with the stipulation that only PMC votes are binding. That allows a PMC member to veto a change with proper justification. Proper justification should also have a counter-proposal so that the rest of the PMC knows *how* to rectify the situation. Regarding Avalon membership, we should follow the Apache bylaws Article IV (4). Membership meaning committers, and PMC. In regards to the definition of Quorum, we should follow the Apache bylaws Article III (3) Section 3.9. Are we on board with this? -- To unsubscribe, e-mail: <mailto:avalon-dev-unsubscribe@jakarta.apache.org> For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>
Berin Loritsch wrote: >>From: Leo Simons [mailto:leosimons@apache.org] >> >>I'll throw the same link at you I got from Steve: >> >>http://marc.theaimsgroup.com/?t=103789608600004&r=1&w=2 >> >>essentially the descriptors were moved to avalon from >>alexandria and we >>did a lousy job maintaining them, so they were moved back. If you want >>access to the descriptors all you have to do is ask :D > > There was no real education either. What does the thing look like? > How to edit it? that sort of thing. I'll let you in on a secret, if you promise not to tell. :-P Go to any gump generated page and click on the bench icon thingie on the top right corner. Cool links to click on from there are the "Source", "Usage", and pretty much any of the "Data Definitions" ones. Just between us, of course. - Sam Ruby -- To unsubscribe, e-mail: <mailto:avalon-dev-unsubscribe@jakarta.apache.org> For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>
Leo Simons wrote: > I'll throw the same link at you I got from Steve: > > http://marc.theaimsgroup.com/?t=103789608600004&r=1&w=2 > > essentially the descriptors were moved to avalon from alexandria and we > did a lousy job maintaining them, so they were moved back. If you want > access to the descriptors all you have to do is ask :D +1 If descriptors exist in local cvses that are better maintained than the ones in the alexandria's cvs, then they will simply be pointed to. If existing committers want to access to the descriptors in alexandria's cvs, all one needs to do is demonstrate an ability to execute a simple build.xml which only depends on Ant, Xerces, and Xalan. I seriously doubt that this is beyond the reach of most of the readers of this e-mail. - Sam Ruby -- To unsubscribe, e-mail: <mailto:avalon-dev-unsubscribe@jakarta.apache.org> For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>
> From: news [mailto:news@main.gmane.org]On Behalf Of Sam Ruby > Editorial comment: there are people who are actively trying to build > Avalon related components - if for no other reason than to verify the > correct operation of projects they care about (e.g. Ant) or > to identify > things that other subprojects (e.g., james) may need to be > aware of at > some point. At times, this requires a little bit of cooperation - to > this day, I still have been unable to locate the correct > place to find > and build the org.apache.avalon.framework.info classes. Any > hints would > be appreciated. :/ Unfortunately, that was someone's planned library for future inclusion. It is not voted upon, and not released yet. It was being developed in Excalibur (info?) > In return, you will have nightly builds that are internally self > consistent - each component that depends on the common > framework will be > built with the same version of that framework. > > Who knows, this might even foster a bit more cooperation and > communication within the Avalon project. :) -- To unsubscribe, e-mail: <mailto:avalon-dev-unsubscribe@jakarta.apache.org> For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>
On Wed, 04 Dec 2002, Sam Ruby <rubys@apache.org> wrote: > Stephan Bodewig constructed and committed a correct entry - before > you even posted this e-mail. No, we seem to have some mail-server hickups ATM. I've seen a response by Nicola Ken to a mail by Leo - but not that original mail so far. Without Leo's mail I wouldn't have known about the move. > to this day, I still have been unable to locate the correct place to > find and build the org.apache.avalon.framework.info classes. Any > hints would be appreciated. ++++1 Stefan -- To unsubscribe, e-mail: <mailto:avalon-dev-unsubscribe@jakarta.apache.org> For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>
> And thereby grant the right to a single individual to block progress. > That takes away the ability of the PMC to function. Please see http://incubator.apache.org/drafts/voting.html and check with Sam Ruby. The draft document currently states: "votes on procedural issues follow the common format of majority rule unless otherwise stated." See also ASF Bylaw 5.8: Quorum and Voting. If that rule applies to the ASF Board, why should the PMC voting policy be any different? I reiterate my earlier suggestion that the PMC Charter draw upon and incorporate by reference existing ASF policy documents. --- Noel -- To unsubscribe, e-mail: <mailto:avalon-dev-unsubscribe@jakarta.apache.org> For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>
> How can you vote on something unless you see it in action. Do you not understand that perfection is not required for committing code? What is important is a Community Consensus that it appears to be the right thing to do at the time. Were one to take your statement literally, you couldn't commit any code until it had been evaluated through a sandbox. > Separate trees only become a problem when there is > chest thumpers and code ownership galore. There is an old Irish saying: begin as you intend to go on. I don't think that it is a good practice to start with competing branches vying for popularity. That is not a unified community. > A little story [...] Your story is quite similar to the one that you told me about Phoenix and Merlin. Except, of course, that those two remain forked. However, I do thank you for understanding why the "urn:" prefix is important, since if a future need arose to support JNDI strings, e.g., to integrate JINI components directly, the string passed could be "jndi:" prefixed and the API for the lookup need not be changed. > At no stage did we have any problems with the different proposals. Selective examples. If this weren't a problem here, we wouldn't be having this discussion. --- Noel -- To unsubscribe, e-mail: <mailto:avalon-dev-unsubscribe@jakarta.apache.org> For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>
I think it makes much more sense to have the gump descriptor locally in avalon-sandbox. All of the stuff I've been working on in excalibur was actively maintained until it wass pulled of the excalibur site. Putting it on avalon-sandbox makes it so much easier to maintain. Cheers, Steve. Leo Simons wrote: >I'll throw the same link at you I got from Steve: > >http://marc.theaimsgroup.com/?t=103789608600004&r=1&w=2 > >essentially the descriptors were moved to avalon from alexandria and we >did a lousy job maintaining them, so they were moved back. If you want >access to the descriptors all you have to do is ask :D > >the only thing in sandbox referenced by gump atm is containerkit. The >rest can change as often as it wants without gump noticing. > >cheers, > >- Leo > >On Wed, 2002-12-04 at 16:54, Berin Loritsch wrote: > > >>Include GUMP descriptor in Avalon-Sandbox. It is reasonable >>to assume that the sandbox area will change more often than >>the Alexandria folks can keep up with. The released stuff >>should remain fairly static in its dependencies so if the >>Alexandria folks want to keep up control of it let them. >> >> > > >-- >To unsubscribe, e-mail: <mailto:avalon-dev-unsubscribe@jakarta.apache.org> >For additional commands, e-mail: <mailto:avalon-dev-help@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: <mailto:avalon-dev-unsubscribe@jakarta.apache.org> For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>
Leo Simons wrote: > Hi gang, > > Gump has an entry for excalibur-containerkit, which I've just moved to > the avalon-sandbox cvs. The sourcepath for this entry needs to be > updated, but even after lots of headscratching I can't figure out what > to do; the <home/> and <work/> tags probably both need to change but > it's unclear to me to what; and I can't find the <module/> definitions > at all! > > could someone with more gump knowledge take a peek? Stephan Bodewig constructed and committed a correct entry - before you even posted this e-mail. http://cvs.apache.org/viewcvs/jakarta-alexandria/proposal/gump/project/avalon-sandbox.xml Editorial comment: there are people who are actively trying to build Avalon related components - if for no other reason than to verify the correct operation of projects they care about (e.g. Ant) or to identify things that other subprojects (e.g., james) may need to be aware of at some point. At times, this requires a little bit of cooperation - to this day, I still have been unable to locate the correct place to find and build the org.apache.avalon.framework.info classes. Any hints would be appreciated. In return, you will have nightly builds that are internally self consistent - each component that depends on the common framework will be built with the same version of that framework. Who knows, this might even foster a bit more cooperation and communication within the Avalon project. Just my 2 cents. - Sam Ruby -- To unsubscribe, e-mail: <mailto:avalon-dev-unsubscribe@jakarta.apache.org> For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>
> From: Leo Simons [mailto:leosimons@apache.org] > > I'll throw the same link at you I got from Steve: > > http://marc.theaimsgroup.com/?t=103789608600004&r=1&w=2 > > essentially the descriptors were moved to avalon from > alexandria and we > did a lousy job maintaining them, so they were moved back. If you want > access to the descriptors all you have to do is ask :D There was no real education either. What does the thing look like? How to edit it? that sort of thing. > the only thing in sandbox referenced by gump atm is containerkit. The > rest can change as often as it wants without gump noticing. All our code needs to be continuously integrated. If a sanbox project depends on outside code, we need to know about changes. -- To unsubscribe, e-mail: <mailto:avalon-dev-unsubscribe@jakarta.apache.org> For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>
Berin Loritsch wrote: > > Steve, your fears are duly noted. Keep in mind that it is the PMC that > must be unanimous--not the general committer populus. > > I am sure that people who have a proven track record of being able to > work with others can come to agreement. I am also sure that unanimous > has to work any time there is a legal issue at stake. Remember PMC > does not make technical decisions so there is unlikely to be an undue > amount of blocking--and never for frivolent reasons. > > PMC is responsible to oversee the legal aspects of this community. Two points: 1) If a PMC gets to the point of being deadlocked to the point where it is no longer functional, it will simply be disolved. Conceivably, at that point, proposals for a new PMC may be entertained by the board. 2) Code commits, arguably the most technical aspect of *any* project, are to be done in accordance to a "consensus based development process". - Sam Ruby -- To unsubscribe, e-mail: <mailto:avalon-dev-unsubscribe@jakarta.apache.org> For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>
I'll throw the same link at you I got from Steve: http://marc.theaimsgroup.com/?t=103789608600004&r=1&w=2 essentially the descriptors were moved to avalon from alexandria and we did a lousy job maintaining them, so they were moved back. If you want access to the descriptors all you have to do is ask :D the only thing in sandbox referenced by gump atm is containerkit. The rest can change as often as it wants without gump noticing. cheers, - Leo On Wed, 2002-12-04 at 16:54, Berin Loritsch wrote: > Include GUMP descriptor in Avalon-Sandbox. It is reasonable > to assume that the sandbox area will change more often than > the Alexandria folks can keep up with. The released stuff > should remain fairly static in its dependencies so if the > Alexandria folks want to keep up control of it let them. -- To unsubscribe, e-mail: <mailto:avalon-dev-unsubscribe@jakarta.apache.org> For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>
Leo Simons wrote:
> aha: the name attribute for <module> corresponds to the name of the cvs
> module! du-uh :D
There is a tentative GUI editor for the Gump descriptor in the
Alexandria-Gump repo, under /editor in the gump proposal dir.
> thanks!
>
> - Leo
>
> On Wed, 2002-12-04 at 16:41, Stefan Bodewig wrote:
>
>>On 04 Dec 2002, Leo Simons <leosimons@apache.org> wrote:
>>
>>
>>>Just can't figure out what file to change into what.
>>
>>I've added a new file avalon-sandbox.xml with a module for
>>avalon-sandbox (those file vaguely correspond to CVS modules and as
>>there hasn't been obe for avalon-sandbox, you need a new one).
>>
>>I moved the excalibur-containerkit <project> to the new file and added
>>the new file to the project.
>>
>>See it in action with the next Gump build.
>
>
>
> --
> To unsubscribe, e-mail: <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>
>
>
>
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>
Why not just put it in avalon-sandbox? --- Noel -- To unsubscribe, e-mail: <mailto:avalon-dev-unsubscribe@jakarta.apache.org> For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>
On Wed, 4 Dec 2002, Berin Loritsch <bloritsch@citi-us.com> wrote: > Include GUMP descriptor in Avalon-Sandbox. It is reasonable > to assume that the sandbox area will change more often than > the Alexandria folks can keep up with. Feel free to add <http://cvs.apache.org/viewcvs.cgi/jakarta-alexandria/proposal/gump/project/avalon-sandbox.xml> to avalon-sandbox and tell me where you've put it. Stefan -- To unsubscribe, e-mail: <mailto:avalon-dev-unsubscribe@jakarta.apache.org> For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>