You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by "Geir Magnusson Jr." <ge...@apache.org> on 2005/07/13 04:42:22 UTC
Close to completion? (Re: Is it a mountain? (Re: Donation of Admin Console- request for help))
Lets start a new thread tomorrow, finish discussion since I suspect
that all that will say their peace have done so, and work out a vote?
I suspect we need to decide :
1) do we need to have any policy?
2) If so, decide the
a) general committer acceptance policy/guidelines to define some
sensible, fair, transparent metrics for accepting a committer
such as
- how long a person must commit patches
- how long participate on the mailing lists
b) general code acceptance policy (what we have been discussing here)
where the options include
- bring into SVN, grant committer status to some # of people
- bring into SVN, grant restricted status to some # of people
- bring into SVN, follow a) above for people
- none of the above
I think that "bring to incubator" is not in scope for this vote, as
it's a tool we already have now - we can always do that and decide to
sponsor or just participate, but at the end of that process, then the
code contribution b) rules should apply.
geir
On Jul 12, 2005, at 7:50 PM, Aaron Mulder wrote:
> Well, I was going to start a new thread, but it seems Alan doesn't
> like that, so...
>
> Would it be accurate to say that the options on the table for
> donated code are:
>
> 1) Bring (project X) to geronimo, grant full commit status to (some
> number
> of people) who have worked with the code before
>
> 2) Bring project X to geronimo, put in a clearly separate SVN area,
> grant restricted commit status (via ACL or explicit direction) to some
> number of people who have worked with the code before
>
> 3) Bring project X to the incubator, mix outside people and
> potentially
> Geronimo people to form a new project team
>
> It's clear that there's a variety of opinions as to which of these
> is preferable, and potentially which is most preferable for the web
> console vs the ORB.
>
> Aaron
>
> On Tue, 12 Jul 2005, David Blevins wrote:
>
>> On Tue, Jul 12, 2005 at 07:17:44PM -0400, Davanum Srinivas wrote:
>>
>>> It's a judgement call i guess. i have not been on the calls. If you
>>> guys feel that it can support its own eco-system. then thats fine.
>>>
>>>
>>
>> I don't know yet, myself. But certainly one cannot deny there are
>> more CORBA specs than Web Services specs (for a while anyway); not
>> exactly the same deal as a web console.
>>
>> -David
>>
>>
>>> On 7/12/05, David Blevins <da...@visi.com> wrote:
>>>
>>>> On Tue, Jul 12, 2005 at 06:58:20PM -0400, Davanum Srinivas wrote:
>>>>
>>>>> It's just that the piece of code we are talking about in both
>>>>> cases,
>>>>> seem un-usable w/o geronimo.
>>>>>
>>>>
>>>> Is that really true? We are talking about a compliant ORB
>>>> aren't we?
>>>>
>>>> -David
>>>>
>>>>
>>>
>>>
>>> --
>>> Davanum Srinivas -http://blogs.cocoondev.org/dims/
>>>
>>
>>
>
>
--
Geir Magnusson Jr +1-203-665-6437
geirm@apache.org
Re: Close to completion? (acl policy questions)
Posted by "Geir Magnusson Jr." <ge...@apache.org>.
I'll be a good little fishy, as I think this is important. I'm
keeping the following in mind from a recent post by David Jencks as I
go through the list :
"I'd like to reemphasize that bringing in new committers with their
code is going to be a lot of work for the existing community. If we
fail to integrate a donation a very large part of the responsibility
rests with us for not having good enough community skills to work
with the newcomers. It seems to me that discussions about limited
commit access/ acls/ etc are fundamentally discussions about what
happens if we fail. I wonder what would happen if we instead
discussed how we will provide superb support and mentoring for our
new members and left the questions of what to do if we fail to such
time as it might be needed."
On Jul 13, 2005, at 2:37 PM, David Blevins wrote:
> If you vote for this, no complaining later -- you eat your own dog
> food.
If you vote for anything, and we don't like it, we change it. We
aren't bending re-bar and pouring cement...
>
>
> ----------------------------------------------------------
> NOTE: I apologize in advance for using the words
> "incubation", "incubating", "incubated", and finally
> "incubator".
Why didn't you just avoid using it then? We're not creating an
incubator. We're trying to bring in code, add committers and build
*our* community.
[SNIP]
>
> Do ACLs extend to things like:
> - websites
> - documentation (possibly donated as well)
> - QA
> - project management
>
If we want them to, and I think we want them to. The goal here is
Geronimo project participation, not "off in the corner" participation.
>
> What is the policy on how this affects voting?
> - Can a restricted committer -1 a change made by a non-restricted
> committer
In the code they are working on? Yes because the "non-restricted
committer" will have karma to the "restricted" svn repo.
> - Does a restricted committer get a binding vote on the code to
> which they have access?
yes
> - Does a restricted committer have a binding vote to code to which
> they do not have access?
No
> - Does a restricted committer have a binding vote on non-technical
> issues?
That's an interesting question to think about, and I think my answer
is yes, again because it's about growing project participation.
To explain, I want to object to the lingo of "restricted committer"
vs "non-restricted committer". I think of as "committer to Geronimo
main SVN" vs "committer to Geronimo $foo SVN"
So yes. And I think that for code being brought into Geronimo
project (even in a $foo SVN) would mean that all committers to
Geronimo main SVN have commit to $foo SVN so that
a) we have PMC oversight
b) we have full interaction and participation
>
>
For the following, I'll assume "incubating" means "code in Geronimo
$foo repository" where $foo != main
> New committers:
> - Does an existing ASF committer contributing to the incubating
> code get restricted commit?
Like someone from httpd? No.
> - Does an existing ASF committer contributing to the incubating
> code and some to other code get full commit?
No - I assume you mean some arbitrary committer from Jakarta or -ish?
> - Does an employee of the donor contributing to the incubating
> code get restricted commit?
Any arbitrary employee? of course not. I would assume we'd craft
some guideline asking the donor to list the humans that worked on the
code and wish to continue.
Note that "donor" isn't necessarily an entity with employees - for
example, if hypothetically something like MX4J decided to come to
Geronimo...
> - Does an employee of the donor contributing to the incubating
> code and some to other code get full commit?
do you mean "if a person that is working on the code in the Geronimo
$foo repository starts contributing to the Geronimo main repository,
do we offer them commit"? yes, at some point, which I assume is
going to be *way* accelerated because they've been working right in
the community all long on stuff that's part of the community.
> - Does an unknown community member contributing to the incubating
> code get restricted commit?
> - Does an unknown community member contributing to the incubating
> code and some to other code get full commit?
If someone starts posting patches to the Geronimo $foo repo, and we
feel that they meet our criterion for offered commit access,yes, lets
offer them commit access to the Geronimo $foo repository.
> - Will there be an advantage to *not* contributing to the
> incubating code as to avoid getting voted in as a restricted
> committer.
I don't get it.
When I think of "restricted ACL" I think of simply setting up another
repository with a different group of committers, that includes all
the committers from the main [current] repository, along with the
people that want to keep working on their donation with us.
If a "restricted ACL" repo is a place where someone wants to
contribute, lets let them earn commit status there if they didn't
come with the code...
>
>
> Releasing:
> - Can code being Geronimo incubated be distributed in our unstable
> builds?
> - Can code being Geronimo incubated be distributed in official
> releases?
> - Can code being Geronimo incubated be certified and distributed
> in a certified release?
Being there is no incubation, I'd say "yes" to all of these questions
- at all times the main repository committers are committers on the
$foo respoitory, the PMC has full responsibility and oversight, etc.
If there is no one but the donor committers working on the codebase
here, it shouldn't be here. Either this is stuff we work on with
them, or they can be elswhere. We're not an incubator.
>
>
> Management and dynamics:
> - Can we handle having 2 or 3 more donations in addition to the
> two we plan?
It certainly will be easier with more people. it's up to us to gauge
who and what we bring in. You have a good point here - we must
always consider the load on the existing committers for anything like
this that we do. Making commitments means making commitments - doing
it elsewhere just leaves less time for here.
> - Is is possible that the number of active restricted committers
> outnumbers the active fully privileged committers?
Anything is possible, and I think that would mean we weren't paying
attention to what you pointed out above. If we do this, it's our error.
And I think that it's not the end of the world if it happens, as if G
is the set of all committers in the main geronimo repo and C is the
new people that want to come and work on console then
C' is the set of commiters in the console repo
C' = G + C
assume the same for Trifork (see, got the case of the "F" right...
sorry about my previous errors...)
T' = G + T
> - How much time are you willing to dedicate in a week to managing
> issues, documenting guidelines and general Apache Way mentoring?
meaning, working with others in the community? I seem to put in a
bit of time now. I know if I didn't have to spend the time on this
subject, I'd have oodles of free hours :)
> - Will we be open to assistance from experienced ASF people
> willing to assist in managing issues, documenting guidelines and
> general Apache Way mentoring?
We always are. But we're not doing an incubator.
> - Would they get a binding vote?
No.
> - Would they get and be welcome to use commit privileges?
Interesting question :) In some places at the ASF, being an existing
ASF committer is a huge step towards commit if you are known, but
lets not go there in this thread.
>
>
> PMC:
> - Can a restricted committer join the Geronimo PMC?
I'd like to avoid this. If a person has been around such that we
believe they deserve to be on the PMC, we trust them with commit to
main repo, and if peeps like that have been around, we should be just
integrating the pile of people into the main tree anyway?
> - Can a person under a documentation ACL join the PMC?
> - Can a person under a management ACL join the PMC?
I don't know what a "management ACL" is, but for the same reasons as
above...
The model I'm worried about is the Jakarta model, which was having
committers from the various subprojects (a reasonable analogy -
different CVS roots with separate ACLs for each root) be on the PMC
in a limited way. That gave PMC oversight officially, as if there
were 3 committers from Jakarta Wombat that voted +1 on a release,
because they were on the PMC, that provided the necessary minimum
legal requirement.
We *may* be able to do this if we start from scratch with the goal
that *every* committer should be on the PMC, and that the "restricted
ACL" is just an internal management feature of code access.
I could easily talk myself into this, but we'd have to be very clear
from the get-go that we will work to have everyone on the PMC (which
is our goal now, btw) and people should have the good manners and
common sense to abstain from voting on things they aren't a part of.
>
>
> Moving Up:
> - What is the criteria for leaving the Geronimo incubator?
There is no Geronimo incubator.
I see it as the question of "when can and how do we combine these
repos"?
> - Is it acceptable to take half or less of the code?
Sure
> - How is this consensus reached, public vote or private vote?
public
> - How do restricted committers become full committers?
"How does someone w/o commit access to the main Geronimo repository
get commit access?" ? I don't see us having special rules - if we
believe the person does good work, is committed, etc, then we vote
that person in as committer.
Our guidelines for committer access apply to any repo. There are no
special "Geronimo incubator" rules.
> - If a donation moves to full status, are the restrictions of all
> committers working on that code removed?
Again, in my mental model, it's not about restriction but commit in
other parts of our multi-repo SVN.
> - Are these people free to vote on matters of other donated code?
I don't grok
>
>
> Moving Out:
> - Is it possible to remove a project from incubation and not
> accept it as a part of Geronimo?
There is no Geronimo incubation.
But yes, we've had sandbox code that we never used, and just threw it
out. Not a new issue.
> - How long will donors have to wait to get this answer?
Huh?
> - On what basis will the PMC vote on removing a project?
I assume that there's all sorts of factors that will come up.
>
> - Is that a public or private vote?
if it's technology, public. if there's people issues involved, private.
> - Is it possible to remove all commit access for a restricted
> committer.
of course. it's possible to remove all commit access for any committer
> - On what basis will the PMC vote on removing all commit access?
For the same reasons that I would now - gross breach of trust,
prolonged inactivity, etc
> - Is that a public or private vote?
Private. It's a person.
>
>
> Potential fairness issues:
> - Donor X gets in the incubator in March, donor Y gets in the
> incubator two months later. Sometime later, the PMC votes to
> graduate donor Y's code. Do we graduate X as well? If not, do we
> owe X and explanation of why they aren't being graduated?
Oh, I see. Because there is no Geronimo incubator... Let me rephrase :
Donor X gets a contribution accepted into repoX in March and begins
working. Donor Y gets a contribution accepted into repoY and begins
working. At some point, the community votes to combine the code from
repoY into repoMain. X and repoX keep doing their thing. They are
all independent.
Because there is no Geronimo incubator, there is nothing to
"graduate" from. If it makes technological or other sense to move
things around, we do it.
> - Adam and Jack are restricted committers from donor ABC. Jack is
> voted in as a full committer. Do we vote in Adam as well? If not,
> do we owe Adam an explanation of why?
I assume that Jack was contributing to mainRepo and it was time to
give him access? Or do you mean that repoABC is combined with
repoMain? In the latter case, I think that not taking all the people
would be an extreme corner case and would have to deal with
individually.
(Note - there's a similar problem if we went and sponsored something
in the Apache Incubator to incorporate into Geronimo - at that point,
each committer would have to earn commit status independently, so you
could have the situation where we fractured that community ... :/ )
> - Bill and Ben are restricted committers from donor QRS. Bill and
> Ben are having a hard time getting really involved. Eric is an
> Apache committer from another project who started working with the
> donated code and was made a restricted committer. The PMC decides
> to vote Eric in as a full Geronimo committer. Do we make Bill and
> Ben full committers as well? If no, how do we handle Bill and
> Ben's expectations?
Be honest and up front with them? I think that this is a corner
case, and self-solving. If they aren't involved, why would they care?
Whew! Happy to get through that before my meeting starts.
Just to recap the model I'm thinking of is a set of additional repos
besides the "main" Geronimo repo that has the committer set denoted
as G. Each non-main repo has a committer set that is G + additions
that either came with a donation (if that's how it started) or people
that wanted to participate in that part of our world and earned commit.
There is no "graduation" - there is combining technology when and if
it makes sense, and granting further commit when and if it makes
sense for a person.
The key is that all would be part of the same community, working
together. I expect that if we did something like this, a trusted
person X with commit rights to repoX that wanted to work on repoY
would be subject to a quick vote and given access.
My only concern is how to really ensure that we have no balkanization
of the community. I think we saw it happen in Jakarta as it really
grew, and the things to avoid are partitioned dev lists, for one, and
not working as hard as possible to get all committers on the PMC from
day 0. (I'm not criticizing Jakarta - I think it has been
phenomenally successful in many ways, and we just need to learn from
their groundbreaking efforts.)
Thanks for the thought-provoking questions.
geir
--
Geir Magnusson Jr +1-203-665-6437
geirm@apache.org
Re: Close to completion? (acl policy questions)
Posted by David Blevins <da...@visi.com>.
If you vote for this, no complaining later -- you eat your own dog food.
----------------------------------------------------------
NOTE: I apologize in advance for using the words
"incubation", "incubating", "incubated", and finally
"incubator". The word "sandbox" is not a verb and really
hard to use as one, nor could I think of another verb.
Sorry, sorry, sorry. Please, please, please try and focus
on the content in the questions.
----------------------------------------------------------
Do ACLs extend to things like:
- websites
- documentation (possibly donated as well)
- QA
- project management
What is the policy on how this affects voting?
- Can a restricted committer -1 a change made by a non-restricted committer
- Does a restricted committer get a binding vote on the code to which they have access?
- Does a restricted committer have a binding vote to code to which they do not have access?
- Does a restricted committer have a binding vote on non-technical issues?
New committers:
- Does an existing ASF committer contributing to the incubating code get restricted commit?
- Does an existing ASF committer contributing to the incubating code and some to other code get full commit?
- Does an employee of the donor contributing to the incubating code get restricted commit?
- Does an employee of the donor contributing to the incubating code and some to other code get full commit?
- Does an unknown community member contributing to the incubating code get restricted commit?
- Does an unknown community member contributing to the incubating code and some to other code get full commit?
- Will there be an advantage to *not* contributing to the incubating code as to avoid getting voted in as a restricted committer.
Releasing:
- Can code being Geronimo incubated be distributed in our unstable builds?
- Can code being Geronimo incubated be distributed in official releases?
- Can code being Geronimo incubated be certified and distributed in a certified release?
Management and dynamics:
- Can we handle having 2 or 3 more donations in addition to the two we plan?
- Is is possible that the number of active restricted committers outnumbers the active fully privileged committers?
- How much time are you willing to dedicate in a week to managing issues, documenting guidelines and general Apache Way mentoring?
- Will we be open to assistance from experienced ASF people willing to assist in managing issues, documenting guidelines and general Apache Way mentoring?
- Would they get a binding vote?
- Would they get and be welcome to use commit privileges?
PMC:
- Can a restricted committer join the Geronimo PMC?
- Can a person under a documentation ACL join the PMC?
- Can a person under a management ACL join the PMC?
Moving Up:
- What is the criteria for leaving the Geronimo incubator?
- Is it acceptable to take half or less of the code?
- How is this consensus reached, public vote or private vote?
- How do restricted committers become full committers?
- If a donation moves to full status, are the restrictions of all committers working on that code removed?
- Are these people free to vote on matters of other donated code?
Moving Out:
- Is it possible to remove a project from incubation and not accept it as a part of Geronimo?
- How long will donors have to wait to get this answer?
- On what basis will the PMC vote on removing a project?
- Is that a public or private vote?
- Is it possible to remove all commit access for a restricted committer.
- On what basis will the PMC vote on removing all commit access?
- Is that a public or private vote?
Potential fairness issues:
- Donor X gets in the incubator in March, donor Y gets in the incubator two months later. Sometime later, the PMC votes to graduate donor Y's code. Do we graduate X as well? If not, do we owe X and explanation of why they aren't being graduated?
- Adam and Jack are restricted committers from donor ABC. Jack is voted in as a full committer. Do we vote in Adam as well? If not, do we owe Adam an explanation of why?
- Bill and Ben are restricted committers from donor QRS. Bill and Ben are having a hard time getting really involved. Eric is an Apache committer from another project who started working with the donated code and was made a restricted committer. The PMC decides to vote Eric in as a full Geronimo committer. Do we make Bill and Ben full committers as well? If no, how do we handle Bill and Ben's expectations?
Re: Close to completion? (Re: Is it a mountain? (Re: Donation of Admin Console- request for help))
Posted by "Geir Magnusson Jr." <ge...@apache.org>.
On Jul 12, 2005, at 10:58 PM, Aaron Mulder wrote:
> Well, can we have a separate vote for what to do with the web
> console? I thought it was ready (or nearly so) and I don't want to
> hold
> up the contribution for some of the unrelated items on your list.
I was hoping that we could just define the guidelines first, and then
apply it to the web console as our first use.
>
> (break)
>
> As for your list, are you saying that a vote for new code going to
> the incubator must necessarily be cast as a "we don't need a
> policy" vote
> for 1 (since "it's a tool we already have now - we can always do
> that")?
> I don't think that's entirely reasonable. A policy of sending
> donations
> to the incubator is still a policy. Whatever, I guess I'm OK voting
> against policy.
Ok - I see. I think of it as something we have always had the
ability to do, so it's not a decision on what we do *here*. So if we
choose to always send to the incubator, we haven't actually done
anything, and leave open the question of what to do when it comes out
of incubator :)
>
> Also, I thought we were going to try to avoid votes on things that
> haven't been discussed. Where did the metrics for accepting a
> committer
> topic come from?
That's why I left it open and didn't call for a vote, and I thought
posed them as suggestions - starters for a conversation. I think we
need a good rule of thumb "guideline" for potential committers so
they know what to expect.
No worries.
geir
>
> Aaron
>
> On Tue, 12 Jul 2005, Geir Magnusson Jr. wrote:
>
>> Lets start a new thread tomorrow, finish discussion since I suspect
>> that all that will say their peace have done so, and work out a vote?
>>
>> I suspect we need to decide :
>>
>> 1) do we need to have any policy?
>>
>> 2) If so, decide the
>>
>> a) general committer acceptance policy/guidelines to define some
>> sensible, fair, transparent metrics for accepting a committer
>> such as
>> - how long a person must commit patches
>> - how long participate on the mailing lists
>>
>> b) general code acceptance policy (what we have been discussing
>> here)
>> where the options include
>> - bring into SVN, grant committer status to some # of people
>> - bring into SVN, grant restricted status to some # of people
>> - bring into SVN, follow a) above for people
>> - none of the above
>>
>> I think that "bring to incubator" is not in scope for this vote, as
>> it's a tool we already have now - we can always do that and decide to
>> sponsor or just participate, but at the end of that process, then the
>> code contribution b) rules should apply.
>>
>> geir
>>
>>
>> On Jul 12, 2005, at 7:50 PM, Aaron Mulder wrote:
>>
>>
>>> Well, I was going to start a new thread, but it seems Alan
>>> doesn't
>>> like that, so...
>>>
>>> Would it be accurate to say that the options on the table for
>>> donated code are:
>>>
>>> 1) Bring (project X) to geronimo, grant full commit status to (some
>>> number
>>> of people) who have worked with the code before
>>>
>>> 2) Bring project X to geronimo, put in a clearly separate SVN area,
>>> grant restricted commit status (via ACL or explicit direction) to
>>> some
>>> number of people who have worked with the code before
>>>
>>> 3) Bring project X to the incubator, mix outside people and
>>> potentially
>>> Geronimo people to form a new project team
>>>
>>> It's clear that there's a variety of opinions as to which of
>>> these
>>> is preferable, and potentially which is most preferable for the web
>>> console vs the ORB.
>>>
>>> Aaron
>>>
>>> On Tue, 12 Jul 2005, David Blevins wrote:
>>>
>>>
>>>> On Tue, Jul 12, 2005 at 07:17:44PM -0400, Davanum Srinivas wrote:
>>>>
>>>>
>>>>> It's a judgement call i guess. i have not been on the calls. If
>>>>> you
>>>>> guys feel that it can support its own eco-system. then thats fine.
>>>>>
>>>>>
>>>>>
>>>>
>>>> I don't know yet, myself. But certainly one cannot deny there are
>>>> more CORBA specs than Web Services specs (for a while anyway); not
>>>> exactly the same deal as a web console.
>>>>
>>>> -David
>>>>
>>>>
>>>>
>>>>> On 7/12/05, David Blevins <da...@visi.com> wrote:
>>>>>
>>>>>
>>>>>> On Tue, Jul 12, 2005 at 06:58:20PM -0400, Davanum Srinivas wrote:
>>>>>>
>>>>>>
>>>>>>> It's just that the piece of code we are talking about in both
>>>>>>> cases,
>>>>>>> seem un-usable w/o geronimo.
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> Is that really true? We are talking about a compliant ORB
>>>>>> aren't we?
>>>>>>
>>>>>> -David
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Davanum Srinivas -http://blogs.cocoondev.org/dims/
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>> --
>> Geir Magnusson Jr +1-203-665-6437
>> geirm@apache.org
>>
>>
>>
>>
>
>
--
Geir Magnusson Jr +1-203-665-6437
geirm@apache.org
Re: Close to completion? (Re: Is it a mountain? (Re: Donation of
Admin Console- request for help))
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
Well, can we have a separate vote for what to do with the web
console? I thought it was ready (or nearly so) and I don't want to hold
up the contribution for some of the unrelated items on your list.
(break)
As for your list, are you saying that a vote for new code going to
the incubator must necessarily be cast as a "we don't need a policy" vote
for 1 (since "it's a tool we already have now - we can always do that")?
I don't think that's entirely reasonable. A policy of sending donations
to the incubator is still a policy. Whatever, I guess I'm OK voting
against policy.
Also, I thought we were going to try to avoid votes on things that
haven't been discussed. Where did the metrics for accepting a committer
topic come from?
Aaron
On Tue, 12 Jul 2005, Geir Magnusson Jr. wrote:
> Lets start a new thread tomorrow, finish discussion since I suspect
> that all that will say their peace have done so, and work out a vote?
>
> I suspect we need to decide :
>
> 1) do we need to have any policy?
>
> 2) If so, decide the
>
> a) general committer acceptance policy/guidelines to define some
> sensible, fair, transparent metrics for accepting a committer
> such as
> - how long a person must commit patches
> - how long participate on the mailing lists
>
> b) general code acceptance policy (what we have been discussing here)
> where the options include
> - bring into SVN, grant committer status to some # of people
> - bring into SVN, grant restricted status to some # of people
> - bring into SVN, follow a) above for people
> - none of the above
>
> I think that "bring to incubator" is not in scope for this vote, as
> it's a tool we already have now - we can always do that and decide to
> sponsor or just participate, but at the end of that process, then the
> code contribution b) rules should apply.
>
> geir
>
>
> On Jul 12, 2005, at 7:50 PM, Aaron Mulder wrote:
>
> > Well, I was going to start a new thread, but it seems Alan doesn't
> > like that, so...
> >
> > Would it be accurate to say that the options on the table for
> > donated code are:
> >
> > 1) Bring (project X) to geronimo, grant full commit status to (some
> > number
> > of people) who have worked with the code before
> >
> > 2) Bring project X to geronimo, put in a clearly separate SVN area,
> > grant restricted commit status (via ACL or explicit direction) to some
> > number of people who have worked with the code before
> >
> > 3) Bring project X to the incubator, mix outside people and
> > potentially
> > Geronimo people to form a new project team
> >
> > It's clear that there's a variety of opinions as to which of these
> > is preferable, and potentially which is most preferable for the web
> > console vs the ORB.
> >
> > Aaron
> >
> > On Tue, 12 Jul 2005, David Blevins wrote:
> >
> >> On Tue, Jul 12, 2005 at 07:17:44PM -0400, Davanum Srinivas wrote:
> >>
> >>> It's a judgement call i guess. i have not been on the calls. If you
> >>> guys feel that it can support its own eco-system. then thats fine.
> >>>
> >>>
> >>
> >> I don't know yet, myself. But certainly one cannot deny there are
> >> more CORBA specs than Web Services specs (for a while anyway); not
> >> exactly the same deal as a web console.
> >>
> >> -David
> >>
> >>
> >>> On 7/12/05, David Blevins <da...@visi.com> wrote:
> >>>
> >>>> On Tue, Jul 12, 2005 at 06:58:20PM -0400, Davanum Srinivas wrote:
> >>>>
> >>>>> It's just that the piece of code we are talking about in both
> >>>>> cases,
> >>>>> seem un-usable w/o geronimo.
> >>>>>
> >>>>
> >>>> Is that really true? We are talking about a compliant ORB
> >>>> aren't we?
> >>>>
> >>>> -David
> >>>>
> >>>>
> >>>
> >>>
> >>> --
> >>> Davanum Srinivas -http://blogs.cocoondev.org/dims/
> >>>
> >>
> >>
> >
> >
>
> --
> Geir Magnusson Jr +1-203-665-6437
> geirm@apache.org
>
>
>
Re: Close to completion? (Re: Is it a mountain? (Re: Donation of Admin Console- request for help))
Posted by "Geir Magnusson Jr." <ge...@apache.org>.
On Jul 12, 2005, at 10:52 PM, Jeff Genender wrote:
> 1) -1. Guidelines are good, policy can be bad.
yes - guidelines captures what I meant. (I think of policy being the
same, but I can see how others don't...)
> 2a) IMHO...This will be hard to guage and form metrics. This is
> subjective...since I think quality of participation plays to a certain
> degree. Is this necessary? Can't we continue as we have (or has this
> proven to be negative)?
I'd prefer to have a set of guidelines to make it clear to everyone
how we operate, and limit the chance that either we play favorites,
or are accused of doing so.
>
> 2b) +1 for "bring into SVN, grant restricted status to some # of
> people"
> because obviously it needs to be worked on by the authors to a certain
> degree.
>
> Jeff
>
> -----Original Message-----
> From: Geir Magnusson Jr. [mailto:geirm@apache.org]
> Sent: Tuesday, July 12, 2005 8:42 PM
> To: dev@geronimo.apache.org
> Subject: Close to completion? (Re: Is it a mountain? (Re: Donation
> of Admin
> Console- request for help))
>
> Lets start a new thread tomorrow, finish discussion since I suspect
> that all
> that will say their peace have done so, and work out a vote?
>
> I suspect we need to decide :
>
> 1) do we need to have any policy?
>
> 2) If so, decide the
>
> a) general committer acceptance policy/guidelines to define some
> sensible, fair, transparent metrics for accepting a committer
> such as
> - how long a person must commit patches
> - how long participate on the mailing lists
>
> b) general code acceptance policy (what we have been discussing
> here)
> where the options include
> - bring into SVN, grant committer status to some # of people
> - bring into SVN, grant restricted status to some # of people
> - bring into SVN, follow a) above for people
> - none of the above
>
> I think that "bring to incubator" is not in scope for this vote, as
> it's a
> tool we already have now - we can always do that and decide to
> sponsor or
> just participate, but at the end of that process, then the code
> contribution
> b) rules should apply.
>
> geir
>
>
> On Jul 12, 2005, at 7:50 PM, Aaron Mulder wrote:
>
>
>> Well, I was going to start a new thread, but it seems Alan
>> doesn't
>> like that, so...
>>
>> Would it be accurate to say that the options on the table for
>> donated code are:
>>
>> 1) Bring (project X) to geronimo, grant full commit status to (some
>> number of people) who have worked with the code before
>>
>> 2) Bring project X to geronimo, put in a clearly separate SVN area,
>> grant restricted commit status (via ACL or explicit direction) to
>> some
>> number of people who have worked with the code before
>>
>> 3) Bring project X to the incubator, mix outside people and
>> potentially Geronimo people to form a new project team
>>
>> It's clear that there's a variety of opinions as to which of
>> these
>> is preferable, and potentially which is most preferable for the web
>> console vs the ORB.
>>
>> Aaron
>>
>> On Tue, 12 Jul 2005, David Blevins wrote:
>>
>>
>>> On Tue, Jul 12, 2005 at 07:17:44PM -0400, Davanum Srinivas wrote:
>>>
>>>
>>>> It's a judgement call i guess. i have not been on the calls. If you
>>>> guys feel that it can support its own eco-system. then thats fine.
>>>>
>>>>
>>>>
>>>
>>> I don't know yet, myself. But certainly one cannot deny there are
>>> more CORBA specs than Web Services specs (for a while anyway); not
>>> exactly the same deal as a web console.
>>>
>>> -David
>>>
>>>
>>>
>>>> On 7/12/05, David Blevins <da...@visi.com> wrote:
>>>>
>>>>
>>>>> On Tue, Jul 12, 2005 at 06:58:20PM -0400, Davanum Srinivas wrote:
>>>>>
>>>>>
>>>>>> It's just that the piece of code we are talking about in both
>>>>>> cases, seem un-usable w/o geronimo.
>>>>>>
>>>>>>
>>>>>
>>>>> Is that really true? We are talking about a compliant ORB aren't
>>>>> we?
>>>>>
>>>>> -David
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Davanum Srinivas -http://blogs.cocoondev.org/dims/
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>>
>
> --
> Geir Magnusson Jr +1-203-665-6437
> geirm@apache.org
>
>
>
>
--
Geir Magnusson Jr +1-203-665-6437
geirm@apache.org
RE: Close to completion? (Re: Is it a mountain? (Re: Donation of Admin Console- request for help))
Posted by Jeff Genender <jg...@savoirtech.com>.
1) -1. Guidelines are good, policy can be bad.
2a) IMHO...This will be hard to guage and form metrics. This is
subjective...since I think quality of participation plays to a certain
degree. Is this necessary? Can't we continue as we have (or has this
proven to be negative)?
2b) +1 for "bring into SVN, grant restricted status to some # of people"
because obviously it needs to be worked on by the authors to a certain
degree.
Jeff
-----Original Message-----
From: Geir Magnusson Jr. [mailto:geirm@apache.org]
Sent: Tuesday, July 12, 2005 8:42 PM
To: dev@geronimo.apache.org
Subject: Close to completion? (Re: Is it a mountain? (Re: Donation of Admin
Console- request for help))
Lets start a new thread tomorrow, finish discussion since I suspect that all
that will say their peace have done so, and work out a vote?
I suspect we need to decide :
1) do we need to have any policy?
2) If so, decide the
a) general committer acceptance policy/guidelines to define some
sensible, fair, transparent metrics for accepting a committer
such as
- how long a person must commit patches
- how long participate on the mailing lists
b) general code acceptance policy (what we have been discussing here)
where the options include
- bring into SVN, grant committer status to some # of people
- bring into SVN, grant restricted status to some # of people
- bring into SVN, follow a) above for people
- none of the above
I think that "bring to incubator" is not in scope for this vote, as it's a
tool we already have now - we can always do that and decide to sponsor or
just participate, but at the end of that process, then the code contribution
b) rules should apply.
geir
On Jul 12, 2005, at 7:50 PM, Aaron Mulder wrote:
> Well, I was going to start a new thread, but it seems Alan doesn't
> like that, so...
>
> Would it be accurate to say that the options on the table for
> donated code are:
>
> 1) Bring (project X) to geronimo, grant full commit status to (some
> number of people) who have worked with the code before
>
> 2) Bring project X to geronimo, put in a clearly separate SVN area,
> grant restricted commit status (via ACL or explicit direction) to some
> number of people who have worked with the code before
>
> 3) Bring project X to the incubator, mix outside people and
> potentially Geronimo people to form a new project team
>
> It's clear that there's a variety of opinions as to which of these
> is preferable, and potentially which is most preferable for the web
> console vs the ORB.
>
> Aaron
>
> On Tue, 12 Jul 2005, David Blevins wrote:
>
>> On Tue, Jul 12, 2005 at 07:17:44PM -0400, Davanum Srinivas wrote:
>>
>>> It's a judgement call i guess. i have not been on the calls. If you
>>> guys feel that it can support its own eco-system. then thats fine.
>>>
>>>
>>
>> I don't know yet, myself. But certainly one cannot deny there are
>> more CORBA specs than Web Services specs (for a while anyway); not
>> exactly the same deal as a web console.
>>
>> -David
>>
>>
>>> On 7/12/05, David Blevins <da...@visi.com> wrote:
>>>
>>>> On Tue, Jul 12, 2005 at 06:58:20PM -0400, Davanum Srinivas wrote:
>>>>
>>>>> It's just that the piece of code we are talking about in both
>>>>> cases, seem un-usable w/o geronimo.
>>>>>
>>>>
>>>> Is that really true? We are talking about a compliant ORB aren't
>>>> we?
>>>>
>>>> -David
>>>>
>>>>
>>>
>>>
>>> --
>>> Davanum Srinivas -http://blogs.cocoondev.org/dims/
>>>
>>
>>
>
>
--
Geir Magnusson Jr +1-203-665-6437
geirm@apache.org