You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Paul Hammant <Pa...@yahoo.com> on 2002/02/19 09:27:05 UTC
Adding a committer : Catch-22
Folks,
I am trying to add a committer to commons-sandbox/altrmi. The fellow in
question is heavily involved with "Enterprise Object Broker" hosted at
sourceforge which uses AltRMI.
The commons charter, at present, does not allow for a person to be added
who is not currently a jakarta-* committer.
I need advise, because it seems to be this is insolvable.
- Paul
Re: Adding a committer : Catch-22
Posted by Morgan Delagrange <md...@yahoo.com>.
----- Original Message -----
From: "Geir Magnusson Jr." <ge...@optonline.net>
To: <co...@jakarta.apache.org>
Sent: Tuesday, February 19, 2002 11:08 AM
Subject: Re: Adding a committer : Catch-22
On 2/19/02 12:00 PM, "Ted Husted" <hu...@apache.org> wrote:
> Paul,
>
> Any time you want to propose AltRMI to the Commons, you have my vote,
> even if you were the only Committer listed on the proposal. You know
> what's what, and I trust that AltRMI will develop a good following over
> time.
Agreed. It already is, and that¹s the issue here.
However, I would appreciate if you don't just try to ram this through but
actually have a discussion about the issue.
>
> The whole idea behind the Commons committers having karma to every
> package was so that we would not need to have three active committers.
Not sure if that is true.
> I'm not going to get into a discussion about that, but wanted to let you
> know how I would cast my own vote.
--
Geir Magnusson Jr. geirm@optonline.net
System and Software Consulting
The bytecodes are language independent. - Sam Ruby
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
Re: Adding a committer : Catch-22
Posted by Morgan Delagrange <md...@yahoo.com>.
Hey gang,
My personal view is that I'm willing to consider anyone as a committer to
the Commons on their merits, regardless of whether or not their particular
interests lie in the Sandbox. AFAIK Vinay has made six posts to the commons
list over the last 20 days, including several patches:
http://marc.theaimsgroup.com/?l=jakarta-commons-dev&w=2&r=1&s=vinaysahil+cha
ndran&q=a
(This is assuming that my search criteria were accurate. I don't keep
copies of all the email I receive.) Although I'm not in a good position to
judge the quality of these contributions, the quantity and span of
involvement is a little lower than I would ordinarily support. So I'm
currently at a -0 vote, but I'm willing to be convinced. This is regardless
of whether or not altRMI is in the sandbox or the Commons Proper.
IMO accepting new Committers to Commons in support of sandbox projects could
be _slightly_ discouraged. After all, if the project doesn't take off (look
in the current sandbox for examples), you end up with a brand new Committer
who has no projects (not optimal). We have to account for the volatility of
Sandbox projects in our decisions. If there is significant non-Committer
interest in a project, it should be strongly considered for promotion to the
Commons Proper.
By that token, I would also +1 a proposal to move altRMI to the Commons
Proper. Looks promising.
- Morgan
P.S. If we're going to start using this commons-process mailing list, then
someone who supports the idea really should post a link on
http://jakarta.apache.org/site/mail2.html. If not, we should nix it.
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
Re: Adding a committer : Catch-22
Posted by Daniel Rall <dl...@finemaltcoding.com>.
"Geir Magnusson Jr." <ge...@optonline.net> writes:
> - make a break from the jakarta guidelines and allow new code with fewer
> than 3 serious committers under the justification that there are more than
> enough committers waiting, which I don't think is valid as there is no
> reason to believe than people will naturally work on things just 'because'.
> I would vote against this.
As would I. Time and again, I have seen this proven to be a bad idea.
Re: Adding a committer : Catch-22
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On 2/19/02 12:45 PM, "Paul Hammant" <Pa...@yahoo.com> wrote:
> Geir, Ted,
>
>>> Any time you want to propose AltRMI to the Commons, you have my vote,
>>> even if you were the only Committer listed on the proposal. You know
>>> what's what, and I trust that AltRMI will develop a good following over
>>> time.
>>>
>>
>> Agreed. It already is, and that¹s the issue here.
>>
>
> Thank you both for your votes of confidence. Though I am good at
> solutions, there are many better than me at separation and modular
> design. Most particularly in AltRMI I think my class naming sucks!
>
>> However, I would appreciate if you don't just try to ram this through but
>> actually have a discussion about the issue.
>>
> I had no intention :-) I think if I am to stay at commons then I should
> go by the book. A month ago I tried to move it from sandbox to proper
> and could have forced that too, but felt it was wrong. I too think
> something smells about the policy. Specifically voting, but now also
> joiners from outside. The combination of these for me is plain catch-22
> (anti)pattern.
I'm sorry - That was directed towards Ted. You have been more than patient
with our weird rules in commons, and like I noted before, you have been
doing the 'right thing', in my opinion anyway.
I too think this is a good chance to get this straightened out. Either we :
- make a break from the jakarta guidelines and allow new code with fewer
than 3 serious committers under the justification that there are more than
enough committers waiting, which I don't think is valid as there is no
reason to believe than people will naturally work on things just 'because'.
I would vote against this.
- we acknowledge that this is an important criterion for ensuring the health
of projects (even subproject subprojects like compoenents). I would vote for
this.
Additionally, we should find a solution to your problem with your proposed
committer.
I am hoping others join this conversation.
--
Geir Magnusson Jr. geirm@optonline.net
System and Software Consulting
"He who throws mud only loses ground." - Fat Albert
Re: Adding a committer : Catch-22
Posted by Paul Hammant <Pa...@yahoo.com>.
Geir, Ted,
>>Any time you want to propose AltRMI to the Commons, you have my vote,
>>even if you were the only Committer listed on the proposal. You know
>>what's what, and I trust that AltRMI will develop a good following over
>>time.
>>
>
>Agreed. It already is, and that¹s the issue here.
>
Thank you both for your votes of confidence. Though I am good at
solutions, there are many better than me at separation and modular
design. Most particularly in AltRMI I think my class naming sucks!
>However, I would appreciate if you don't just try to ram this through but
>actually have a discussion about the issue.
>
I had no intention :-) I think if I am to stay at commons then I should
go by the book. A month ago I tried to move it from sandbox to proper
and could have forced that too, but felt it was wrong. I too think
something smells about the policy. Specifically voting, but now also
joiners from outside. The combination of these for me is plain catch-22
(anti)pattern.
>>The whole idea behind the Commons committers having karma to every
>>package was so that we would not need to have three active committers.
>>
>
>Not sure if that is true.
>
>
>>I'm not going to get into a discussion about that, but wanted to let you
>>know how I would cast my own vote.
>>
Thanks Ted.
Lastly, I am not sure how many people are listening to this conversation.!
- Paul
Re: Adding a committer : Catch-22
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On 2/19/02 12:00 PM, "Ted Husted" <hu...@apache.org> wrote:
> Paul,
>
> Any time you want to propose AltRMI to the Commons, you have my vote,
> even if you were the only Committer listed on the proposal. You know
> what's what, and I trust that AltRMI will develop a good following over
> time.
Agreed. It already is, and that¹s the issue here.
However, I would appreciate if you don't just try to ram this through but
actually have a discussion about the issue.
>
> The whole idea behind the Commons committers having karma to every
> package was so that we would not need to have three active committers.
Not sure if that is true.
> I'm not going to get into a discussion about that, but wanted to let you
> know how I would cast my own vote.
--
Geir Magnusson Jr. geirm@optonline.net
System and Software Consulting
The bytecodes are language independent. - Sam Ruby
Re: Adding a committer : Catch-22
Posted by Ted Husted <hu...@apache.org>.
Paul,
Any time you want to propose AltRMI to the Commons, you have my vote,
even if you were the only Committer listed on the proposal. You know
what's what, and I trust that AltRMI will develop a good following over
time.
The whole idea behind the Commons committers having karma to every
package was so that we would not need to have three active committers.
I'm not going to get into a discussion about that, but wanted to let you
know how I would cast my own vote.
-Ted.
Paul Hammant wrote:
>
> Folks,
>
> I am trying to add a committer to commons-sandbox/altrmi. The fellow in
> question is heavily involved with "Enterprise Object Broker" hosted at
> sourceforge which uses AltRMI.
>
> The commons charter, at present, does not allow for a person to be added
> who is not currently a jakarta-* committer.
>
> I need advise, because it seems to be this is insolvable.
>
> - Paul
Re: Adding a committer : Catch-22
Posted by Paul Hammant <mo...@mongrel.homechoice.co.uk>.
dIon,
> I like some of the idea Paul is proposing. Having a 'forge' of Apache
> related software sounds like a good idea. It's a focussed version of
> what's provided @ SourceForge - apache licensed, apache related, but
> not apache endorsed. Think of it as a place to gather apache related
> stuff. Good stuff becomes apache endorsed.
>
> It would not be 'Apache Software', but apache related. It would be a
> good showcase for all those cross project tools like Ant.
Why cannot I be so eloquent?
That part of the discussion moved to general@jakarta, and has been
killed by a few dudes concerned with cost (without actually knowing facts).
Regards,
- Paul H
Re: Adding a committer : Catch-22
Posted by dIon Gillard <di...@multitask.com.au>.
Paul Hammant wrote:
> Geir,
>
>>> And still could. There are plenty of people in Avalon I could rudely
>>> approach and "gerrymander" into an interest in AltRMI... but that would
>>> be dishonest. Bizarrely in this age, I try to keep to a policy of
>>> honesty, but it backfires often.
>>>
>>
>> Well, I agree, but I don't think many people would think it
>> dishonest. Some
>> would even argue that the whole '3 active committer' thing on my part is
>> just some kind of strawman or something, although I have no personal
>> reason
>> to make up a requirement like that, other than my belief in the
>> wisdom that
>> it makes a codebase stronger to have more interested participants.
>>
>>>> Now, the commons charter says nothing about not allowing a person
>>>> to be
>>>> added who isn't a jakarta-* committer. It states, if it really
>>>> matters -
>>>>
>>>> "The subproject will host a CVS repository available to all Jakarta
>>>> committers as a workplace for new packages or other projects."
>>>>
>>>> It does not have any language pertaining to exclusion.
>>>>
>>>> (aside : read the next line - "Before release to the public, code or
>>>> documentation developed here must be sponsored by a Jakarta
>>>> subproject."
>>>> There's a weird one...)
>>>>
>>>> Anyhow, believe it or not, I also agree with Ted about the
>>>> importance of
>>>> making sure that being a Jakarta committer means something.
>>>>
>>> Yes. But look at it another way. Say AltRMI had a different history.
>>> I added it as a packge not project to avalon-excalibur (there is good
>>> overlap). Vinay could have submitted his patches there and been voted
>>> in immediately as he was committing to a viable project. What have I
>>> just said? AltRMI in commons-sanbox is unviable - it has one
>>> committer.
>>> If taped to a preexisting viable project the committer would be added
>>> and welcomed immediately.
>>>
>>
>> I know, I agree, and I greatly sympathize. We have an interesting bind
>> here, and I hope we can resolve it in a way that helps clear this up
>> for the
>> future (rather than just punt again) without causing you undue stress or
>> delay.
>>
>>>> Still, I feel that the sandbox is a great way to introduce people
>>>> to the
>>>> jakarta community - I mean, they are 'harmless' there. I think
>>>> making a
>>>> mistake and adding a committer to sandbox is much easier to deal
>>>> with than
>>>> adding to commons, due to our "commit one, commit all" policy.
>>>>
>>>> So it comes down to 2 options, doesn't it?
>>>>
>>>> 1) Vote on your new person to make him a committer in sandbox.
>>>>
>>>> 2) Vote on your new person to make him a committer in commons.
>>>>
>>> Not just two options....
>>>
>>> 3) Give up - project is by definition unviable heh?
>>>
>>
>> Nope. Not an option. Don't give up - I need some RMI help in a
>> project :)
>>
> Of course not.
>
>>> 4) Move to SourceForge keeping Apache license
>>>
>>
>> I thought of this, but would rather not see that happen.
>>
> Bizarrely it is a front runner. I can build a community there without
> (club metaphor) people being told their footwear is in appropriate
> then bring a project and group back later for Apache project status.
>
>>> 5) Move to avalon-excalibur - instant vaibility, though still
>>> controversy (the RemoteException stuff still trips many up).
>>>
>>
>> This I don't understand, but will take your word for it.
>>
> The controversy I hint at is RMI versus AltRMI per se, not suitability
> for Avalon.
>
>>>> The status of AltRMI would only be relevant here because as a
>>>> component, we
>>>> still would then have to vote on your committer, and as a commons
>>>> committer.
>>>> If we do allow sandbox committers, then we can indeed see if the
>>>> person
>>>> really is interested and dedicated, and when AltRMI comes over the
>>>> fence,
>>>> you can with confidence bring committers you know are, well,
>>>> committed :)
>>>>
>>>> I don't know how to make everyone happy here :)
>>>>
>>>> My 0.02
>>>>
>>> All valid dude.
>>>
>>> I think the moral is - make a community first. Tempt people with code
>>> you have cut, but not surrendered copyright on. Don't be too much of a
>>> do-er - involve all in the codebase, there needs to be room for others.
>>>
>>
>> Right. I agree. There may be questions of appropriateness of AltRMI
>> as a
>> component in commons (I don't know...) and the sandbox maybe has the
>> problem
>> of being too attractive for people to work in. ( I still don't
>> understand
>> why you didn't do this in Avalon, but you have reasons, I am sure - I
>> don't
>> parse the whole avalon community thing anyway...)
>>
> It was a peace keeping measure (another failure of mine). If Avalon
> existed first, then commons is created with some overlap of mandate
> then it could been seen as bridge building for an Avaloner to arrive
> in commons (belatedly) and start some now tuple of code.
>
>> I wonder if we would be well served with a Jakarta-Sandbox - not to be a
>> sourceforge replacement, but also not associate the free playpen only
>> with
>> Commons.
>>
> An idea. I prefer the Forge concept... ApacheForge.
>
>>> I love Apache, the people and the ethos. I dislike the viral
>>> aspects of
>>> the GPL and particularly the wisdom of the FSF not granting Apache
>>> license equal status to BSD. I think we should be encouraging as many
>>> people as possible to cut code with the Apache license. SandBox
>>> (concept of) is good, what might be better is a real sourceforge like
>>> place that openly encourages any project to start along the merit based
>>> principles of Apache. There could be specific rules about non
>>> advertisment (some people are only here for Kudos), but there would be
>>> an ever increasing amount of Apache licensed code. At some stage the
>>> PMC might tap a project on the shoulder and suggest that a move to
>>> formal "front page" project status is appropriate. I like what the FSF
>>> did (from their POV) when they forked the closing Sourceforge software
>>> and mounted : http://savannah.gnu.org/
>>>
>>
>> The problem of and ever-increasing amount of Apache licensed code is
>> that we
>> do have a responsibility towards ensuring that code is free of others
>> IP and
>> such - so having an open market to get more Apache licensed code is
>> worrysome.
>>
> IP, good point. Whilst we dither with such worries though, the FSF
> hoovers up new projects (sooo many people think GPL is the only
> license choice). All of that code is unusable to Apache licensed
> code. A foundary that encouraged (1) from scratch projects and (2)
> licensed change projects, is at best making code that is hopefully IP
> issue clean. There could be issues discovered later, there hopefully
> will not. We would not be the only group to have problems :-
> http://slashdot.org/bsd/01/09/24/1432223.shtml
>
> I'll stand by my assertion that some rules-bound but open ApacheForge
> would be fantastic. It would give us far more benefits than
> drawbacks. I could have played there with AltRMI and have carte
> blanche to build the community how I liked (until I am effectively
> just one of a number). We can take the software that the FSF use (
> http://savannah.gnu.org/projects/savannah/ ) and mount a server that
> is entirely for Apache licensed sandbox projects. Define the merit
> rules. Define the IP rules. Post guidelines for Ant usage, project
> directory structure, announce open season. I mean really, does
> everyone in commons read all the postings? Would the same be true for
> jakarta-sandbox?
>
>>> Sometimes it seems to me that Apache is a closed club.
>>>
>>
>> Hm. I don't know. I will note you are in the club...
>>
> That's fine, but maybe it is not an issue of which side of the shut
> door you are on.
>
> With a separate ApacheForge, we'd have a place where anyone could
> play, while they earn the right for Apache membership.
> At the moment if you bring a half decent project with comitters to
> Apache and have got their agreement for a license change, then you're
> in. Those two steps smell somewhat. Surely a more merit based pure
> route would be to Apache license the code then ask for
> membership/project status.
>
> - Paul
I like some of the idea Paul is proposing. Having a 'forge' of Apache
related software sounds like a good idea. It's a focussed version of
what's provided @ SourceForge - apache licensed, apache related, but not
apache endorsed. Think of it as a place to gather apache related stuff.
Good stuff becomes apache endorsed.
It would not be 'Apache Software', but apache related. It would be a
good showcase for all those cross project tools like Ant.
--
dIon Gillard, Multitask Consulting
http://www.multitask.com.au/developers
Re: Adding a committer : Catch-22
Posted by Paul Hammant <Pa...@yahoo.com>.
Geir,
>>And still could. There are plenty of people in Avalon I could rudely
>>approach and "gerrymander" into an interest in AltRMI... but that would
>>be dishonest. Bizarrely in this age, I try to keep to a policy of
>>honesty, but it backfires often.
>>
>
>Well, I agree, but I don't think many people would think it dishonest. Some
>would even argue that the whole '3 active committer' thing on my part is
>just some kind of strawman or something, although I have no personal reason
>to make up a requirement like that, other than my belief in the wisdom that
>it makes a codebase stronger to have more interested participants.
>
>>>Now, the commons charter says nothing about not allowing a person to be
>>>added who isn't a jakarta-* committer. It states, if it really matters -
>>>
>>>"The subproject will host a CVS repository available to all Jakarta
>>>committers as a workplace for new packages or other projects."
>>>
>>>It does not have any language pertaining to exclusion.
>>>
>>>(aside : read the next line - "Before release to the public, code or
>>>documentation developed here must be sponsored by a Jakarta subproject."
>>>There's a weird one...)
>>>
>>>Anyhow, believe it or not, I also agree with Ted about the importance of
>>>making sure that being a Jakarta committer means something.
>>>
>>Yes. But look at it another way. Say AltRMI had a different history.
>>I added it as a packge not project to avalon-excalibur (there is good
>>overlap). Vinay could have submitted his patches there and been voted
>>in immediately as he was committing to a viable project. What have I
>>just said? AltRMI in commons-sanbox is unviable - it has one committer.
>>If taped to a preexisting viable project the committer would be added
>>and welcomed immediately.
>>
>
>I know, I agree, and I greatly sympathize. We have an interesting bind
>here, and I hope we can resolve it in a way that helps clear this up for the
>future (rather than just punt again) without causing you undue stress or
>delay.
>
>>>Still, I feel that the sandbox is a great way to introduce people to the
>>>jakarta community - I mean, they are 'harmless' there. I think making a
>>>mistake and adding a committer to sandbox is much easier to deal with than
>>>adding to commons, due to our "commit one, commit all" policy.
>>>
>>>So it comes down to 2 options, doesn't it?
>>>
>>>1) Vote on your new person to make him a committer in sandbox.
>>>
>>>2) Vote on your new person to make him a committer in commons.
>>>
>>Not just two options....
>>
>>3) Give up - project is by definition unviable heh?
>>
>
>Nope. Not an option. Don't give up - I need some RMI help in a project :)
>
Of course not.
>>4) Move to SourceForge keeping Apache license
>>
>
>I thought of this, but would rather not see that happen.
>
Bizarrely it is a front runner. I can build a community there without
(club metaphor) people being told their footwear is in appropriate then
bring a project and group back later for Apache project status.
>>5) Move to avalon-excalibur - instant vaibility, though still
>>controversy (the RemoteException stuff still trips many up).
>>
>
>This I don't understand, but will take your word for it.
>
The controversy I hint at is RMI versus AltRMI per se, not suitability
for Avalon.
>>>The status of AltRMI would only be relevant here because as a component, we
>>>still would then have to vote on your committer, and as a commons committer.
>>>If we do allow sandbox committers, then we can indeed see if the person
>>>really is interested and dedicated, and when AltRMI comes over the fence,
>>>you can with confidence bring committers you know are, well, committed :)
>>>
>>>I don't know how to make everyone happy here :)
>>>
>>>My 0.02
>>>
>>All valid dude.
>>
>>I think the moral is - make a community first. Tempt people with code
>>you have cut, but not surrendered copyright on. Don't be too much of a
>>do-er - involve all in the codebase, there needs to be room for others.
>>
>
>Right. I agree. There may be questions of appropriateness of AltRMI as a
>component in commons (I don't know...) and the sandbox maybe has the problem
>of being too attractive for people to work in. ( I still don't understand
>why you didn't do this in Avalon, but you have reasons, I am sure - I don't
>parse the whole avalon community thing anyway...)
>
It was a peace keeping measure (another failure of mine). If Avalon
existed first, then commons is created with some overlap of mandate then
it could been seen as bridge building for an Avaloner to arrive in
commons (belatedly) and start some now tuple of code.
>I wonder if we would be well served with a Jakarta-Sandbox - not to be a
>sourceforge replacement, but also not associate the free playpen only with
>Commons.
>
An idea. I prefer the Forge concept... ApacheForge.
>>I love Apache, the people and the ethos. I dislike the viral aspects of
>>the GPL and particularly the wisdom of the FSF not granting Apache
>>license equal status to BSD. I think we should be encouraging as many
>>people as possible to cut code with the Apache license. SandBox
>>(concept of) is good, what might be better is a real sourceforge like
>>place that openly encourages any project to start along the merit based
>>principles of Apache. There could be specific rules about non
>>advertisment (some people are only here for Kudos), but there would be
>>an ever increasing amount of Apache licensed code. At some stage the
>>PMC might tap a project on the shoulder and suggest that a move to
>>formal "front page" project status is appropriate. I like what the FSF
>>did (from their POV) when they forked the closing Sourceforge software
>>and mounted : http://savannah.gnu.org/
>>
>
>The problem of and ever-increasing amount of Apache licensed code is that we
>do have a responsibility towards ensuring that code is free of others IP and
>such - so having an open market to get more Apache licensed code is
>worrysome.
>
IP, good point. Whilst we dither with such worries though, the FSF
hoovers up new projects (sooo many people think GPL is the only license
choice). All of that code is unusable to Apache licensed code. A
foundary that encouraged (1) from scratch projects and (2) licensed
change projects, is at best making code that is hopefully IP issue
clean. There could be issues discovered later, there hopefully will
not. We would not be the only group to have problems :-
http://slashdot.org/bsd/01/09/24/1432223.shtml
I'll stand by my assertion that some rules-bound but open ApacheForge
would be fantastic. It would give us far more benefits than drawbacks.
I could have played there with AltRMI and have carte blanche to build
the community how I liked (until I am effectively just one of a number).
We can take the software that the FSF use (
http://savannah.gnu.org/projects/savannah/ ) and mount a server that is
entirely for Apache licensed sandbox projects. Define the merit rules.
Define the IP rules. Post guidelines for Ant usage, project directory
structure, announce open season. I mean really, does everyone in
commons read all the postings? Would the same be true for jakarta-sandbox?
>>Sometimes it seems to me that Apache is a closed club.
>>
>
>Hm. I don't know. I will note you are in the club...
>
That's fine, but maybe it is not an issue of which side of the shut door
you are on.
With a separate ApacheForge, we'd have a place where anyone could play,
while they earn the right for Apache membership.
At the moment if you bring a half decent project with comitters to
Apache and have got their agreement for a license change, then you're
in. Those two steps smell somewhat. Surely a more merit based pure
route would be to Apache license the code then ask for
membership/project status.
- Paul
Re: Adding a committer : Catch-22
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On 2/19/02 6:16 AM, "Paul Hammant" <mo...@mongrel.homechoice.co.uk> wrote:
> Geir,
>
>>> I need advise, because it seems to be this is insolvable.
>>>
>>
>> I agree, and this is my POV as well.
>>
>> When you proposed to make AltRMI a commons component, I suggested that you
>> get two more committers, as the Jakarta guidelines suggest that 3 committers
>> are required to add a new sourcebase. The spirit of this, as I understand
>> it, is to make sure that there are 3 interested, dedicated people behind a
>> codebase ("active, involved developers") to ensure the life of it in case
>> one person stops working on it.
>>
> Yup.
>
>> Of course in commons, the charter is vague, and we can appeal to a whole set
>> of non-binding guidelines to hand-wave this issue away, but I don't think we
>> should do that.
>>
>> Now, since then, I have watched you, Paul, work diligently on AltRMI with no
>> loss of focus, and I have to say I am impressed. I also believe that you
>> aren't trivially trying to add this person just to get committers. I
>> *really* respect that, as you could have just gotten two others and claimed
>> they were committers.
>>
> And still could. There are plenty of people in Avalon I could rudely
> approach and "gerrymander" into an interest in AltRMI... but that would
> be dishonest. Bizarrely in this age, I try to keep to a policy of
> honesty, but it backfires often.
Well, I agree, but I don't think many people would think it dishonest. Some
would even argue that the whole '3 active committer' thing on my part is
just some kind of strawman or something, although I have no personal reason
to make up a requirement like that, other than my belief in the wisdom that
it makes a codebase stronger to have more interested participants.
>
>> Now, the commons charter says nothing about not allowing a person to be
>> added who isn't a jakarta-* committer. It states, if it really matters -
>>
>> "The subproject will host a CVS repository available to all Jakarta
>> committers as a workplace for new packages or other projects."
>>
>> It does not have any language pertaining to exclusion.
>>
>> (aside : read the next line - "Before release to the public, code or
>> documentation developed here must be sponsored by a Jakarta subproject."
>> There's a weird one...)
>>
>> Anyhow, believe it or not, I also agree with Ted about the importance of
>> making sure that being a Jakarta committer means something.
>>
> Yes. But look at it another way. Say AltRMI had a different history.
> I added it as a packge not project to avalon-excalibur (there is good
> overlap). Vinay could have submitted his patches there and been voted
> in immediately as he was committing to a viable project. What have I
> just said? AltRMI in commons-sanbox is unviable - it has one committer.
> If taped to a preexisting viable project the committer would be added
> and welcomed immediately.
I know, I agree, and I greatly sympathize. We have an interesting bind
here, and I hope we can resolve it in a way that helps clear this up for the
future (rather than just punt again) without causing you undue stress or
delay.
>
>> Still, I feel that the sandbox is a great way to introduce people to the
>> jakarta community - I mean, they are 'harmless' there. I think making a
>> mistake and adding a committer to sandbox is much easier to deal with than
>> adding to commons, due to our "commit one, commit all" policy.
>>
>> So it comes down to 2 options, doesn't it?
>>
>> 1) Vote on your new person to make him a committer in sandbox.
>>
>> 2) Vote on your new person to make him a committer in commons.
>>
> Not just two options....
>
> 3) Give up - project is by definition unviable heh?
Nope. Not an option. Don't give up - I need some RMI help in a project :)
>
> 4) Move to SourceForge keeping Apache license
I thought of this, but would rather not see that happen.
>
> 5) Move to avalon-excalibur - instant vaibility, though still
> controversy (the RemoteException stuff still trips many up).
This I don't understand, but will take your word for it.
>> The status of AltRMI would only be relevant here because as a component, we
>> still would then have to vote on your committer, and as a commons committer.
>> If we do allow sandbox committers, then we can indeed see if the person
>> really is interested and dedicated, and when AltRMI comes over the fence,
>> you can with confidence bring committers you know are, well, committed :)
>>
>> I don't know how to make everyone happy here :)
>>
>> My 0.02
>>
> All valid dude.
>
> I think the moral is - make a community first. Tempt people with code
> you have cut, but not surrendered copyright on. Don't be too much of a
> do-er - involve all in the codebase, there needs to be room for others.
Right. I agree. There may be questions of appropriateness of AltRMI as a
component in commons (I don't know...) and the sandbox maybe has the problem
of being too attractive for people to work in. ( I still don't understand
why you didn't do this in Avalon, but you have reasons, I am sure - I don't
parse the whole avalon community thing anyway...)
I wonder if we would be well served with a Jakarta-Sandbox - not to be a
sourceforge replacement, but also not associate the free playpen only with
Commons.
>
> I love Apache, the people and the ethos. I dislike the viral aspects of
> the GPL and particularly the wisdom of the FSF not granting Apache
> license equal status to BSD. I think we should be encouraging as many
> people as possible to cut code with the Apache license. SandBox
> (concept of) is good, what might be better is a real sourceforge like
> place that openly encourages any project to start along the merit based
> principles of Apache. There could be specific rules about non
> advertisment (some people are only here for Kudos), but there would be
> an ever increasing amount of Apache licensed code. At some stage the
> PMC might tap a project on the shoulder and suggest that a move to
> formal "front page" project status is appropriate. I like what the FSF
> did (from their POV) when they forked the closing Sourceforge software
> and mounted : http://savannah.gnu.org/
The problem of and ever-increasing amount of Apache licensed code is that we
do have a responsibility towards ensuring that code is free of others IP and
such - so having an open market to get more Apache licensed code is
worrysome.
> Sometimes it seems to me that Apache is a closed club.
Hm. I don't know. I will note you are in the club...
>
>
> - Paul
>
--
Geir Magnusson Jr. geirm@optonline.net
System and Software Consulting
Be a giant. Take giant steps. Do giant things...
Re: Adding a committer : Catch-22
Posted by Paul Hammant <mo...@mongrel.homechoice.co.uk>.
Geir,
>>I need advise, because it seems to be this is insolvable.
>>
>
>I agree, and this is my POV as well.
>
>When you proposed to make AltRMI a commons component, I suggested that you
>get two more committers, as the Jakarta guidelines suggest that 3 committers
>are required to add a new sourcebase. The spirit of this, as I understand
>it, is to make sure that there are 3 interested, dedicated people behind a
>codebase ("active, involved developers") to ensure the life of it in case
>one person stops working on it.
>
Yup.
>Of course in commons, the charter is vague, and we can appeal to a whole set
>of non-binding guidelines to hand-wave this issue away, but I don't think we
>should do that.
>
>Now, since then, I have watched you, Paul, work diligently on AltRMI with no
>loss of focus, and I have to say I am impressed. I also believe that you
>aren't trivially trying to add this person just to get committers. I
>*really* respect that, as you could have just gotten two others and claimed
>they were committers.
>
And still could. There are plenty of people in Avalon I could rudely
approach and "gerrymander" into an interest in AltRMI... but that would
be dishonest. Bizarrely in this age, I try to keep to a policy of
honesty, but it backfires often.
>Now, the commons charter says nothing about not allowing a person to be
>added who isn't a jakarta-* committer. It states, if it really matters -
>
>"The subproject will host a CVS repository available to all Jakarta
>committers as a workplace for new packages or other projects."
>
>It does not have any language pertaining to exclusion.
>
>(aside : read the next line - "Before release to the public, code or
>documentation developed here must be sponsored by a Jakarta subproject."
>There's a weird one...)
>
>Anyhow, believe it or not, I also agree with Ted about the importance of
>making sure that being a Jakarta committer means something.
>
Yes. But look at it another way. Say AltRMI had a different history.
I added it as a packge not project to avalon-excalibur (there is good
overlap). Vinay could have submitted his patches there and been voted
in immediately as he was committing to a viable project. What have I
just said? AltRMI in commons-sanbox is unviable - it has one committer.
If taped to a preexisting viable project the committer would be added
and welcomed immediately.
>Still, I feel that the sandbox is a great way to introduce people to the
>jakarta community - I mean, they are 'harmless' there. I think making a
>mistake and adding a committer to sandbox is much easier to deal with than
>adding to commons, due to our "commit one, commit all" policy.
>
>So it comes down to 2 options, doesn't it?
>
>1) Vote on your new person to make him a committer in sandbox.
>
>2) Vote on your new person to make him a committer in commons.
>
Not just two options....
3) Give up - project is by definition unviable heh?
4) Move to SourceForge keeping Apache license
5) Move to avalon-excalibur - instant vaibility, though still
controversy (the RemoteException stuff still trips many up).
>The status of AltRMI would only be relevant here because as a component, we
>still would then have to vote on your committer, and as a commons committer.
>If we do allow sandbox committers, then we can indeed see if the person
>really is interested and dedicated, and when AltRMI comes over the fence,
>you can with confidence bring committers you know are, well, committed :)
>
>I don't know how to make everyone happy here :)
>
>My 0.02
>
All valid dude.
I think the moral is - make a community first. Tempt people with code
you have cut, but not surrendered copyright on. Don't be too much of a
do-er - involve all in the codebase, there needs to be room for others.
I love Apache, the people and the ethos. I dislike the viral aspects of
the GPL and particularly the wisdom of the FSF not granting Apache
license equal status to BSD. I think we should be encouraging as many
people as possible to cut code with the Apache license. SandBox
(concept of) is good, what might be better is a real sourceforge like
place that openly encourages any project to start along the merit based
principles of Apache. There could be specific rules about non
advertisment (some people are only here for Kudos), but there would be
an ever increasing amount of Apache licensed code. At some stage the
PMC might tap a project on the shoulder and suggest that a move to
formal "front page" project status is appropriate. I like what the FSF
did (from their POV) when they forked the closing Sourceforge software
and mounted : http://savannah.gnu.org/
Sometimes it seems to me that Apache is a closed club.
- Paul
Re: Adding a committer : Catch-22
Posted by Paul Hammant <Pa...@yahoo.com>.
Gerhard,
>Here I mean just rising something up like SourceForge (Solution
>for #2). Paul suggested it this afternoon in the Jakarta general
>list! But I think Apache can't effort this.
>
You and that other guy don;t know what Apache can afford. Sorry
good-buddy, but we should only speak up on areas we actullay know of.
For most of us that is technology not funding. Besides Apache could
get SF to so it all and have it as a skinning or branding effort.
>>Your english is way better than my german - no worries :)
>>
Your English is always good dude.
>>I think I lost you at the end though. Can you restate the last three
>>paragraphs?
>>
>
>Personally I'm in a dilemma:
>1. I would like to see Paul's AltRMI and other's (mine included, of course)
>to be a success!
>2. I have a problem, how Jakarta principles are weakened, just to work
>around a definition issue here and otherwise are lived tough in other
>projects. This I don't like in general. Sometimes hard for my friends ;)
>
I assert that the best pattern for success for people of lowly stature
like you ame be dude, is a paraphrased Prodigal Son pattern - Go to
sourceforge, use freedoms there, come back and be welcomed. Would POI
have been allowed in commons or as a from-scratch project if you or I
suggested it?
- Paul
RE: Adding a committer : Catch-22
Posted by Gerhard Froehlich <g-...@gmx.de>.
All,
<skip/>
>PMC shouldn't have to pay attention. I am on the PMC (for the next week or
>so anyway :) but my participation in this has nothing to do with that. I am
>a concerned commons committer, just like you.
>
>I think we can change things such that the PMC never has to be involved.
>That's the ideal world, for me anyway.
>
>Yes, people are trusted. That's not the problem. And as Commons is a
>Jakarta project, it is a private club - however, we can allow people that
>are not existing jakarta committers into Commons, just like any other
>subproject can.
Hmm I think it doesn't work in reality, because of the bunch of projects.
It's more a organizational problem. One project, one big clear vision.
Many projects, many visions (sometimes very personal). It's hard to share
them. That's Paul problem. He is a great developer and one of my masters I
follow! But he fails, because AltRMI is not that popular in commons,
but this doesn't mean it's bad code, or. Remember his is doing lot of stuff
in the Avalon project and rememeber he is a trusted Jakarta-Avalon committer
and remember he is just searching for a place to share his ideas here at Jakarta.
Commons is this place!
>The 'sissy 3 committer rule' is actually a Jakarta guideline. Since I
>didn't have anything to do with it's creation, I can only guess at the
>reasoning - to support the Apache principle that projects should outlive
>their initial creators. By having 3 dedicated committers, we ensure that
>something we adopt in commons will have a good chance of enduring if one of
>the committers has to put less time into it....
>
>As the number of commons components grow, self-management of the components
>becomes more important. If people start to perceive that there is abandoned
>junk in it...
Yes, I see the problem. But it doesn't work and it weakens the Jakarta rules,
which are much stronger in other projects. This doesn't fit together.
>>
>> Commons-Sandbox is kool for starting the draft and after a final
>> proposal for the first release, it's ready for commons.
>
>Indeed. It's also a fun place to play in. Try things. Abandon them.
>That's ok.
Yes, I'm doing this in the moment with Juozas and I change my orginal
proposal every week ;). But this is kool and learn much!
>> Do we need
>> another vote here? Sorry guys, but there are so many projects around
>> and honestly I can't observe them all. I have to do this selective
>> (interest and job driven)! And I have one golden rule, I don't vote
>> for things I don't know and I don't vote for committers I don't know.
>> Neither nor I do it just to fancy somebody.
>
>This is the problem then.
>
>If we all followed this, we couldn't ever add people to commons when you
>have a situation like Paul's - only he knows the person in question (we
>trust) and therefore since it's his gig...
>
>Suppose we made AltRMI a commons component. So far, no commons committer in
>the months that its been there has participated, IIRC. So now again we are
>down to Paul asking for a vote, and if we all followed your lead, he's still
>stuck.
Hmm but then why this rules. Following this lead, I give blind +1. Maybe I read
the Proposal, but I have no idea of the codebase and I don't know it in detail!
Ok the argument could be -> dig into the project! But let's be realistic.
>At least if we let the candidate into sandbox, he could prove himself to
>Paul, and then paul can propose AltRMI with a set of committers in tow.
>
>>
>> Solution for #1 would be to close Jakarta-Commons for non Jakarta
>> committers and weaken the rules above.
>
>I don't understand - do you mean only let people into commons that are
>committers elsewhere in Jakarta? Interesting idea in that it keeps commons
>true to a *few* of it's original intents, but closes the door for some of
>the other original intents, namely as a way to build community. I think I
>am pretty sure I would be against this, as letting new people into commons,
>like any other subproject in jakarta, is good and healthy.
Yes exactly, that I mean for proposal #1 "Commons as a private club".
I just balancing the possible solutions and the effects.
Yep Commons would be a very exclusive party and maybe against the open
community character, that's the deal here in solution #1.
NOTE: I posted 2 proposals ;).
>>I think that would be a
>> realistic trade and I have no problem with that, really! Some of
>> us worked really hard to get their committer state, why not.
>> Apache was always something special under the OSS community. It is
>> professional led! It rules!
>
>Yep. I agree with that. Becoming a committer to Commons should be no
>'easier' than becoming a committer to anything else. It means something.
>
>>
>> 2) Commons is a public Club open for everybody and it has the same
>> process as every Jakarta project like Avalon, Struts, ... .
>> But now you have a problem. Normally it takes at least 3-6 month heavy
>> patch contributing until you become a committer in the other projects.
>> Especially the first time (like in live ;-)). After then, you
>> earned some respect, you're known in the community and things going
>> easier (Maybe I'm the only one, because my patches were to bad in the
>> beginning).
>
>:) I have no idea if that's true. Appreciate the self-deprecating humor
>though...
Sadly it was truth in the beginning, but the Cocoon committers showed me
the way from the dark into the light ;).
>> I personally like this, because people contributing with more ambition
>> and they are earning their status. Farther on you don't want, that everybody
>> gets this easy an @jakarta.org account. Kool I like this, but it doesn't
>> work for commons really! First of all, this 3 committer rule and then
>> the "you have to be Jakarta Committer" rule. What shall I do. Post to
>> every Jakarta list and advertise for the project. It doesn't work.
>> I understand why people don't show attention to my project, because
>> they aren't interested, are involved in much other things or don't
>> have the time. But then destiny got me and my project will stay in
>> commons-sandbox for ever. For me no problem, because I use it. But
>> somehow it's a pity that good projects get lost in the mass of contribution.
>>
>
>I have to admit I lost you here.
I just wanted to describe the problem of building a community
No community, no commons. Hard, but truth. How to build a community?
Screaming loud and often? Remember what I talked above about many projects,
many visions.
How to build a community, when you have to? That's a little bit constrained.
I like this community approach for the big ones like (Tomcat, s.o.)!
But for commons it's too much and can't be handled fair!
>> How to solve #2, close commons under Jakarta and start something
>> completly new under a special domain. Apache for *everybody* and
>> restrict this to the Apache License. But then you have to handle
>> with a mass of contibutions.
>> Or you allow *written*, that people can be voted as committers for
>> commons-sandbox and you deal with the fact that your @apache.org
>> members are increasing (is that bad?).
>> Ok but with which voting rules?
Here I mean just rising something up like SourceForge (Solution
for #2). Paul suggested it this afternoon in the Jakarta general
list! But I think Apache can't effort this.
>> Personally I prefer #1 and #2, because I like coding and for me
>> it doesn't play any role if this is in commons or commons-sandbox.
>> I like to share my knowledge and I like to learn from you guys.
>> That's my motivation.
>> But things here are going to be a farce and that's dangerous!
>> Make a clear statement and clear rules!
>>
>> Sorry for being a little bit rude, but it's really weird here.
>> (apologies bad english)
>
>Your english is way better than my german - no worries :)
>
>I think I lost you at the end though. Can you restate the last three
>paragraphs?
Personally I'm in a dilemma:
1. I would like to see Paul's AltRMI and other's (mine included, of course)
to be a success!
2. I have a problem, how Jakarta principles are weakened, just to work
around a definition issue here and otherwise are lived tough in other
projects. This I don't like in general. Sometimes hard for my friends ;)
So now I have to be careful, otherwise I shoot myself in the knee ;)
~Gerhard
----------------------------------------
"In English, there is no double positive
that makes a negative."
"Yeah, right."
----------------------------------------
Re: Adding a committer : Catch-22
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On 2/19/02 1:17 PM, "Gerhard Froehlich" <g-...@gmx.de> wrote:
> Geir,
>
>
>> So it comes down to 2 options, doesn't it?
>>
>> 1) Vote on your new person to make him a committer in sandbox.
>>
>> 2) Vote on your new person to make him a committer in commons.
>
> Exactly, that's they way I introduced Jouzoas for the simplestore
> project and he's doing well. I hope this was correct, because
> he wasn't a jakarta-* committer before. But I think I mentioned
> that...
>
> Honestly otherwise I don't see any way to see commons grow.
>
> For me there are two strategic possibilties:
>
> 1) Commons is a private Club *only* for Jakarta committers, which
> earned that status in other Jakarta projects. But then this sissy
> 3 committer rule is unnecessary. This people are trusted
> coders and hopefully they know what they are doing. One of you PMC
> guys plays big brother and pay attention, that there is no wild
> hacking and everybody is playing after the usual Jakarta rules.
PMC shouldn't have to pay attention. I am on the PMC (for the next week or
so anyway :) but my participation in this has nothing to do with that. I am
a concerned commons committer, just like you.
I think we can change things such that the PMC never has to be involved.
That's the ideal world, for me anyway.
Yes, people are trusted. That's not the problem. And as Commons is a
Jakarta project, it is a private club - however, we can allow people that
are not existing jakarta committers into Commons, just like any other
subproject can.
The 'sissy 3 committer rule' is actually a Jakarta guideline. Since I
didn't have anything to do with it's creation, I can only guess at the
reasoning - to support the Apache principle that projects should outlive
their initial creators. By having 3 dedicated committers, we ensure that
something we adopt in commons will have a good chance of enduring if one of
the committers has to put less time into it....
As the number of commons components grow, self-management of the components
becomes more important. If people start to perceive that there is abandoned
junk in it...
>
> Commons-Sandbox is kool for starting the draft and after a final
> proposal for the first release, it's ready for commons.
Indeed. It's also a fun place to play in. Try things. Abandon them.
That's ok.
> Do we need
> another vote here? Sorry guys, but there are so many projects around
> and honestly I can't observe them all. I have to do this selective
> (interest and job driven)! And I have one golden rule, I don't vote
> for things I don't know and I don't vote for committers I don't know.
> Neither nor I do it just to fancy somebody.
This is the problem then.
If we all followed this, we couldn't ever add people to commons when you
have a situation like Paul's - only he knows the person in question (we
trust) and therefore since it's his gig...
Suppose we made AltRMI a commons component. So far, no commons committer in
the months that its been there has participated, IIRC. So now again we are
down to Paul asking for a vote, and if we all followed your lead, he's still
stuck.
At least if we let the candidate into sandbox, he could prove himself to
Paul, and then paul can propose AltRMI with a set of committers in tow.
>
> Solution for #1 would be to close Jakarta-Commons for non Jakarta
> committers and weaken the rules above.
I don't understand - do you mean only let people into commons that are
committers elsewhere in Jakarta? Interesting idea in that it keeps commons
true to a *few* of it's original intents, but closes the door for some of
the other original intents, namely as a way to build community. I think I
am pretty sure I would be against this, as letting new people into commons,
like any other subproject in jakarta, is good and healthy.
>I think that would be a
> realistic trade and I have no problem with that, really! Some of
> us worked really hard to get their committer state, why not.
> Apache was always something special under the OSS community. It is
> professional led! It rules!
Yep. I agree with that. Becoming a committer to Commons should be no
'easier' than becoming a committer to anything else. It means something.
>
> 2) Commons is a public Club open for everybody and it has the same
> process as every Jakarta project like Avalon, Struts, ... .
> But now you have a problem. Normally it takes at least 3-6 month heavy
> patch contributing until you become a committer in the other projects.
> Especially the first time (like in live ;-)). After then, you
> earned some respect, you're known in the community and things going
> easier (Maybe I'm the only one, because my patches were to bad in the
> beginning).
:) I have no idea if that's true. Appreciate the self-deprecating humor
though...
> I personally like this, because people contributing with more ambition
> and they are earning their status. Farther on you don't want, that everybody
> gets this easy an @jakarta.org account. Kool I like this, but it doesn't
> work for commons really! First of all, this 3 committer rule and then
> the "you have to be Jakarta Committer" rule. What shall I do. Post to
> every Jakarta list and advertise for the project. It doesn't work.
> I understand why people don't show attention to my project, because
> they aren't interested, are involved in much other things or don't
> have the time. But then destiny got me and my project will stay in
> commons-sandbox for ever. For me no problem, because I use it. But
> somehow it's a pity that good projects get lost in the mass of contribution.
>
I have to admit I lost you here.
> How to solve #2, close commons under Jakarta and start something
> completly new under a special domain. Apache for *everybody* and
> restrict this to the Apache License. But then you have to handle
> with a mass of contibutions.
> Or you allow *written*, that people can be voted as committers for
> commons-sandbox and you deal with the fact that your @apache.org
> members are increasing (is that bad?).
> Ok but with which voting rules?
>
> Personally I prefer #1 and #2, because I like coding and for me
> it doesn't play any role if this is in commons or commons-sandbox.
> I like to share my knowledge and I like to learn from you guys.
> That's my motivation.
> But things here are going to be a farce and that's dangerous!
> Make a clear statement and clear rules!
>
> Sorry for being a little bit rude, but it's really weird here.
> (apologies bad english)
Your english is way better than my german - no worries :)
I think I lost you at the end though. Can you restate the last three
paragraphs?
--
Geir Magnusson Jr. geirm@optonline.net
System and Software Consulting
Java : the speed of Smalltalk with the simple elegance of C++...
Re: Adding a committer : Catch-22
Posted by Paul Hammant <mo...@mongrel.homechoice.co.uk>.
costinm@covalent.net wrote:
>IMHO commons is supposed to be a repository for code
>that is used by multiple jakarta projects - not
>a dump or a sourceforge-style repository where
>any cool idea can be implemented.
>
>I don't see any catch-22 here - I think of sandbox as
>a ( common ) 'extension' to all jakarta projects.
>If a project is indeed usefull in at least a jakarta project
> ( or more ), and someone sends patches and contributions
>to that sandbox component, I'm sure the commiters from
>the jakarta project that is interested in the sandbox
>component can vote and make the contributor a commiter
>- either on the project or on commons.
>
>If the sandbox component doesn't have at least 3
>commiters and is not used by at least one jakarta project,
>I don't think it should be included in commons or
>get to add more commiters - there's not enoguh review
>nor interest.
>
>In general, use by at least one jakarta project should
>be a major factor in getting something in jakarta-commons.
>
It is ->
http://cvs.apache.org/viewcvs/jakarta-avalon-cornerstone/src/java/org/apache/avalon/cornerstone/blocks/transport/
This track leads me to believe that Commons was the wrong place.
AltRMI is reusable yes. It is for use by server (and client) comps,
yes. Ideally I would like it as a jakarta level project, but hell would
freeze over before that happens - I am no good a building communities
and lots of people read one line of it's purpose and -1 it on principle.
Sigh, I am at no decision point yet, but my feeling is that commons is
the wrong place. Excalibur is the right place (if it stays at Apache),
Sourceforge would be a good place too, cos I can just add my committer.
- Paul
Re: Adding a committer : Catch-22
Posted by Paul Hammant <mo...@mongrel.homechoice.co.uk>.
Geir
>
>And this is an interesting aspect : do you consider AltRMI a part of Avalon?
>
I'll chip in here. No, it is a general client-server piping tool It
can be used by fat swing client and non avalon server comps.
It is wrapped by Avalon (a few cornerstone blocks), or you could call
them implementation hiding proxies. It is also used by EOB - being
announced today on FreshMeat,
Regards,
- Paul H
RE: Adding a committer : Catch-22
Posted by Magnus ?or Torfason <ma...@handtolvur.is>.
> Magnus,
>
> Your views on the quality of Avalon code are way off.
>
> - Paul
I am extremely sorry if you took my comments as a statement regarding the
quality of Avalon code.
My point (deduced f.e. from Email components and Base64 components from
within specific projects, not from Avalon code) is that specific packages,
while working very well within their context, are not always directly usable
on their own. Configuration methods may be missing, so when used out of
context, they need some tinkering with, even if they work perfectly within
the context of the application.
So what I meant to say that this difference may, in general (I am NOT
referring to this special case), justify handling the addition of a
component to Commons (Three committers and other formalities Geir is
mentioning), differently from adding a new component to a project, where it
is to be used only by those that are using that project itself.
Best regards,
Magnus
Re: Adding a committer : Catch-22
Posted by Paul Hammant <mo...@mongrel.homechoice.co.uk>.
Magnus,
Your views on the quality of Avalon code are way off.
- Paul
>>But in Avalon I could add my committer (granted with maybe one more
>>patch submission) because the project (Avalon) is viable. I would not
>>be questioed there in adding the AltRMI packages to avalon package trees.
>>
>
>Yes, but the stability and sustainability requirements would then be
>significantly lower. If I were to use a component from within Avalon, I
>would expect that it may not work out of context, and I may need to make
>modifications and fixes.
>
>If I get the component from commons, I do not think that the same level of
>quality would be acceptable. Hence, it is not such a weird idea that the
>requirements for commitment are higher.
>
>>- Paul
>>
>
>Regards,
>
>Magnus
>
>
>
RE: Adding a committer : Catch-22
Posted by Magnus ?or Torfason <ma...@handtolvur.is>.
>
> But in Avalon I could add my committer (granted with maybe one more
> patch submission) because the project (Avalon) is viable. I would not
> be questioed there in adding the AltRMI packages to avalon package trees.
>
Yes, but the stability and sustainability requirements would then be
significantly lower. If I were to use a component from within Avalon, I
would expect that it may not work out of context, and I may need to make
modifications and fixes.
If I get the component from commons, I do not think that the same level of
quality would be acceptable. Hence, it is not such a weird idea that the
requirements for commitment are higher.
>
> - Paul
>
Regards,
Magnus
Re: Adding a committer : Catch-22
Posted by Paul Hammant <mo...@mongrel.homechoice.co.uk>.
Geir,
>
>What's wrong with RMI ? :)
>
<fx>Loads Gun</fx>
>>>>Even in the unlikely event other commons people will vote
>>>>against, the code can still be released and people
>>>>added as part of the other project.
>>>>
>>>If it is associated with another project. In Paul's case?
>>>
>>Yes, Avalon-Cornerstone uses AltRMI.
>>EOB (announced today and hosted at sourceforge) uses it.
>>
>
>So let me get this straight - it's not in Avalon, although Avalon uses it?
>
>
>Why isn't this just the case of an Avalon component coming to commons?
>
It had broader appeal than just Avalon.
I would agree that it was a tool that could have been and Avalon comp,
coming to Commons (as a peace keeping measure). Unfortunately my
position is impossible there. I should have started it on SourceForge
as LGPL!
- Paul
Re: Adding a committer : Catch-22
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On 2/19/02 4:20 PM, "Paul Hammant" <mo...@mongrel.homechoice.co.uk> wrote:
> Geir
>
>> It does, actually, doesn't it? It means that things in the sandbox must be
>> associated with a Jakarta subproject. In Paul's case, is it Avalon or is it
>> Commons? No one in commons is participating in AltRMI (except Paul,
>> diligently) and no one in Avalon is either.
>>
>
> But in Avalon I could add my committer (granted with maybe one more
> patch submission) because the project (Avalon) is viable. I would not
> be questioed there in adding the AltRMI packages to avalon package trees.
Right. Agreed. Just posing the question, as you clearly aren't doing it in
Avalon, although you could. I am not questioning your reasons, just noting
the situation.
>
> In commons half of the problem is that the entire project (AltRMI) only
> has one committer. Secondly it is controvercial ("what is wrong with
> RMI" they bellow).
What's wrong with RMI ? :)
>
>>> Even in the unlikely event other commons people will vote
>>> against, the code can still be released and people
>>> added as part of the other project.
>>>
>>
>> If it is associated with another project. In Paul's case?
>>
> Yes, Avalon-Cornerstone uses AltRMI.
> EOB (announced today and hosted at sourceforge) uses it.
So let me get this straight - it's not in Avalon, although Avalon uses it?
Why isn't this just the case of an Avalon component coming to commons?
--
Geir Magnusson Jr. geirm@optonline.net
System and Software Consulting
"He who throws mud only loses ground." - Fat Albert
Re: Adding a committer : Catch-22
Posted by Paul Hammant <mo...@mongrel.homechoice.co.uk>.
Geir
>It does, actually, doesn't it? It means that things in the sandbox must be
>associated with a Jakarta subproject. In Paul's case, is it Avalon or is it
>Commons? No one in commons is participating in AltRMI (except Paul,
>diligently) and no one in Avalon is either.
>
But in Avalon I could add my committer (granted with maybe one more
patch submission) because the project (Avalon) is viable. I would not
be questioed there in adding the AltRMI packages to avalon package trees.
In commons half of the problem is that the entire project (AltRMI) only
has one committer. Secondly it is controvercial ("what is wrong with
RMI" they bellow).
>>Even in the unlikely event other commons people will vote
>>against, the code can still be released and people
>>added as part of the other project.
>>
>
>If it is associated with another project. In Paul's case?
>
Yes, Avalon-Cornerstone uses AltRMI.
EOB (announced today and hosted at sourceforge) uses it.
>>>>In general, use by at least one jakarta project should
>>>>be a major factor in getting something in jakarta-commons.
>>>>
>>>And this is an interesting aspect : do you consider AltRMI a part of Avalon?
>>>
>>I don't know - I'm not an avalon commiter. If AltRMI solves a problem
>>for Avalon and avalon people would be interested to include the
>>code with avalon ( and that means support it, etc ) - then there's
>>no problem. They can do it right now, and they can add new commiters
>>easily in avalon and probably in commons, and they can even make
>>a release ( as an avalon component ), regardless of commons.
>>
>
>Agreed. But in this case, AltRMI is not a part of Avalon, as far as I can
>tell... Nor of commons...
>
True. It is a novel, standalone client-server tool. It obsoletes RMI.
Avalon can use it. Tomcat can use it any client/server or server/server
tool could use it for RPC.
Ho hum...
- Paul
Re: Adding a committer : Catch-22
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On 2/19/02 3:22 PM, "costinm@covalent.net" <co...@covalent.net> wrote:
> On Tue, 19 Feb 2002, Geir Magnusson Jr. wrote:
>
>>> IMHO commons is supposed to be a repository for code
>>> that is used by multiple jakarta projects - not
>>> a dump or a sourceforge-style repository where
>>> any cool idea can be implemented.
>>
>> Well, I remember the former as one of the drivers of the project, but the
>> latter is where we are.
>>
>> Commons-logging is an example - it was created entirely within commons.
>
> But with at least jakarta-struts and possibly other projects
> 'signed up' as users ( tomcat's j-t-c/jk will use it shortly, etc ).
>
I'm not arguing against it - but if commons is a place for things that are
part of other projects, you either must forget the chicken-egg problem and
let things start fresh in commons, or stand firm on a rule things must come
from a jakarta subproject.
I note that if you choose the latter, then the whole problem goes away, as
then there is no such thing as a 'commons committer', as they were a jakarta
committer in some other project first.
(I don't like that, BTW... Just pointing it out...)
> If a commons component is not used in any other jakarta project,
> what's the point and what does it have to do with the
> commons in the first place ?
It could be useful to developers in general, just like jakarta subprojects
are. That was one of my motivators, to have a place for things that are
smaller in scope than a jakarta subproject, but important enough to want to
avoid burying in a subproject.
> If you have something that is not curently needed in any
> project - the right solution is to request a new top-level
> project, not to dump it in commons as a workaround for
> the current rules.
Yes, if that's what is happening. Playing devil's advocate, wouldn't you
require it to be used in *more* than one project? Otherwise, why dump it
into commons if it's not shared?
>
>
>>> I don't see any catch-22 here - I think of sandbox as
>>> a ( common ) 'extension' to all jakarta projects.
>>> If a project is indeed usefull in at least a jakarta project
>>> ( or more ), and someone sends patches and contributions
>>> to that sandbox component, I'm sure the commiters from
>>> the jakarta project that is interested in the sandbox
>>> component can vote and make the contributor a commiter
>>> - either on the project or on commons.
>>
>> That works and solves the problem. However, it puts a restriction on
>> Commons we don't currently have.
>
> There is no restriction - commons is a jakarta project and the
> normal rules apply - vote, etc.
It does, actually, doesn't it? It means that things in the sandbox must be
associated with a Jakarta subproject. In Paul's case, is it Avalon or is it
Commons? No one in commons is participating in AltRMI (except Paul,
diligently) and no one in Avalon is either.
> What I'm saying is that if
> a sandbox or commons component is indeed usefull to another
> jakarta project, it's quite easy to get the review and votes
> that are needed ( since most jakarta projects have people
> who are in commons - or it's easy to get them in ).
But that isn't a commitment from anyone to work on and maintain the
component, which I think is an important factor to consider. Others don't
seem to care.
> Even in the unlikely event other commons people will vote
> against, the code can still be released and people
> added as part of the other project.
If it is associated with another project. In Paul's case?
>
>
>>> If the sandbox component doesn't have at least 3
>>> commiters and is not used by at least one jakarta project,
>>> I don't think it should be included in commons or
>>> get to add more commiters - there's not enoguh review
>>> nor interest.
>>
>> I agree up to the 'one jakarta project' bit, but only because I have gotten
>> used to the idea of standalone components, not that I disagree
>> fundamentally.
>
> Standalone components that are _used_ for something in jakarta.
>
I don't think that is a requirement, is it? And if it is, it's an empty
requirement - Unless you require that new components come from existing
codebases, all you have to do to meet it is claim that something will use
it Real Soon Now. If the requirement is that weak, why bother?
I guess a lot of my concerns are driven by weak and easily circumventable
requirements and 'guidelines'. If we want a "one huge codebase, all commit,
all vote, component subproject", then just dump the junk. I think that such
a thing will have problems over time, as Peter showed.
If you want to keep it based on ideas of 'those who do the work get to
choose' then somehow recognizing the contributors to the components has some
appeal.
But I won't go down this thread again. :)
>
>>> In general, use by at least one jakarta project should
>>> be a major factor in getting something in jakarta-commons.
>>
>> And this is an interesting aspect : do you consider AltRMI a part of Avalon?
>
> I don't know - I'm not an avalon commiter. If AltRMI solves a problem
> for Avalon and avalon people would be interested to include the
> code with avalon ( and that means support it, etc ) - then there's
> no problem. They can do it right now, and they can add new commiters
> easily in avalon and probably in commons, and they can even make
> a release ( as an avalon component ), regardless of commons.
>
Agreed. But in this case, AltRMI is not a part of Avalon, as far as I can
tell... Nor of commons...
--
Geir Magnusson Jr. geirm@optonline.net
System and Software Consulting
Age and treachery will always triumph over youth and talent
Re: Adding a committer : Catch-22
Posted by co...@covalent.net.
On Tue, 19 Feb 2002, Geir Magnusson Jr. wrote:
> > IMHO commons is supposed to be a repository for code
> > that is used by multiple jakarta projects - not
> > a dump or a sourceforge-style repository where
> > any cool idea can be implemented.
>
> Well, I remember the former as one of the drivers of the project, but the
> latter is where we are.
>
> Commons-logging is an example - it was created entirely within commons.
But with at least jakarta-struts and possibly other projects
'signed up' as users ( tomcat's j-t-c/jk will use it shortly, etc ).
If a commons component is not used in any other jakarta project,
what's the point and what does it have to do with the
commons in the first place ?
If you have something that is not curently needed in any
project - the right solution is to request a new top-level
project, not to dump it in commons as a workaround for
the current rules.
> > I don't see any catch-22 here - I think of sandbox as
> > a ( common ) 'extension' to all jakarta projects.
> > If a project is indeed usefull in at least a jakarta project
> > ( or more ), and someone sends patches and contributions
> > to that sandbox component, I'm sure the commiters from
> > the jakarta project that is interested in the sandbox
> > component can vote and make the contributor a commiter
> > - either on the project or on commons.
>
> That works and solves the problem. However, it puts a restriction on
> Commons we don't currently have.
There is no restriction - commons is a jakarta project and the
normal rules apply - vote, etc. What I'm saying is that if
a sandbox or commons component is indeed usefull to another
jakarta project, it's quite easy to get the review and votes
that are needed ( since most jakarta projects have people
who are in commons - or it's easy to get them in ).
Even in the unlikely event other commons people will vote
against, the code can still be released and people
added as part of the other project.
> > If the sandbox component doesn't have at least 3
> > commiters and is not used by at least one jakarta project,
> > I don't think it should be included in commons or
> > get to add more commiters - there's not enoguh review
> > nor interest.
>
> I agree up to the 'one jakarta project' bit, but only because I have gotten
> used to the idea of standalone components, not that I disagree
> fundamentally.
Standalone components that are _used_ for something in jakarta.
> > In general, use by at least one jakarta project should
> > be a major factor in getting something in jakarta-commons.
>
> And this is an interesting aspect : do you consider AltRMI a part of Avalon?
I don't know - I'm not an avalon commiter. If AltRMI solves a problem
for Avalon and avalon people would be interested to include the
code with avalon ( and that means support it, etc ) - then there's
no problem. They can do it right now, and they can add new commiters
easily in avalon and probably in commons, and they can even make
a release ( as an avalon component ), regardless of commons.
Costin
Re: Adding a committer : Catch-22
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On 2/19/02 2:46 PM, "costinm@covalent.net" <co...@covalent.net> wrote:
>
> IMHO commons is supposed to be a repository for code
> that is used by multiple jakarta projects - not
> a dump or a sourceforge-style repository where
> any cool idea can be implemented.
Well, I remember the former as one of the drivers of the project, but the
latter is where we are.
Commons-logging is an example - it was created entirely within commons.
>
> I don't see any catch-22 here - I think of sandbox as
> a ( common ) 'extension' to all jakarta projects.
> If a project is indeed usefull in at least a jakarta project
> ( or more ), and someone sends patches and contributions
> to that sandbox component, I'm sure the commiters from
> the jakarta project that is interested in the sandbox
> component can vote and make the contributor a commiter
> - either on the project or on commons.
That works and solves the problem. However, it puts a restriction on
Commons we don't currently have.
> If the sandbox component doesn't have at least 3
> commiters and is not used by at least one jakarta project,
> I don't think it should be included in commons or
> get to add more commiters - there's not enoguh review
> nor interest.
I agree up to the 'one jakarta project' bit, but only because I have gotten
used to the idea of standalone components, not that I disagree
fundamentally.
> In general, use by at least one jakarta project should
> be a major factor in getting something in jakarta-commons.
And this is an interesting aspect : do you consider AltRMI a part of Avalon?
--
Geir Magnusson Jr. geirm@optonline.net
System and Software Consulting
POC lives!
Re: Adding a committer : Catch-22
Posted by co...@covalent.net.
IMHO commons is supposed to be a repository for code
that is used by multiple jakarta projects - not
a dump or a sourceforge-style repository where
any cool idea can be implemented.
I don't see any catch-22 here - I think of sandbox as
a ( common ) 'extension' to all jakarta projects.
If a project is indeed usefull in at least a jakarta project
( or more ), and someone sends patches and contributions
to that sandbox component, I'm sure the commiters from
the jakarta project that is interested in the sandbox
component can vote and make the contributor a commiter
- either on the project or on commons.
If the sandbox component doesn't have at least 3
commiters and is not used by at least one jakarta project,
I don't think it should be included in commons or
get to add more commiters - there's not enoguh review
nor interest.
In general, use by at least one jakarta project should
be a major factor in getting something in jakarta-commons.
Costin
Re: Adding a committer : Catch-22
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On 2/19/02 2:01 PM, "vinaysahil chandran" <sa...@yahoo.com> wrote:
> Folks,
>> I like to share my knowledge and I like to learn
>> from you guys.
>> That's my motivation.
>
> You spoke right for me .
> I am pretty much happy contributing the way I have.
> Lets not create a aberration for some guy (v.i.z me:-)
>
> I would rather ^earn^ a *committer* status
> as laid down by the *rules*
> and not have it as a ^grant^.
No one was going to grant you anything. :)
The problem is that we have you in a bind - you want to participate in a
project that is forming - in the commons sandbox - and we need to provide a
fair playing field in which to do that.
--
Geir Magnusson Jr. geirm@optonline.net
System and Software Consulting
The question is : What is a Mahnamahna?
RE: Adding a committer : Catch-22
Posted by vinaysahil chandran <sa...@yahoo.com>.
Folks,
> I like to share my knowledge and I like to learn
> from you guys.
> That's my motivation.
You spoke right for me .
I am pretty much happy contributing the way I have.
Lets not create a aberration for some guy (v.i.z me:-)
I would rather ^earn^ a *committer* status
as laid down by the *rules*
and not have it as a ^grant^.
Regards,
V i n a y.
__________________________________________________
Do You Yahoo!?
Yahoo! Sports - Coverage of the 2002 Olympic Games
http://sports.yahoo.com
RE: Adding a committer : Catch-22
Posted by Gerhard Froehlich <g-...@gmx.de>.
Geir,
>So it comes down to 2 options, doesn't it?
>
>1) Vote on your new person to make him a committer in sandbox.
>
>2) Vote on your new person to make him a committer in commons.
Exactly, that's they way I introduced Jouzoas for the simplestore
project and he's doing well. I hope this was correct, because
he wasn't a jakarta-* committer before. But I think I mentioned
that...
Honestly otherwise I don't see any way to see commons grow.
For me there are two strategic possibilties:
1) Commons is a private Club *only* for Jakarta committers, which
earned that status in other Jakarta projects. But then this sissy
3 committer rule is unnecessary. This people are trusted
coders and hopefully they know what they are doing. One of you PMC
guys plays big brother and pay attention, that there is no wild
hacking and everybody is playing after the usual Jakarta rules.
Commons-Sandbox is kool for starting the draft and after a final
proposal for the first release, it's ready for commons. Do we need
another vote here? Sorry guys, but there are so many projects around
and honestly I can't observe them all. I have to do this selective
(interest and job driven)! And I have one golden rule, I don't vote
for things I don't know and I don't vote for committers I don't know.
Neither nor I do it just to fancy somebody.
Solution for #1 would be to close Jakarta-Commons for non Jakarta
committers and weaken the rules above. I think that would be a
realistic trade and I have no problem with that, really! Some of
us worked really hard to get their committer state, why not.
Apache was always something special under the OSS community. It is
professional led! It rules!
2) Commons is a public Club open for everybody and it has the same
process as every Jakarta project like Avalon, Struts, ... .
But now you have a problem. Normally it takes at least 3-6 month heavy
patch contributing until you become a committer in the other projects.
Especially the first time (like in live ;-)). After then, you
earned some respect, you're known in the community and things going
easier (Maybe I'm the only one, because my patches were to bad in the
beginning).
I personally like this, because people contributing with more ambition
and they are earning their status. Farther on you don't want, that everybody
gets this easy an @jakarta.org account. Kool I like this, but it doesn't
work for commons really! First of all, this 3 committer rule and then
the "you have to be Jakarta Committer" rule. What shall I do. Post to
every Jakarta list and advertise for the project. It doesn't work.
I understand why people don't show attention to my project, because
they aren't interested, are involved in much other things or don't
have the time. But then destiny got me and my project will stay in
commons-sandbox for ever. For me no problem, because I use it. But
somehow it's a pity that good projects get lost in the mass of contribution.
How to solve #2, close commons under Jakarta and start something
completly new under a special domain. Apache for *everybody* and
restrict this to the Apache License. But then you have to handle
with a mass of contibutions.
Or you allow *written*, that people can be voted as committers for
commons-sandbox and you deal with the fact that your @apache.org
members are increasing (is that bad?).
Ok but with which voting rules?
Personally I prefer #1 and #2, because I like coding and for me
it doesn't play any role if this is in commons or commons-sandbox.
I like to share my knowledge and I like to learn from you guys.
That's my motivation.
But things here are going to be a farce and that's dangerous!
Make a clear statement and clear rules!
Sorry for being a little bit rude, but it's really weird here.
(apologies bad english)
~Gerhard
*---------------------------------------------------------*
| Contrary to popular belief, UNIX is user-friendly. It |
| just happens to be selective on who it makes friendship |
| with. |
| - Richard Cook |
*---------------------------------------------------------*
Re: Adding a committer : Catch-22
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On 2/19/02 3:27 AM, "Paul Hammant" <Pa...@yahoo.com> wrote:
> Folks,
>
> I am trying to add a committer to commons-sandbox/altrmi. The fellow in
> question is heavily involved with "Enterprise Object Broker" hosted at
> sourceforge which uses AltRMI.
>
> The commons charter, at present, does not allow for a person to be added
> who is not currently a jakarta-* committer.
>
> I need advise, because it seems to be this is insolvable.
>
I agree, and this is my POV as well.
When you proposed to make AltRMI a commons component, I suggested that you
get two more committers, as the Jakarta guidelines suggest that 3 committers
are required to add a new sourcebase. The spirit of this, as I understand
it, is to make sure that there are 3 interested, dedicated people behind a
codebase ("active, involved developers") to ensure the life of it in case
one person stops working on it.
Of course in commons, the charter is vague, and we can appeal to a whole set
of non-binding guidelines to hand-wave this issue away, but I don't think we
should do that.
Now, since then, I have watched you, Paul, work diligently on AltRMI with no
loss of focus, and I have to say I am impressed. I also believe that you
aren't trivially trying to add this person just to get committers. I
*really* respect that, as you could have just gotten two others and claimed
they were committers.
Now, the commons charter says nothing about not allowing a person to be
added who isn't a jakarta-* committer. It states, if it really matters -
"The subproject will host a CVS repository available to all Jakarta
committers as a workplace for new packages or other projects."
It does not have any language pertaining to exclusion.
(aside : read the next line - "Before release to the public, code or
documentation developed here must be sponsored by a Jakarta subproject."
There's a weird one...)
Anyhow, believe it or not, I also agree with Ted about the importance of
making sure that being a Jakarta committer means something.
Still, I feel that the sandbox is a great way to introduce people to the
jakarta community - I mean, they are 'harmless' there. I think making a
mistake and adding a committer to sandbox is much easier to deal with than
adding to commons, due to our "commit one, commit all" policy.
So it comes down to 2 options, doesn't it?
1) Vote on your new person to make him a committer in sandbox.
2) Vote on your new person to make him a committer in commons.
The status of AltRMI would only be relevant here because as a component, we
still would then have to vote on your committer, and as a commons committer.
If we do allow sandbox committers, then we can indeed see if the person
really is interested and dedicated, and when AltRMI comes over the fence,
you can with confidence bring committers you know are, well, committed :)
I don't know how to make everyone happy here :)
My 0.02
geir
--
Geir Magnusson Jr. geirm@optonline.net
System and Software Consulting
"Now what do we do?"