From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ricardo Wurmus Subject: Re: shortening the git test suite Date: Thu, 05 Jul 2018 11:21:16 +0200 Message-ID: <87fu0y11ir.fsf@elephly.net> References: <87r2ko6pby.fsf@elephly.net> <87r2ki2hso.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:44975) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fb0SN-0001Bf-4S for guix-devel@gnu.org; Thu, 05 Jul 2018 05:21:44 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fb0SJ-0001gM-U1 for guix-devel@gnu.org; Thu, 05 Jul 2018 05:21:43 -0400 Received: from sender-of-o51.zoho.com ([135.84.80.216]:21064) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1fb0SJ-0001bY-JF for guix-devel@gnu.org; Thu, 05 Jul 2018 05:21:39 -0400 In-reply-to: <87r2ki2hso.fsf@gmail.com> 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: Chris Marusich Cc: guix-devel@gnu.org Chris Marusich writes: > Ricardo Wurmus writes: > >> Hi Guix, >> >> git takes a very long time to build, because it has an extensive test >> suite. Most of the time is spent in running the SVN interoperability >> tests, though, which are not really all that interesting for most uses >> of git. >> >> The Makefile says this: >> >> # Define NO_SVN_TESTS if you want to skip time-consuming SVN interoper= ability >> # tests. These tests take up a significant amount of the total test t= ime >> # but are not needed unless you plan to talk to SVN repos. >> >> What do you think about disabling the SVN tests in the git package? > > This sounds similar to the discussion we had earlier about treating > tests as a special case: > > https://lists.gnu.org/archive/html/guix-devel/2018-04/msg00071.html > > I felt that the conclusion of that thread was basically that if someone > is concerned about the build time, then they ought to be able to use > substitutes to speed things up, and we should continue to run as many > tests as possible in order to discover problems sooner. What I=E2=80=99m worried about is availability of substitutes. When we keep changing packages on the =E2=80=9Cmaster=E2=80=9D branch that have very exp= ensive test suites then we accept that people won=E2=80=99t have substitutes for a whil= e. The duration of that while depends on how quickly the build of this package is started by our continuous integration software, and how long it takes to complete the build. Granted, disabling parts of the test suite in an attempt to shorten it is really a technical fix to a social problem. 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 suites= 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. But as it seems that the people who responded to this message rather lean in the other direction, let=E2=80=99s try to address the social problem instea= d: How can we change our workflow to make sure that for packages with long build/test times we can provide substitutes more quickly? Currently, our policy for pushing changes to =E2=80=9Cstaging=E2=80=9D and =E2=80=9Cco= re-updates=E2=80=9D is based on package counts. I=E2=80=99m not suggesting that changes to Git be pushe= d to =E2=80=9Cstaging=E2=80=9D. 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-foo= =E2=80=9D for updating the =E2=80=9Cfoo=E2=80=9D package), which causes Cuirass to build = them and merge the branch into =E2=80=9Cmaster=E2=80=9D (semi-)automatically when th= e build is successful? (Obviously, any kind of automation has to be thought out carefully, but I=E2=80=99m sure we would be able to find a solution.) What do you think? -- Ricardo