[prev in list] [next in list] [prev in thread] [next in thread] 

List:       incubator-general
Subject:    Re: Podling Status Event Dates - Re: Podling status Copyright section
From:       Kenneth Knowles <kenn () apache ! org>
Date:       2019-05-16 20:17:48
Message-ID: CAN_Ypr30ZPw6OXQYgKH+F5ZuhDpr06BoPzbnHq_5b3F4bQM46A () mail ! gmail ! com
[Download RAW message or body]


Thanks for this. The steps are very clear and I like the addition of
repository clearance.

Kenn

On Wed, May 15, 2019 at 12:52 PM Chris Lambertus <cml@apache.org> wrote:

>
>
> > On May 15, 2019, at 12:10 PM, Dave Fisher <dave2wave@comcast.net> wrote:
> >
> > Hi -
> >
> > I think that we are mixing together a few events in a podling's
> lifecycle. Since I published a plan to update the status process and am
> just about to implement I think we should discuss events in a modern way
> since much of the language is a decade or more old and we are each trying
> to find the best language for modern times which includes our collective
> thoughts and understanding.
> >
> > (1) Start Date - Podling Proposal is Accepted.
> > (2) Podlings.xml file updated.
> > (3) Status page created.
> > (Not needed in improvement plan where the correct dates and events will
> be maintained through Whimsy Roster/Status pages)
> > (4) LDAP and Mailing lists created by Infra.
>
>
> DNS is a required Infra step. the LDAP creation is via Whimsy, and anyone
> with appropriate karma can click the button, although I do not currently
> know who has the karma. It is nominally apldap (Infra) but I think
> Secretary may also be able to take this step? This can be changed to suit,
> and could easily happen as part of the onboarding process (maybe by
> Secretary, maybe by some other designee) after podlings.xml has been
> updated. For now, it's easy enough to include it as an Infra step.
>
> Mailing lists are self-serve once the LDAP and DNS exists via
> https://selfserve.apache.org/ <https://selfserve.apache.org/>
>
>
>
> > (5) PPMC Member onboarding - ICLA, Apache accounts, ML signup.
> > (6) Codebase onboarding - assuming that all podling's continue to fit
> the GitHub development model.
> > - SGA (or proof that CCLA/ICLA in some combination are appropriate.)
> > - List of Repositories Cleared - This is NEW and providing this will be
> very helpful to both the podling and INFRA.
> > - Different repositories may come under different SGAs (or ICLA/CCLA)
> > - Date the repository is moved (or copied) and accepted by the PPMC.
>
> Specifically for Infra onboarding, we really just need to know that "the
> Foundation" has accepted the code and the donation has been reviewed by
> someone in-the-know about these things. Historically, this has been
> Secretary. The most critical thing for infra is that the repositories
> requested to be moved to the ASF are the ones which Secretary has received
> the SGA for, and the person requesting the import include a mailing list
> link to the Secretary's acceptance of the SGA.
>
> Thanks for putting this together.
>
> -Chris
>
>
>
>
>
> > (7) Date that the donated code has been changed.
> > - AL2 headers
> > - Copyrights removed.
> > (8) First fully compliant release
> > - Date when the IPMC agrees that podling is making compliant releases.
> > (9) News - releases, added committers, added PPMC members, (added
> repositories?)
> >
> > Notes on (6):
> > (a) Providing clearance for each repository will provide INFRA with a
> clear place to confirm that GitHub JIRA requests are valid.
> > (b) Provide a clear view to the status of repositories.
> >
> > Does this breakdown help us focus on the code versus committer
> requirements?
> >
> >> On May 15, 2019, at 1:28 AM, sebb <sebbaz@gmail.com> wrote:
> >>
> >> On Wed, 15 May 2019 at 06:55, Alex Harui <aharui@adobe.com.invalid>
> wrote:
> >>>
> >>> I do not like the words "transfer rights".  It could be interpreted as
> transfer of copyright.  Copyright of existing code is not transferred to
> the ASF, AIUI.  How about "Check to make sure that an SGA or CCLA has been
> received."
> >
> > At the point the SGA is granted and the code repository moved over one
> of the first actions to add the AL2 headers where appropriate. The donation
> may be relicensed from proprietary to AL2. At this time the copyright line
> is typically removed.
> >
> > It is up to the donating companies what they do with their copyright to
> their copy.
> >
> >>>
> >>> I don't like hypotheticals, but I can imagine some individual starting
> a project on GitHub, has only a few files already under ALv2, and gets a
> project going at the ASF?  Wouldn't we accept those few files under his
> ICLA and not require an SGA or CCLA?
> >
> > Yes. See 6 above.
> >
> >>>
> >>> I'd suggest dropping the second sentence ("it is necessary to transfer
> rights...").  AIUI, it is only necessary to grant a perpetual license to
> the ASF.
> >>
> >> Also, the CCLA is not required, and is not an alternative to the SGA
> >> -- as may perhaps be inferred by some from the phrase "(SGA or CCLA)"
> >>
> >> https://www.apache.org/licenses/cla-faq.html#cclas-not-required <
> https://www.apache.org/licenses/cla-faq.html#cclas-not-required>
> >
> > It is between the individuals and their employers if they can
> contribute. In the rare case where a company might not grant the donation
> via our SGA, but would with an CCLA, then we should be flexible. The
> question is where that decision should be made and how it is memorialized.
> >
> >>
> >>> I like your third sentence.
> >>>
> >>> HTH,
> >>> -Alex
> >>>
> >>> On 5/13/19, 5:28 PM, "Craig Russell" <apache.clr@gmail.com> wrote:
> >>>
> >>>   The Copyright section of the podling status page says "Check and
> make sure that the papers that transfer rights to the ASF been received. It
> is only necessary to transfer rights for the package, the core code, and
> any new code produced by the project.".
> >>>
> >>>   I'd propose a change:
> >>>
> >>>   "Check to make sure that the papers that transfer rights to the ASF
> been received (SGA or CCLA). It is necessary to transfer rights for any
> existing package and core code. Any new code produced by the project must
> be covered by ICLA."
> >>>
> >>>   This change is proposed because it might not be obvious to everyone
> what "the papers that transfer rights" are. And new code produced must be
> committed by a person who has filed an ICLA.
> >
> > I think that we set this language in the documentation. The status page
> is both documentation and status.
> >
> > Shall we iterate on the above list and patch the cookbook on the site?
> >
> > Regards,
> > Dave
> >>>
> >>>   Patches welcome.
> >>>
> >>>   Craig L Russell
> >>>   clr@apache.org
> >>>
> >>>
> >>>   ---------------------------------------------------------------------
> >>>   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
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> >> For additional commands, e-mail: general-help@incubator.apache.org
> >>
> >
>
>


[prev in list] [next in list] [prev in thread] [next in thread]