This is a good idea, thanks for driving this! > Am 08.11.2021 um 10:38 schrieb Oleg Nenashev <[email protected]>: > > Hi all, > > I would like to proceed with https://github.com/jenkinsci/infra-cla > <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 > <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 > <https://github.com/jenkinsci/custom-war-packager> - not actively developed > at the moment > https://github.com/jenkinsci/label-verifier-plugin > <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] > <applewebdata://DE34636B-B845-474D-B2A5-504CB9BB1BE1> 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 > <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 > <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/ > > <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] > <mailto:[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 > > <https://groups.google.com/d/msgid/jenkinsci-dev/bc10978c-ddd4-4ec7-8117-27e1dab36cf8n%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/4A195CEC-BE44-46C4-A76B-2298A199656D%40gmail.com.
