Thanks to Justin Harringa, Mark Waite and Coleen Waite for testing the 
EasyCLA process on the 
https://github.com/jenkinsci-infra-ircbot-test/test-easycla  repository.
We have reported a few minor issues discovered during testing, but overall 
the process works pretty well.

I suggest going ahead and enabling individual CLAs for a number of 
repositories within jenkinsci. I suggest taking peripheral repos, because 
we need to figure out company CLAs and have all key maintainer permissions 
before enabling EasyCLA for the Jenkins core. 

I suggest voting for enabling Easy CLA in the Jenkins core next week

Best regards,
Oleg


On Tuesday, June 8, 2021 at 9:13:36 AM UTC+2 Oleg Nenashev wrote:

> Hi all,
>
> Just a quick update on the pending project:
>
>    - At the Governance meeting in April we agreed to proceed with 
>    exploring EasyCLA
>    - We submitted a request to the Linux Foundation. After several 
>    iterations, we agreed to keep EasyCLA management as a part of the CDF 
>    account for now. It technically allows all individuals and contributor 
>    companies to sign a single CLA for all projects, and then moderate where 
>    they contribute by company CLA and internal guidelines
>    - I have got an access yesterday so that I am able to configure 
>    EasyCLA for Jenkins
>    - I set up a test repository in 
>    https://github.com/jenkinsci-infra-ircbot-test/test-easycla and 
>    enabled EasyCLA for it. I also enabled branch protection there, and it 
>    works well. Anyone welcome to try out the new process by submitting pull 
>    requests to the repository.
>
> I will proceed with a process JEP to document the current state. Any 
> feedback is welcome!
>
> Best regards,
> Oleg
>
>
> On Thursday, April 8, 2021 at 8:00:14 PM UTC+2 Oleg Nenashev wrote:
>
>> Hi all,
>>
>> Just in case, you can find some notes from the EasyCLA webinar and 
>> Jenkins-specific questions from the webinar here 
>> <https://docs.google.com/presentation/d/1vy8riAfqzaW-PmvNIK0N6btHq2d4MYA81DKDPqWhrKU/edit?usp=sharing>
>> .
>> Slides and the Video will be published soon by the Linux Foundation.
>>
>> Best regards,
>> Oleg
>>
>>
>> On Friday, April 2, 2021 at 4:12:31 PM UTC+2 Oleg Nenashev wrote:
>>
>>> Hi all,
>>>
>>> Quick progress update:
>>>
>>>    - I have reached out to the Linux Foundation legal to clarify the 
>>>    CLA requirements. At the moment there is no strict guidelines how 
>>> projects 
>>>    should use CLA/DCO, and there are projects using neither of them. Apart 
>>>    from the potential legal risks (e.g. MIT License does not cover patent 
>>>    grant listed in our CLA for the submitted code), the Jenkins community 
>>> can 
>>>    proceed as is.
>>>    - I plan to setup the EasyCLA PoC so that the current contributors 
>>>    could try it out and see whether the process is convenient enough. Then 
>>> we 
>>>    can discuss changes in the CLA policy.
>>>    - I have submitted an application form to create a Jenkins account 
>>>    on Easy CLA. Once it is created, I will share the permissions with the 
>>>    Jenkins governance board members
>>>
>>> For your information, there will be also a webinar about EasyCLA on 
>>> April 8th: 
>>> https://linuxfoundation.org/webinars/lfx-easycla-streamline-your-development-workflow/
>>>  
>>> . It could be a good venue to ask any questions or to share our feedback.
>>>
>>> Best regards,
>>> Oleg Nenashev
>>>
>>>
>>>
>>> On Wednesday, March 24, 2021 at 8:11:05 AM UTC+1 Oleg Nenashev wrote:
>>>
>>>> Thanks for the insights Andrew!
>>>>
>>>> I agree that DCO could be a good compromise for the Jenkins core and 
>>>> related repositories.
>>>> I am not sure about plugin repositories, I'd guess we should make it 
>>>> optional though recommended for the repositories.
>>>>
>>>> Best regards,
>>>> Oleg Nenashev
>>>>
>>>>
>>>>
>>>> On Tue, Mar 23, 2021, 23:10 Andrew Grimberg <
>>>> [email protected]> wrote:
>>>>
>>>>> On 3/23/21 2:54 PM, Oleg Nenashev wrote:
>>>>> >> I don’t think that we should go this way. Kohsuke always tried to 
>>>>> keep
>>>>> > the barrier for contributions very low and I think we should continue
>>>>> > this way. I think that we would not have so many plugins (or PRs for
>>>>> > plugins) if we make the contribution process more complex
>>>>> > 
>>>>> > I would prefer to avoid setting extra boundaries as well. At the same
>>>>> > time, it makes sense to review the current model with the LF legal 
>>>>> team.
>>>>> > Right now we indeed avoid the contribution obstacles, but effectively
>>>>> > common code contributors and plugin maintainers do not sign CLA. It 
>>>>> may
>>>>> > cause some legal loopholes, especially in the terms of the patent 
>>>>> right
>>>>> > which is not covered by the MIT License used in Jenkins. Not that I
>>>>> > expect any real issues with that, but maybe there is a way to be on 
>>>>> the
>>>>> > safe side with minimum impact on contributors.
>>>>>
>>>>> I'm not legal council for LF, but since I do work with several of the
>>>>> projects at LF I can give you some perspective. That being said, 
>>>>> talking
>>>>> with legal is still a good idea!
>>>>>
>>>>> There's one hard and fast thing that I can recommend and that's to
>>>>> require DCO (Signed-off-by) on all changes coming in. If the DCO Probot
>>>>> is not setup on the GitHub org, it should be and enabled as a required
>>>>> check on all repositories.
>>>>>
>>>>> That's the lowest bar that legal is going to tell you that you really
>>>>> need to do.
>>>>>
>>>>> After that, CLAs are a thing that some of our projects use and others
>>>>> don't. Those that don't, just stick with DCO.
>>>>>
>>>>> Since you already have CLAs in play on some repos, legal is likely to
>>>>> push for you to go all out and make it a blanket thing. That being 
>>>>> said,
>>>>> EasyCLA can be configured to only be required on some repos and not 
>>>>> all,
>>>>> so that really is going to come down to what you as a project want.
>>>>>
>>>>> -Andy-
>>>>>
>>>>> -- 
>>>>> Andrew J Grimberg
>>>>> Manager Release Engineering
>>>>> The Linux Foundation
>>>>>
>>>>

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/f7528c47-2a58-4fe1-ada6-f62bea9ced1en%40googlegroups.com.

Reply via email to