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
[EMAIL PROTECTED]