incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "John D. Ament" <johndam...@apache.org>
Subject Re: [DISCUSS] Policy Question: GA for GitHub for Podlings
Date Tue, 08 Nov 2016 02:45:13 GMT
On Mon, Nov 7, 2016 at 9:30 PM Sam Ruby <rubys@intertwingly.net> wrote:

> On Mon, Nov 7, 2016 at 9:10 PM, John D. Ament <johndament@apache.org>
> wrote:
> > I'm +0.5 for this right now.  There's some challenges I would like to see
> > answered to be able to move forward on this.
> >
> > - Who controls the ACLs?  I have some strong opinions of the ACL.
> > Specifically, when the podling joins the incubator, I expect that the
> > "OpenWhisk" organization be handed over to us, and all non-IPMC members
> are
> > removed.  Once we receive ICLAs members are granted access back.  Or the
> > equivalent - we create a new "ApacheOpenWhisk" organization.
> >
> > - All committers who are in the "incubator" group are granted write
> access
> > to OpenWhisk
>
> I have strong opinions on this subject too, and they don't match
> yours.  It happens.  :-)
>

And I honestly wouldn't want them to match.

In my opinion, for this to happen, we need to finish up the LDAP work,
allowing each podling to be given a separate permission set.  I would
generally prefer that approach.


>
> As one of the member of the IPMC, I would very much like to see
> podlings set up *EXACTLY* like PMCs, albeit with oversight by mentors.
> That means non-IPMC members are NOT removed, and committers in the
> "incubator" group are NOT added, only mentors.
>

I'm a bit iffy here.  IMHO, we cannot leave existing accounts in place on
the organization, as we won't have ICLAs on file (except for a few who
already exist I bet).  What I don't want to see is the PPMC, for non-IPMC
members, be given the ability to grant committer privileges to the repo
without having an ICLA on file.


>
> That being said, as the person who volunteered to set up LDAP for
> podlings, I will set aside my preference in favor of the consensus of
> the IPMC.  Logistically, however, giving every member of the incubator
> group write access to an existing GitHub repository would be a
> nightmare.  Granting mentors (a much smaller set) would be a smaller
> set.
>
> > - the ASF still needs to maintain records of the revision history.  I
> would
> > like to understand the plan to provide this history.
>
> Here's an example:
>
> https://matt.apache.org/pushlogs.html?repo=whimsy
>
> > I'm not very comfortable with a policy that allows podlings to do things
> > they can't do as TLPs.  This is setting up for major delays in
> graduation.
>
> The goal, for quite some time now, has been to resolve GitHub as a
> Master one way or another.  It is time to do so.  If the conclusion is
> that GitHub as a Master is not to be, OpenWhisk will need to be
> migrated at that time.  Until then, there is no reason to migrate it
> only to potentially migrate it back.
>
> > John
>
> - Sam Ruby
>
> > On Mon, Nov 7, 2016 at 5:23 PM Chris Mattmann <mattmann@apache.org>
> wrote:
> >
> >> Hi,
> >>
> >> As some of you may have seen the OpenWhisk podling being discussed now
> has
> >> requested to use GitHub as its primary master. Greg Stein our ASF Infra
> >> Admin
> >> has OK’ed this for OpenWhisk iff the IPMC is OK with it.
> >>
> >> I ask now:
> >>
> >> 1. Is the IPMC OK with this for OpenWhisk?
> >> 2. Is the IPMC OK with this in general availability for Podlings?
> >>
> >> I am +1 on both (IPMC hat on).
> >>
> >> Thanks.
> >>
> >> Cheers,
> >> Chris
> >>
> >>
> >>
> >>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> >> For additional commands, e-mail: general-help@incubator.apache.org
> >>
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message