incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "robert burrell donkin" <robertburrelldon...@gmail.com>
Subject Re: [POLICY][DOC] IP clearance process refinements
Date Sun, 19 Mar 2006 21:49:03 GMT
On 3/19/06, Dain Sundstrom <dain@iq80.com> wrote:
> On Mar 19, 2006, at 6:25 AM, robert burrell donkin wrote:
>
> > On 3/19/06, Leo Simons <mail@leosimons.com> wrote:
> >> On Sun, Mar 19, 2006 at 12:26:04PM +0000, robert burrell donkin
> >> wrote:
> >
> > <snip>
> >
> >>> 3 there is no indication the form which CLA's and CCLA's are
> >>> relevant.
> >>> this makes oversight difficult.
> >>>
> >>> PROPOSAL: the form should include official names (as listed in the
> >>> foundation documents) for those donating the code.
> >>
> >> Hrmpf. Aren't official names supposed to be private?
> >
> > didn't know that
> >
> >> I think we have a
> >> map of "nickname" -> "official name" which is somewhere private. I
> >> think
> >> the rule should be that all non-official names should be
> >> registered in
> >> that mapping.
> >
> > anyone know where this lives?
>
> Do you mean this?
>
>   http://people.apache.org/~jim/committers.html

that's generated by a script. appears that jim fixes up any nick names
before it's entered into the original. therefore using the name in the
original should satisfy those who wish to use a nick name.

> >>> 5 the VOTE from the project receiving the code is unnecessary and
> >>> confusing. it serves no useful legal purpose and normal apache
> >>> process
> >>> can handle objections when the code is committed.
> >>>
> >>> PROPOSAL: scrap this requirement
> >>
> >> *shrug*. I like how it makes explicit that its a group decision
> >> (which
> >> also implies you don't go sue the individual that did the commit
> >> if there
> >> is ever a problem).
> >
> > the vote proved to be confusing in practice. the concensus seems to be
> > +0 'yes but only if it's legal'.
> >
> > the legal oversight is supposed to be provided by the incubator pmc
> > not the project where the code lands.
> >
> > this is probably a good reason why the donation should be initially
> > committed into the incubator repository. it can then be yanked by
> > anyone in incubator. alternatively, the code could be committed to a
> > private repository since it's only there for the records.
> >
> > AIUI the commit should be safe enough since the execution will be done
> > by an ASF official or member. processing a grant is an official ASF
> > operation and the work is done on behalf of the foundation.
> >
> > anyone who knows more like to jump in here?
>
> I personally think a vote is just good form.  Donations of entire cvs
> or svn trees require the assistance of infrastructure and I would
> hate to ask them to do something and then have the community
> ultimately reject the code.

i think that this can be handled by normal consensus building.
processing a software grant takes quite a lot of time and effort so
the member or officer will be convinced that the project wants the
code before starting out.

it's really the timing with regard to incubator pmc approval which
caused the confusion. the current process says that a formal vote must
be held prior to approval by the incubator pmc.

infrastructure shouldn't be involved until the code is signed off from
a legal perspective by the incubator pmc. if the grant involves
infrastructure then a VOTE will be required before the request is
actioned but infrastructure work shouldn't be actioned until after
legal sign off. so, really a second vote would be necessary in any
case.

seems cleaner to separate these issues:

1 preparation by member or officer
2 incubator legal signoff
3 hand over to project to be handled in the standard way. if
infrastructure needs to be involved a formal VOTE will be required to
action the work.

- robert

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org


Mime
View raw message