Hi all, I would like to proceed with https://github.com/jenkinsci/infra-cla and to build a new process around this repository for now (TL;DR: ditching PDFs for new CLAs and gradually migrating old ones). Any objections?
Best rgeards, Oleg On Tuesday, June 22, 2021 at 11:25:44 PM UTC+2 Oleg Nenashev wrote: > Hi Tim. I would not like to enforce it for the Jenkins core and components > until we have all active core maintainers and company contributors to sign > ICLA/CCLA. It may take months. What I want to do is to enable EasyCLA > without enforcement. So I need a few repositories where we could enable > EasyCLA so that everyone can prepare. > > I suggest the following repositories: > > - https://github.com/jenkinsci/infra-cla - good repo for testing CLA. > Everyone can submit PR with removing dated CLAs while verifying their > signatures in the process :) > - platformlabeler-plugin and the elastic-axis-plugin as suggested by > Mark > - https://github.com/jenkinsci/custom-war-packager - not actively > developed at the moment > - https://github.com/jenkinsci/label-verifier-plugin - not actively > developed at the moment > > Is everyone fine with the ICLA/CCLA text? There are some minor differences > from the current ICLA/CCLAs we use > > BR, Oleg > > > > > On Tuesday, June 22, 2021 at 11:00:31 PM UTC+2 [email protected] wrote: > >> 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/bc10978c-ddd4-4ec7-8117-27e1dab36cf8n%40googlegroups.com.
