From owner-freebsd-testing@freebsd.org Sun Oct 18 01:50:11 2015 Return-Path: Delivered-To: freebsd-testing@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CA005A1085B for ; Sun, 18 Oct 2015 01:50:11 +0000 (UTC) (envelope-from jmmv@meroh.net) Received: from mail-qg0-f42.google.com (mail-qg0-f42.google.com [209.85.192.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 82E4119A for ; Sun, 18 Oct 2015 01:50:10 +0000 (UTC) (envelope-from jmmv@meroh.net) Received: by qgbb65 with SMTP id b65so26036039qgb.2 for ; Sat, 17 Oct 2015 18:50:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=mWx+wyPglLT8/5v+KLhUVFOioKGiYQG+Gc8EAs6/plc=; b=PfwvXSWnzvTnhK0ptSAgLPacDnVd8TtoLsOhUZm+UY389PkoHw7IZ05e8/pm9qvHsz O94i4/nY44Vrko5EJdKKGGuSpzuDDosxVdme8VFkIDy89GJiRUCUsNNvcd0n+p3IrDwf 2D4tzihkXMmvqYwYXXsx3SEq+XJSU/962Uq2PYzqtCO3sAnnLe6dgaDnhB+b/iHWr2N+ ZUVkmXz6DQ9sbj8kuM5SW055LeHP7zb3TzZqZ9dCUriN4LWK/Zh0BGYZAk1mccP/GJbJ O8ZytdcZHeRsYOLu3m30G2tfwlh6Q2hEGXV8vFiBp8SsGV8amEUFz5CkgMZVuaZjlR4t bKJA== X-Gm-Message-State: ALoCoQkUiA2aR6d4Xu/i6Be0qGc+Yn5IXZ/i79VxRXDuXZzAaVsgTR6BdlXpNYjkesSJuaFLeFeE X-Received: by 10.140.43.183 with SMTP id e52mr20577545qga.38.1445133009112; Sat, 17 Oct 2015 18:50:09 -0700 (PDT) Received: from ?IPv6:2604:2000:c667:7600:4815:f07:b75a:45a7? ([2604:2000:c667:7600:4815:f07:b75a:45a7]) by smtp.gmail.com with ESMTPSA id f31sm11328065qkh.24.2015.10.17.18.50.08 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 17 Oct 2015 18:50:08 -0700 (PDT) Sender: Julio Merino Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.0 \(3094\)) Subject: Re: [RFC] Rename `make test` in suite.test.mk with `make regress` From: Julio Merino In-Reply-To: Date: Sat, 17 Oct 2015 21:50:02 -0400 Cc: "freebsd-testing@freebsd.org" Content-Transfer-Encoding: quoted-printable Message-Id: <5C39F495-5717-450F-8460-14B69DD48AD6@freebsd.org> References: To: NGie Cooper X-Mailer: Apple Mail (2.3094) X-BeenThere: freebsd-testing@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Testing on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Oct 2015 01:50:11 -0000 On Oct 17, 2015, at 18:03, NGie Cooper wrote: >=20 > Hi all, > There=E2=80=99s a lesser known target in suite.test.mk that runs = `kyua test` in a similar manner to how Jenkins and other groups have = integrated kyua into their test infrastructures. > The legacy target on FreeBSD was `regress`, but the target = created with the bsd.test.mk creation back a few years ago was `test`. = Why change from `test` to `regress`? There are places in the tree = (bin/test for example) that have targets named test, so in order to = avoid clashing with a common target (name), it=E2=80=99s best to use the = legacy target name. > Would anyone have any serious heartburn over the change? Is this only because of bin/test? Seems like renaming a target to avoid = that one collision is just moving the problem around. It is possible = that some other directory could later grow a target that conflicts with = your new name. Strictly speaking, "regress" is wrong. We do not have regression tests = only. Also, "regress" is a pretty obscure name for a target; it does = not appear in any other projects nor in any other build systems that I = know of. Have you considered "check"? That'd be in line with what automake does, = for example, which would homogenize the target name with a ton of other = projects out there.= From owner-freebsd-testing@freebsd.org Sun Oct 18 01:56:05 2015 Return-Path: Delivered-To: freebsd-testing@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CB894A10973 for ; Sun, 18 Oct 2015 01:56:05 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: from mail-pa0-x22e.google.com (mail-pa0-x22e.google.com [IPv6:2607:f8b0:400e:c03::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9C0B9620; Sun, 18 Oct 2015 01:56:05 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: by pabrc13 with SMTP id rc13so155426159pab.0; Sat, 17 Oct 2015 18:56:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=hvEj2wrxTqMhXN696sRV6rltroGtrykSH3gaqc03zvs=; b=QnHynB7YgfOVLrLzZ8DOi4f5Fzxv+RZwKHfXwOU1VF+VdHPycaJ0pcSUdz/CS02AgV tGWc+/ga7ZVe4ZfXcw1QLq7iFRNVPjlOT6Sz4mGAKs3iNfOIu8iI4I/1cMMzt8aZSqnZ o87zvIa+qR+tSWRjVNIiBmfCQtWqz2L4QTop71VAPYzEnruC1Sqj3rx+2LBMkUNHmqKU S0/g5I0ofF0xNOJKn1KOcWuyP+TA19QKkMAkRflPaaw6En/LgrP6wfod1/OmcNcUY2MZ gPiq3y1nnqhHKgo0+4RgErzmv8aoXwpnE0eyi8mIjnAYrtdD+GFJJC8ySxBegYkHGDSU Z4hQ== X-Received: by 10.67.15.100 with SMTP id fn4mr26475115pad.120.1445133365174; Sat, 17 Oct 2015 18:56:05 -0700 (PDT) Received: from ?IPv6:2601:601:800:126d:61c1:5eeb:a155:3bc5? ([2601:601:800:126d:61c1:5eeb:a155:3bc5]) by smtp.gmail.com with ESMTPSA id ro3sm5827917pbc.69.2015.10.17.18.56.04 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 17 Oct 2015 18:56:04 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: Re: [RFC] Rename `make test` in suite.test.mk with `make regress` From: NGie Cooper In-Reply-To: <5C39F495-5717-450F-8460-14B69DD48AD6@freebsd.org> Date: Sat, 17 Oct 2015 18:56:04 -0700 Cc: "freebsd-testing@freebsd.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <5C39F495-5717-450F-8460-14B69DD48AD6@freebsd.org> To: Julio Merino X-Mailer: Apple Mail (2.2104) X-BeenThere: freebsd-testing@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Testing on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Oct 2015 01:56:06 -0000 > On Oct 17, 2015, at 18:50, Julio Merino wrote: >=20 > On Oct 17, 2015, at 18:03, NGie Cooper wrote: >>=20 >> Hi all, >> There=E2=80=99s a lesser known target in suite.test.mk that runs = `kyua test` in a similar manner to how Jenkins and other groups have = integrated kyua into their test infrastructures. >> The legacy target on FreeBSD was `regress`, but the target = created with the bsd.test.mk creation back a few years ago was `test`. = Why change from `test` to `regress`? There are places in the tree = (bin/test for example) that have targets named test, so in order to = avoid clashing with a common target (name), it=E2=80=99s best to use the = legacy target name. >> Would anyone have any serious heartburn over the change? >=20 > Is this only because of bin/test? Seems like renaming a target to = avoid that one collision is just moving the problem around. It is = possible that some other directory could later grow a target that = conflicts with your new name. Yes, I realize that. The goal though is I want to be able to call `make = ` from the top and it would iterate down each and every = subdirectory and run tests. Sadly, most people don=E2=80=99t care to figure out how kyua works = enough to run `kyua test`=E2=80=A6 so I=E2=80=99m just trying to lower = the barrier of entry in a way that will work 100% of the time. > Strictly speaking, "regress" is wrong. We do not have regression = tests only. Also, "regress" is a pretty obscure name for a target; it = does not appear in any other projects nor in any other build systems = that I know of. Unfortunately it=E2=80=99s been in place a lot longer than anything = else, so it=E2=80=99s kind of the =E2=80=9Cdefacto standard=E2=80=9D. = That said... > Have you considered "check"? That'd be in line with what automake = does, for example, which would homogenize the target name with a ton of = other projects out there. =E2=80=A6 `make check` would be ok too. I just have to comb the tree for = binaries that don=E2=80=99t match `check`. Thanks! -NGie= From owner-freebsd-testing@freebsd.org Sun Oct 18 02:21:55 2015 Return-Path: Delivered-To: freebsd-testing@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7A5EBA10E84 for ; Sun, 18 Oct 2015 02:21:55 +0000 (UTC) (envelope-from jmmv@meroh.net) Received: from mail-qk0-f181.google.com (mail-qk0-f181.google.com [209.85.220.181]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3BCF4201 for ; Sun, 18 Oct 2015 02:21:54 +0000 (UTC) (envelope-from jmmv@meroh.net) Received: by qkcy65 with SMTP id y65so1947490qkc.0 for ; Sat, 17 Oct 2015 19:21:53 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=UEEu+hBbCjO6PWvqgaDtaP7J7dkJ6KKGoOHHhUM7BcI=; b=d5cuZx2J8XBlD62/0+6OWfwe2DZqb4rwKn/zzbE4happgb533ahebQ0BOwvchE/OCS gZF4SEYcUaFlKcIGMvEgkevYO3eBnRDUBKWdX608BafEdC4qzh07ZABCwGOixm0KGeo3 kBb939ISLnnWxR54Zzyu7SwTo/YcVlPIfubdIt/Gn/f3C6oG2fP/2vxd3MgWzMgBytkX ok5HiE6jUifHQUnrt6yNRyiIkcLXHQlPy494dn5njuQrBnXni6UxLHgm/G+aZTe8Gd5k XNvVQu4kIPypsAySq0SCXYw6Uc46ELa490Gs77reN8cgIQBpgi89zaMBilBfFaM6MjaS 979w== X-Gm-Message-State: ALoCoQmDcFFtBy+DrsezihDXxCigB4YjjEqdfWy9oLlT+xa+59HEEA3L51lBJ7oAHkPUVaUaSlgl X-Received: by 10.55.200.71 with SMTP id c68mr27964476qkj.72.1445134912997; Sat, 17 Oct 2015 19:21:52 -0700 (PDT) Received: from ?IPv6:2604:2000:c667:7600:4815:f07:b75a:45a7? ([2604:2000:c667:7600:4815:f07:b75a:45a7]) by smtp.gmail.com with ESMTPSA id l91sm11364651qkh.46.2015.10.17.19.21.52 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 17 Oct 2015 19:21:52 -0700 (PDT) Sender: Julio Merino Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.0 \(3094\)) Subject: Re: [RFC] Rename `make test` in suite.test.mk with `make regress` From: Julio Merino In-Reply-To: Date: Sat, 17 Oct 2015 22:21:49 -0400 Cc: "freebsd-testing@freebsd.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <5C39F495-5717-450F-8460-14B69DD48AD6@freebsd.org> To: NGie Cooper X-Mailer: Apple Mail (2.3094) X-BeenThere: freebsd-testing@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Testing on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Oct 2015 02:21:55 -0000 > On Oct 17, 2015, at 21:56, NGie Cooper wrote: >=20 >>=20 >> On Oct 17, 2015, at 18:50, Julio Merino wrote: >>=20 >> On Oct 17, 2015, at 18:03, NGie Cooper wrote: >>>=20 >>> Hi all, >>> There=E2=80=99s a lesser known target in suite.test.mk that runs = `kyua test` in a similar manner to how Jenkins and other groups have = integrated kyua into their test infrastructures. >>> The legacy target on FreeBSD was `regress`, but the target = created with the bsd.test.mk creation back a few years ago was `test`. = Why change from `test` to `regress`? There are places in the tree = (bin/test for example) that have targets named test, so in order to = avoid clashing with a common target (name), it=E2=80=99s best to use the = legacy target name. >>> Would anyone have any serious heartburn over the change? >>=20 >> Is this only because of bin/test? Seems like renaming a target to = avoid that one collision is just moving the problem around. It is = possible that some other directory could later grow a target that = conflicts with your new name. >=20 > Yes, I realize that. The goal though is I want to be able to call = `make ` from the top and it would iterate down each and every = subdirectory and run tests. Other for the bin/test naming collision, that should work already, = shouldn't it? Not sure how ugly this would be, but you'd also define an internal = "run-tests" target or similar that is used exclusively by the recursion = code. Then, in the top-level Makefile, you define a bare "test" target = that starts the recursion so that "make test" works. And then, in = bsd.test.mk, you define a "test" target if - and only if - there is no = "test" target yet. bin/test would behave differently than the rest if = you ever went in there and ran "make test", but I think that's a minor = problem. This is offtopic, but do you have a plan anywhere on how to make the = tests invocation this way reliable? Without installed binaries, the = tests might not do the right thing, and I'm not sure if the object tree = is enough for this to work properly. That's the reason why "make test" = from the top-level directory is currently disallowed. > Sadly, most people don=E2=80=99t care to figure out how kyua works = enough to run `kyua test`=E2=80=A6 so I=E2=80=99m just trying to lower = the barrier of entry in a way that will work 100% of the time. >=20 >> Strictly speaking, "regress" is wrong. We do not have regression = tests only. Also, "regress" is a pretty obscure name for a target; it = does not appear in any other projects nor in any other build systems = that I know of. >=20 > Unfortunately it=E2=80=99s been in place a lot longer than anything = else, so it=E2=80=99s kind of the =E2=80=9Cdefacto standard=E2=80=9D. = That said... I think I see what you mean: that because "regress" already existed in = the FreeBSD tree, no other targets were introduced to collide with it? = If yes, I wouldn't expect that to be the case. Tests were not = interleaved with the source tree in the past, so the "regress" target = only existed in a subset of the tree, didn't it? >> Have you considered "check"? That'd be in line with what automake = does, for example, which would homogenize the target name with a ton of = other projects out there. >=20 > =E2=80=A6 `make check` would be ok too. I just have to comb the tree = for binaries that don=E2=80=99t match `check`. >=20 > Thanks! > -NGie From owner-freebsd-testing@freebsd.org Sun Oct 18 02:48:31 2015 Return-Path: Delivered-To: freebsd-testing@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 49E50A10328 for ; Sun, 18 Oct 2015 02:48:31 +0000 (UTC) (envelope-from jmmv@meroh.net) Received: from mail-qg0-f52.google.com (mail-qg0-f52.google.com [209.85.192.52]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0335AD0F for ; Sun, 18 Oct 2015 02:48:30 +0000 (UTC) (envelope-from jmmv@meroh.net) Received: by qgbb65 with SMTP id b65so26564948qgb.2 for ; Sat, 17 Oct 2015 19:48:24 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=vlrFHgCESWxPHnlWk5vFUhXpjxSbv0r6To1NcO8yngM=; b=JFznpWUYONVoRsgNgLTf0jBnt8RMeCgf9DZdqsaBPRvh12nhomSVAufapO8cQBoRX5 ubOoskCZkrjxKYYGgsiAh8XVftGw9cjYJ/X9HsHRtzpklxBng+V/507Dpe6xKk+a3hmS Ib41GecukGOhp5UaSzufuc+qWMATQgAhvXTtFzEP2ymsuTkbDBoSbR12Z2VVgNnjm9z1 knZmjeD+4XFDtj0fkPI6XmGLEnb2SqISD5P7Pvre1/WFTs1l/SVj4CiySyfwAhIie/LT 4diDhcOSh0aSJz2lL2j2oRY9IgmzWvRoZ2xz6wCxEGk9UzX/dV7uIDhij9Hh4KI+Y74k 12UQ== X-Gm-Message-State: ALoCoQn4wri1qofFFLsc7Srs9F6fTTFPBzRUiHEwfrOuqL+zg9qf/1r8Yf6bPl0CSb/ohAAYk/y6 X-Received: by 10.140.233.130 with SMTP id e124mr29646528qhc.79.1445136503955; Sat, 17 Oct 2015 19:48:23 -0700 (PDT) Received: from ?IPv6:2604:2000:c667:7600:4815:f07:b75a:45a7? ([2604:2000:c667:7600:4815:f07:b75a:45a7]) by smtp.gmail.com with ESMTPSA id b36sm10195598qge.23.2015.10.17.19.48.23 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 17 Oct 2015 19:48:23 -0700 (PDT) Sender: Julio Merino Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.0 \(3094\)) Subject: Re: kyua and Google Contributor License Agreement From: Julio Merino In-Reply-To: Date: Sat, 17 Oct 2015 22:48:17 -0400 Cc: Brad Davis , "freebsd-testing@freebsd.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <20150930211156.GL65719@corpmail.liquidneon.com> To: Craig Rodrigues X-Mailer: Apple Mail (2.3094) X-BeenThere: freebsd-testing@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Testing on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Oct 2015 02:48:31 -0000 > On Oct 1, 2015, at 14:32, Craig Rodrigues wrote: >=20 >=20 >=20 > On Wed, Sep 30, 2015 at 2:11 PM, Brad Davis wrote: > On Wed, Sep 30, 2015 at 01:20:13PM -0700, Craig Rodrigues wrote: >=20 > I am in the same boat, and would love to see if we could just fork it = and > work from there. Could Julio then contribute to the code? >=20 > I don't know all the rules that Google has regarding the CLA and > what Google employees can and cannot contribute to. I'll let Julio = respond. The CLA exists to protect the project, and this is not something = specific to Google. If you ever want to contribute to any major open = source project, you will have to sign a CLA of some form. The FSF has = one; Apache has one; the PSF has one; and a bunch of other projects have = one (see = https://en.wikipedia.org/wiki/Contributor_License_Agreement#Users). The license of the code itself does not say much about the many other = implications a contribution might have. For this reason, and = personally, I see the need to sign a CLA as not-a-bad-thing for the = sanity of the project long-term, even though it might have adverse = consequences in a few cases. In fact, I'm kinda surprised that FreeBSD does not have any kind of = agreement in place. When I joined NetBSD back in the day (oops, 2002), I = was required to sign a contributor agreement. > I really want to avoid forking kyua, because Julio has put a lot of > work into putting things on Github, integrating the kyua github = project > with Travis CI (Continuous Integration), doing releases, etc. I'm afraid that part of the concerns also come from the fact that I = haven't been very responsive lately. Had I dealt with the bugs and = requests in a more timely fashion, you might not see the above as a real = blocker to getting things done... but, as has been the case, I cannot = make promises either. (Spoiler alert: two kids take a ton of time!) If anyone is serious about starting a fork, and wants to do so, please = contact me privately beforehand. I have some thoughts on the = topic/process. > My main concern is that the Google CLA is turning away potential=20 > contributors, and blocking patches that people have already submitted > from going in the kyua tree. Correct me if I'm wrong, but I seem to recall that the issue here was = mostly not with individuals, but with EMC not wanting to sign the = corporate CLA and thus preventing the EMC employees from feeding back = the code. I am not a lawyer, but based on the contents of the CLA, I = fear about the reasons for a company not wanting to sign it... Cheers= From owner-freebsd-testing@freebsd.org Mon Oct 19 20:18:55 2015 Return-Path: Delivered-To: freebsd-testing@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E7351A19C5E for ; Mon, 19 Oct 2015 20:18:55 +0000 (UTC) (envelope-from crodr001@gmail.com) Received: from mail-yk0-x235.google.com (mail-yk0-x235.google.com [IPv6:2607:f8b0:4002:c07::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A63BC2C1; Mon, 19 Oct 2015 20:18:55 +0000 (UTC) (envelope-from crodr001@gmail.com) Received: by ykdz2 with SMTP id z2so69470805ykd.3; Mon, 19 Oct 2015 13:18:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=df4e/+86LZqMlMPBySumfzs1vBn5xG82ORK+FQjNMqk=; b=Zux+ECBhTP6omCXTjCf5VxXnFCXeTzhCCv1ko/UVQ24EqeZz1HQuY22K004k2Ooxz6 /rMDdWtP8SzYnGPLGNqj4/5Q/4nn858f6jJHCvOyM2oMdcIXxCIDGuwS3GVZBtQRM781 4Yb2dv/BA5uYGMymQ5INpSGy3meOdQWd1uN/cpu30LEIf12L9e0Egb95DdiCUX1QAorA cbpSoS1Mzt6p0bWICPTPXpJC6W8anKZjHK+iezlqjVsEWmX1wy7wgxslB9DESgyZurxs 3B81OKZDfFsqPcg7VdMHAEnxd9jjMDCWPyC5rMyV33wtJq+Js0Z6GB0ngYp//xy63x7I IChg== MIME-Version: 1.0 X-Received: by 10.13.234.66 with SMTP id t63mr6116103ywe.89.1445285934843; Mon, 19 Oct 2015 13:18:54 -0700 (PDT) Sender: crodr001@gmail.com Received: by 10.37.107.7 with HTTP; Mon, 19 Oct 2015 13:18:54 -0700 (PDT) In-Reply-To: References: <20150930211156.GL65719@corpmail.liquidneon.com> Date: Mon, 19 Oct 2015 13:18:54 -0700 X-Google-Sender-Auth: 9Trm5n8CPbX_8yxx8WAZHBXgfBQ Message-ID: Subject: Re: kyua and Google Contributor License Agreement From: Craig Rodrigues To: Julio Merino Cc: "freebsd-testing@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-testing@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Testing on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2015 20:18:56 -0000 On Sat, Oct 17, 2015 at 7:48 PM, Julio Merino wrote: > > The CLA exists to protect the project, and this is not something specific > to Google. If you ever want to contribute to any major open source project, > you will have to sign a CLA of some form. > It is true that some major open source projects require a CLA. For now FreeBSD is not one of those projects. In the future, who knows what will happen, but for now, FreeBSD is still moving forward and doing fine without having to require a CLA. kyua is good software, but it is fairly niche, and not widely used compared to the other projects which you listed. For this reason, I view the CLA for kyua as more of an impediment to getting new developers to help contribute to kyua. My opinion is that this impediment outweighs any benefit to kyua that the legal protections of the CLA offers. The CLA for kyua has been an unfortunate impediment for developers at EMC. I understand how things go at big companies and with lawyers. When you have something so small and insignificant to a company's bottom line like kyua, there is almost zero incentive to get lawyers involved and to sign a legal agreement with another major company (Google). I can't say for sure since I don't work there, but that is probably what happened at EMC. Apart from EMC, I see that this one patch from namore has not been integrated due to namore not having signed the CLA: https://github.com/jmmv/kyua/pull/130 I would consider the following: -> is kyua important enough to Google to justify going through the Google CLA process? They already have Googletest ( https://github.com/google/googletest ) which overlaps in functionality with ATF. Googletest seems to have more Google employees working on it, and it has more activity around it than kyua. -> is there intellectual property in kyua that is likely to trigger legal problems if there is no CLA? My opinion is that the answer is no to both these points, however this is just my opinion, and I am not an expert in these areas. In addition, kyua has been integrated into the build system for FreeBSD, which generates Kyuafiles, but no other part of FreeBSD requires a CLA. Requiring a CLA for something that is so integrated into the FreeBSD build doesn't fit in nicely with the "FreeBSD way" of doing things. -- Craig