-------- Original Message -------- Subject: Re: Fwd: Re: Naming issues Date: Tue, 22 Oct 2002 14:12:40 +0200
Peter Donald wrote:
> Nicola Ken Barozzi wrote:
>
>> Peter Donald wrote:
>>
>>>It is still a part of a project. Just like Extension, IO, CLI, Logkit
>>>etc. You won't find Berin or anyone who is respected in Avalon land
>>>trying to block stuff they don't particpate on except for released
>>>components that break backwards compatability.
>>
>>In my knowledge, I repeat in *my* knowledge, this applies only to
>>Avalon, at least this strongly.
>>
>>Stefano vetos things in Cocoon that he has never worked on, but still
>>his vetos have effect, and they are followed, discussed, etc.
>
> Thats because it is a single product. Compare this to jakarta commons > which is effectively what Avalon is like.
Yup. I tended to regard Avalon as Cocoon, so you see that I was thinking in a completely different way.
>> As I told you, I wasn't aware of this unwritten Avalon bylaw, which >> now I /somewhat/ agree with in spirit, but that I have never seen >> in action. > > Which is precisely the point. People just did it because they > respected each other.
It had nothing to do with respect. You know I respect you, it has *never* been a matter of disrespect.
>>>>You know, if Phoenix would have been really separate, probably this >>>>discussion wouldn't even have started. >>> >>>I think this possibility is becoming less and less attractive as time >>>progresses. >> >>Why? >>You would be more indipendent since I would not ask to be a committer >>there, and you would still be a committer on the framework. > > Because over time the notion of container will be refined > significantly enough > that there will never be any need for separate container projects.
Ah, ok, probably... but it's years this wants to happen and it has yet to become... dunno, I like both options.
>>>> Also, I would like to know how you would write the rules to manage >>>> the split of privileges... >>> >>>Members get commit access to everything (presumably they can >>>be trusted). >>>PMC get commit access to everything (presumably they can be trusted). >>>Anyone who is doing infrastructure work get commit access >>>to everything >>>(ala build systems like Paul does in Avalon) >>> >>>People get vote privlidges and commit access when their peers >>>nominate them >>> >>>If we end up with an uber CVS then Apaches infrastructure is not >>>capable >>>of fine grain access control. ie I can not get access to >>>jakarta-avalon-excalibur/io and be blocked from access to >>>jakarta-avalon-excalibur/cli >>>So until that can be fixed nomination to io will mean access to >>>cli but no voting rights on cli. >> >>Ah, ok, now I see it better. >>I agree on the concept, but see the solution more as projects >>being more >>flat -> more granular -> the privileges will be in line automatically. >> >>I'm not sure that having more granular access privileges inside a >>project (given that these are flattened projects) will have benefits. >> >>Or will it... your example of excalibur is interesting; in my proposal >>it would be that all excalibur projects become separate, but it's >>*highly* impractical. >> >>So yes, i start to see a pattern... >> >>Would you mind if we share this with the list? > > go for it.
--
Nicola Ken Barozzi [EMAIL PROTECTED]
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------