From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?UTF-8?Q?G=C3=A1bor_Boskovits?= Subject: Re: shortening the git test suite Date: Fri, 6 Jul 2018 11:46:53 +0200 Message-ID: References: <87r2ko6pby.fsf@elephly.net> <87r2ki2hso.fsf@gmail.com> <87fu0y11ir.fsf@elephly.net> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000f7872b0570518b2a" Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:44919) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fbNKX-0005Uw-1M for guix-devel@gnu.org; Fri, 06 Jul 2018 05:47:10 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fbNKV-0008J0-MC for guix-devel@gnu.org; Fri, 06 Jul 2018 05:47:09 -0400 Received: from mail-it0-x22a.google.com ([2607:f8b0:4001:c0b::22a]:35837) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1fbNKV-0008ED-FB for guix-devel@gnu.org; Fri, 06 Jul 2018 05:47:07 -0400 Received: by mail-it0-x22a.google.com with SMTP id l16-v6so16311362ita.0 for ; Fri, 06 Jul 2018 02:47:07 -0700 (PDT) In-Reply-To: <87fu0y11ir.fsf@elephly.net> 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 Cc: Guix-devel --000000000000f7872b0570518b2a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Ricardo Wurmus ezt =C3=ADrta (id=C5=91pont: 2018. j=C3= =BAl. 5., Cs 11:22): > > 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 > interoperability > >> # tests. These tests take up a significant amount of the total test > time > >> # 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 k= eep > changing packages on the =E2=80=9Cmaster=E2=80=9D branch that have very e= xpensive test > suites then we accept that people won=E2=80=99t have substitutes for a wh= ile. > 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 suit= es 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 inst= ead: > > 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=9C= core-updates=E2=80=9D is based > on package counts. I=E2=80=99m not suggesting that changes to Git be pus= hed 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-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? > > > > I think this is a very reasonable approach. If this will be the way to go= , then we also need a way to select packages to which this applies, and find a way to communicate this. > (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 > > > --000000000000f7872b0570518b2a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


= Ricardo Wurmus <rekado@elephly.net= > ezt =C3=ADrta (id=C5=91pont: 2018. j=C3=BAl. 5., Cs 11:22):

Chris Marusich <cmmarusich@gmail.com> writes:

> Ricardo Wurmus <rekado@elephly.net> writes:
>
>> Hi Guix,
>>
>> git takes a very long time to build, because it has an extensive t= est
>> suite.=C2=A0 Most of the time is spent in running the SVN interope= rability
>> tests, though, which are not really all that interesting for most = uses
>> of git.
>>
>> The Makefile says this:
>>
>>=C2=A0 =C2=A0# Define NO_SVN_TESTS if you want to skip time-consumi= ng SVN interoperability
>>=C2=A0 =C2=A0# tests.=C2=A0 These tests take up a significant amoun= t of the total test time
>>=C2=A0 =C2=A0# but are not needed unless you plan to talk to SVN re= pos.
>>
>> 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 someon= e
> 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<= br> > tests as possible in order to discover problems sooner.

What I=E2=80=99m worried about is availability of substitutes.=C2=A0 When w= e 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.=C2=A0 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?=C2=A0 Currently,<= br> 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.=C2=A0 I=E2=80=99m not suggesting that changes to Git be = pushed 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?



I thi= nk this is a very reasonable approach. If this will be the way to go, then = we also need a way to select packages to which this applies, and find a way= to communicate this.
(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


--000000000000f7872b0570518b2a--