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/5d199909-2140-4fcc-ba7d-ff2f21f00fd5n%40googlegroups.com.
