From mboxrd@z Thu Jan 1 00:00:00 1970 From: Chris Marusich Subject: Re: shortening the git test suite Date: Thu, 12 Jul 2018 02:27:43 -0700 Message-ID: <87wou0regg.fsf_-_@gmail.com> References: <87r2ko6pby.fsf@elephly.net> <87r2ki2hso.fsf@gmail.com> <87r2ko6pby.fsf@elephly.net> <87r2ki2hso.fsf@gmail.com> <87fu0y11ir.fsf@elephly.net> <87r2ko6pby.fsf@elephly.net> <87r2ki2hso.fsf@gmail.com> <87fu0y11ir.fsf@elephly.net> <87sh4wgrc3.fsf@netris.org> <87r2ko6pby.fsf@elephly.net> <87r2ki2hso.fsf@gmail.com> <87fu0y11ir.fsf@elephly.net> <87sh4wgrc3.fsf@netris.org> <87va9s9itb.fsf@gnu.org> <87a7r3gfmx.fsf@netris.org> <87fu0y11ir.fsf@elephly.net> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:50148) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fdXtC-0007ZN-AT for guix-devel@gnu.org; Thu, 12 Jul 2018 05:27:55 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fdXtA-0004eQ-VQ for guix-devel@gnu.org; Thu, 12 Jul 2018 05:27:54 -0400 In-Reply-To: <87fu0y11ir.fsf@elephly.net> (Ricardo Wurmus's message of "Thu, 05 Jul 2018 11:21:16 +0200, Fri, 06 Jul 2018 14:19:08 -0400, Fri, 06 Jul 2018 23:05:04 +0200, Wed, 11 Jul 2018 14:46:13 +0200") List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: Ricardo Wurmus , Mark H Weaver , Ludovic =?utf-8?Q?Court=C3=A8s?= Cc: guix-devel@gnu.org --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Ricardo, Mark, and Ludo, Ricardo Wurmus writes: > What do you think of pushing some package updates only to feature > branches that follow a certain naming convention (e.g. =E2=80=9C_update-f= oo=E2=80=9D for > updating the =E2=80=9Cfoo=E2=80=9D package), which causes Cuirass to buil= d them and > merge the branch into =E2=80=9Cmaster=E2=80=9D (semi-)automatically when = the build is > successful? If the goal is to ensure that the substitutes for a newly pulled Guix are available when "guix pull" runs, then wouldn't channels accomplish that goal? I realize we don't have channels yet, though. I think your proposal would be a reasonable improvement. In the case of a branch like "_update-foo", Cuirass would probably need to build not only the package "foo" but also any packages that depend on it, right? Since we're talking about updates to the master branch, this shouldn't cause too many rebuilds, so it shouldn't add much load to the build farm. If we're going to allow Cuirass to merge an update branch into master automatically, it might also make sense to allow Cuirass to automatically rebase the update branch onto master before merging it (to ensure the merge is a fast-forward merge), and delete the update branch after merging it (to prevent clutter in commands like "git branch -av"). Alternatively, we could leave those steps to a human and just have Cuirass send a summary email or make the results available via its web interface. I think that with the right automated tests to protect against silly bugs (like accidentally deleting the master branch), it would probably be safer to have Cuirass automatically merge and clean up after itself, rather than rely on humans to do it. Humans are prone to make mistakes, especially when performing tedious tasks. Mark H Weaver writes: >> Personally, I think that the SVN tests are non-essential (after all, >> we=E2=80=99re building Git here, we keep running the individual test sui= tes of >> Git and Subversion, and git-svn interop seems like a thing that only >> upstream need to worry about), which is why I made this proposal. > > Why do you say that only upstream needs to worry about it? I would > think that you could say the same thing about almost any test suite, but > there's always the possibility that our particular combination of input > versions, or the unusual aspects of Guix, might break something that > upstream doesn't know about. > > I would think that git-svn interop is something that any user of the > git/svn integration needs to worry about. I agree: just because I don't use a feature doesn't mean that we shouldn't test that feature if we can. We ought to be able to run all the tests. I think Ricardo's proposal would help increase the availability of substitutes, which would make long-running tests more tolerable. ludo@gnu.org (Ludovic Court=C3=A8s) writes: > Mark H Weaver skribis: > >> ludo@gnu.org (Ludovic Court=C3=A8s) writes: > > [...] > >>> Currently if test fails, the whole derivation fails, and you can=E2=80= =99t >>> install your package. If tests were run separately, this would no >>> longer hold: you could get your package regardless of whether tests >>> fail. >> >> Indeed, and I agree that we would need to address this. >> >>> How would you address this? I guess that calls for a new build >>> model, no? >> >> I'm not sure what you mean by "build model" [...] > > [...] > > IOW, this looks like a radical change with lots of potential pitfalls, > one I=E2=80=99d rather not make before 1.0. I agree that long test suite= s can > be a problem, but for now I think we should focus on package-specific > solutions, to the extent possible, such as what we discussed for Git, as > well as improvements to our build farm infrastructure. > > Thoughts? I agree that changes like those seem especially tricky to get right. While I'm here, I'll suggest another far-fetched idea. Perhaps we could rethink the relationship between packages, phases (of build systems), and derivations. Currently, I believe one package corresponds to one derivation, and the build phases are just procedures executed during that derivation. Perhaps we could change this so that a package corresponds to multiple derivations: one derivation per phase. If that were possible, then a package that runs all phases plus the test phase would be able to easily re-use the results of a package that runs the same phases but not the test phase. However, I'm not sure if this really makes sense, and in any case, the details would probably be difficult to design and implement. =2D-=20 Chris --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEy/WXVcvn5+/vGD+x3UCaFdgiRp0FAltHHw8ACgkQ3UCaFdgi Rp2fwxAA0JOmYSlrqiXqOHRMDwoLA083iI5wtcRi1f4HVHwG1BCE6CRIGIkibcUH /ZMTS0oRJ6wu936ziSEciysrJbod3w7W0W17zH0SbnECgexWgx8o0XaIuESpB9tb Wo7DKhfowVvIjnMzRY6Ze9kCqmcNyis2mXaNLnB39NXtUEQOR4QiaTfbvLwIFVkd C+b+vUVoXQ7eU7gFP/i9BxRvkVfXPfs+AcWGJG3uiqBaiKJAEJs7CnKVrhegnXxH hUYBfIng4BdqbYeYz9SQVi5Z9LZ69+eFe7/ISLIJuilyz7ba+Tdhzgs3lRu071M+ /sGfwvA8IFXd+q18dKOn8wZx8zQDBozAjcXMwIJ5oOv7301yfAmY0c14wykgcKoy qqRIFAF1CHGKMoUk2BHM3JDjFGREBkN/wsZmAAaxD49ZYd56stZ1GzOm1UFJTjS2 xy2ylVHg7agLulCDbSYIcRss+NvrCDqbWpRrQjh+pddkoXzi0eA9TYJisPpUon05 o+fO2x09hz7ygHMTNRlex7ksL1YV/ufsqFxIoyhpoqBO0Km3eEkjTYsyS6V32GyS 8Qv4nw8WCq3qS8XFrmXKOo0aE69YdIOmSqhZ8JMb6JJDuy8zDL04wOh2rZBckvMH ljFbJZoZKpzgmpjpkUQiiwr2843Ty1Z2Putki38vQRFLgqBooHI= =gK7D -----END PGP SIGNATURE----- --=-=-=--