Is this close enough for a vote? Do we actually want to do this? Moving the CLA process away from the current process sure, but enabling it on Jenkins core?
On Tue, 22 Jun 2021 at 21:12, Mark Waite <[email protected]> wrote: > Those all sound great to me. > > I volunteer the platformlabeler-plugin and the elastic-axis-plugin as two > that could be used for testing if needed. > > Mark Waite > > On Tue, Jun 22, 2021 at 12:44 PM Oleg Nenashev <[email protected]> > wrote: > >> 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 >> <https://groups.google.com/d/msgid/jenkinsci-dev/f7528c47-2a58-4fe1-ada6-f62bea9ced1en%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> > -- > 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/CAO49JtGcaoiMMF5iNhe2nUnMJgW6R0L5PTjv%3D%2B45drEdaBdAOA%40mail.gmail.com > <https://groups.google.com/d/msgid/jenkinsci-dev/CAO49JtGcaoiMMF5iNhe2nUnMJgW6R0L5PTjv%3D%2B45drEdaBdAOA%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- 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/CAH-3BieJLKp0qXnmj0Py7ycj4agQzMtFrPLcYJQqM5MY7k5MRw%40mail.gmail.com.
