X-Original-To: alpine-devel@lists.alpinelinux.org Received: from mail-io0-f171.google.com (mail-io0-f171.google.com [209.85.223.171]) by lists.alpinelinux.org (Postfix) with ESMTP id 45E595C0F31 for ; Fri, 27 Jan 2017 08:10:20 +0000 (GMT) Received: by mail-io0-f171.google.com with SMTP id v96so55602053ioi.0 for ; Fri, 27 Jan 2017 00:10:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=reevoo.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Ug3k2UBcG/6i8cGqXwmext7xc/JyuYI/uPPYYwHTycM=; b=gKYDrnm58n+PRWEoDppkBiDWTq7L3vtUonkm0UZXBtxri7BbOKzFFgITEu/8J+FkW5 l1zxo1T0J2kfXY5dHSBiDi8AFJBgl8ssNQ621Jo6moGsvUCo3eBqkCMqSKQDs74z4pE2 RBkZCTiR9pjSq0jFvs5pVxgzUdjoX+MuuJ2kM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Ug3k2UBcG/6i8cGqXwmext7xc/JyuYI/uPPYYwHTycM=; b=ZoIVbMgIKGACBGyzEUYkiT6wT+Oh3S9bzN8rpzqrcZgP4n2catdiGdo/a6+tg22b0l 38zIirCkxcZ/D4Ze6vmPcHTh2kBqTN0/3m4GEvwXZQj60g+AlT7T1OXN1JH/Dpa77v+/ O2sP+M6sew4cOYLF0rktFHNRwPO70/TThR2hp5oYM3y9V3h/NqDD2zKEEaOf7E/aQtYE KXreHAhIfXeffKJdbDKWn4C0wpbfZDStI9UGc7fWZU129fZz7hyCHg0XUo3SOItvNKFL zlwutS9tlphsjMsjZpMigbQKF9m1bsSxdyszQ707JMufWeERRlMkqp6S1LeOcfo9SdFL a3aw== X-Gm-Message-State: AIkVDXIW+fnXSmVu8lBgxdoxg0NpfLzl4a1+aZos9KsHNuKyGe6MxNF9YtVzfdLfDuO7/pZPYXkLcDgt4P66unrW X-Received: by 10.107.30.141 with SMTP id e135mr7299831ioe.84.1485504619805; Fri, 27 Jan 2017 00:10:19 -0800 (PST) X-Mailinglist: alpine-devel Precedence: list List-Id: Alpine Development List-Unsubscribe: List-Post: List-Help: List-Subscribe: MIME-Version: 1.0 Received: by 10.79.208.10 with HTTP; Fri, 27 Jan 2017 00:10:19 -0800 (PST) In-Reply-To: <5blaf1.okfi73.2tnq26-qmf@gmx.com> References: <20170126112655.44ad5c0e@vostro.util.wtbts.net> <4EDA0683-3991-44D0-882C-C34FBD4C38B2@jirutka.cz> <5blaf1.okfi73.2tnq26-qmf@gmx.com> From: Ed Robinson Date: Fri, 27 Jan 2017 08:10:19 +0000 Message-ID: Subject: Re: [alpine-devel] Proposal: testsuite support in APKBUILDs To: 7heo <7heo@mail.com> Cc: nenolod@dereferenced.org, alpine-devel@lists.alpinelinux.org, timo.teras@iki.fi, jakub@jirutka.cz Content-Type: multipart/alternative; boundary=001a114198ee2d1b2e05470effa1 --001a114198ee2d1b2e05470effa1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I would prefer test over check and (testsuite). Test is a verb so fits nicely with the other commands. "make test" is used about 4 times more often than make check in the existing packages. https://github.com/alpinelinux/aports/search?utf8=3D%E2%9C%93&q=3Dmake+test= &type=3DCode (634 results) vs https://github.com/alpinelinux/aports/search?utf8=3D%E2%9C%93&q=3Dmake+chec= k&type=3DCode (180 results) I think the idea is a good one overall and I think while naming is moderately important, having the feature is more important than getting the name right... ,Ed On Fri, Jan 27, 2017 at 7:59 AM, 7heo <7heo@mail.com> wrote: > I am really confused that you want to use a wrong vocab because GNU > software already use it. Plus, it was my understanding that our tool's na= me > isn't 'make' (since it's about identical terms). > > I understand that for many people this discussion may seems like a waste > of time, but using the correct vocabulary is an essential part of > code-as-documentation. > > Going with check is not a huge inaccuracy I admit; but it will most likel= y > effectively hinder the understanding of newcomers while lowering the > learning curve for GNU people/users. > > I can explain in a separate mail (or on IRC) why I think it is a bad > enough idea to attract GNU contributors to alpine, to justify continuing > this discussion; but I'll assume here that all alpine contributors share = a > similar view on the GNU code style. > > So, does anyone agree? > > Theo > > On Fri Jan 27 02:28:32 2017 GMT+0100, William Pitcock wrote: > > Hello, > > > > In some ways I am inclined to agree with Jakub, mostly because "make > > check" is the main way of invoking a testsuite on autotools platforms. > > It is perhaps not the most correct description of the phase, but it > > does fit with "make check" usage in autotools, so people would be > > familiar with it. > > > > Lets move forward with check phase and !check in $features? > > > > William > > > > On Thu, Jan 26, 2017 at 8:34 AM, 7heo <7heo@mail.com> wrote: > > > Hey, > > > > > > Since we're talking about vocabulary and semantics, I would rather > avoid check, since it doesn't reflect what happens. A testsuite is a suit= e > (set of, ordered, predictable) of tests (dynamic procedure to validate an > element, that has to be executed). A check is merely an observation with > assertion on an existing state. As an example, you can check the door is > open, but you have to test if the lock works (you can't just check it in > normal conditions and without a specialized apparatus). > > > > > > Long story short, I don't have any problem with making it shorter and > simpler, but I would rather have something that matches what is actually > does. :) > > > > > > Theo. > > > > > > On Thu Jan 26 14:08:29 2017 GMT+0100, Jakub Jirutka wrote: > > >> Hi, > > >> > > >> currently we have the following phases: sanitycheck, builddeps, > clean, fetch, unpack, prepare, mkusers, rootpkg, cleanup. All of them > except rootpkg are verbs. So I=E2=80=99d prefer =E2=80=9Ccheck=E2=80=9D (= as Arch) instead of > =E2=80=9Ctestsuite=E2=80=9D. > > >> > > >> Jakub > > >> > > >> > On 26. Jan 2017, at 10:26, Timo Teras wrote: > > >> > > > >> > On Wed, 25 Jan 2017 21:38:00 -0600 > > >> > William Pitcock wrote: > > >> > > > >> >> As such, I propose we add a testsuite() phase to the build proces= s, > > >> >> that runs after build(), but prior to package(). APKBUILDs shoul= d > > >> >> override the testsuite phase, but the default_testsuite() functio= n > > >> >> will be a noop for the Alpine 3.6 release cycle that raises a > warning > > >> >> that the APKBUILD does not define any mechanism for running a > > >> >> testsuite. If "!testsuite" is defined in $features, the warning = is > > >> >> ignored. > > >> >> > > >> >> For cross-builds, the testsuite would be skipped unless the packa= ge > > >> >> is noarch. > > >> >> > > >> >> After Alpine 3.6 (or maybe 3.7), we change the warning to a fatal > > >> >> error, requiring APKBUILDs to explicitly opt out of running a > > >> >> testsuite through $features. > > >> >> > > >> >> Thoughts? > > >> > > > >> > +1 > > >> > > > >> > We have some packages that run 'make check' or similar, but it > would be > > >> > good to make it a separate step. > > >> > > > >> > The above plan sounds good to me. > > >> > > > >> > Thanks, > > >> > Timo > > >> > > > >> > > > >> > --- > > >> > Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org > > >> > Help: alpine-devel+help@lists.alpinelinux.org > > >> > --- > > >> > > > >> > > >> > > >> > > >> --- > > >> Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org > > >> Help: alpine-devel+help@lists.alpinelinux.org > > >> --- > > >> > > >> > > > --001a114198ee2d1b2e05470effa1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I would prefer test over check and (testsuite). Test is a verb so fits nicely with the other = commands. "make test" is used about 4 times more often than make = check in the existing packages.=C2=A0https= ://github.com/alpinelinux/aports/search?utf8=3D%E2%9C%93&q=3Dmake+test&= amp;type=3DCode (634 results) vs=C2=A0https://github.com/alpinelinux/aports/search?utf8=3D%E2%9C%93&q=3Dmake= +check&type=3DCode (180 results)

I think the ide= a is a good one overall and I think while naming is moderately important, h= aving the feature is more important than getting the name right...

,Ed

On Fri, Jan 27, 2017 at 7:59 AM, 7heo &l= t;7heo@mail.com><= /span> wrote:
I am really confused that y= ou want to use a wrong vocab because GNU software already use it. Plus, it = was my understanding that our tool's name isn't 'make' (sin= ce it's about identical terms).

I understand that for many people this discussion may seems like a waste of= time, but using the correct vocabulary is an essential part of code-as-doc= umentation.

Going with check is not a huge inaccuracy I admit; but it will most likely = effectively hinder the understanding of newcomers while lowering the learni= ng curve for GNU people/users.

I can explain in a separate mail (or on IRC) why I think it is a bad enough= idea to attract GNU contributors to alpine, to justify continuing this dis= cussion; but I'll assume here that all alpine contributors share a simi= lar view on the GNU code style.

So, does anyone agree?

Theo

On Fri Jan 27 02:28:32 2017 GMT+0100, William Pitcock wrote:
> Hello,
>
> In some ways I am inclined to agree with Jakub, mostly because "m= ake
> check" is the main way of invoking a testsuite on autotools platf= orms.
> It is perhaps not the most correct description of the phase, but it > does fit with "make check" usage in autotools, so people wou= ld be
> familiar with it.
>
> Lets move forward with check phase and !check in $features?
>
> William
>
> On Thu, Jan 26, 2017 at 8:34 AM, 7heo <7heo@mail.com> wrote:
> > Hey,
> >
> > Since we're talking about vocabulary and semantics, I would r= ather avoid check, since it doesn't reflect what happens. A testsuite i= s a suite (set of, ordered, predictable) of tests (dynamic procedure to val= idate an element, that has to be executed). A check is merely an observatio= n with assertion on an existing state. As an example, you can check the doo= r is open, but you have to test if the lock works (you can't just check= it in normal conditions and without a specialized apparatus).
> >
> > Long story short, I don't have any problem with making it sho= rter and simpler, but I would rather have something that matches what is ac= tually does. :)
> >
> > Theo.
> >
> > On Thu Jan 26 14:08:29 2017 GMT+0100, Jakub Jirutka wrote:
> >> Hi,
> >>
> >> currently we have the following phases: sanitycheck, builddep= s, clean, fetch, unpack, prepare, mkusers, rootpkg, cleanup. All of them ex= cept rootpkg are verbs. So I=E2=80=99d prefer =E2=80=9Ccheck=E2=80=9D (as A= rch) instead of =E2=80=9Ctestsuite=E2=80=9D.
> >>
> >> Jakub
> >>
> >> > On 26. Jan 2017, at 10:26, Timo Teras <timo.teras@iki.fi> wrote:
> >> >
> >> > On Wed, 25 Jan 2017 21:38:00 -0600
> >> > William Pitcock <nenolod@dereferenced.org> wrote:
> >> >
> >> >> As such, I propose we add a testsuite() phase to the= build process,
> >> >> that runs after build(), but prior to package().=C2= =A0 APKBUILDs should
> >> >> override the testsuite phase, but the default_testsu= ite() function
> >> >> will be a noop for the Alpine 3.6 release cycle that= raises a warning
> >> >> that the APKBUILD does not define any mechanism for = running a
> >> >> testsuite.=C2=A0 If "!testsuite" is define= d in $features, the warning is
> >> >> ignored.
> >> >>
> >> >> For cross-builds, the testsuite would be skipped unl= ess the package
> >> >> is noarch.
> >> >>
> >> >> After Alpine 3.6 (or maybe 3.7), we change the warni= ng to a fatal
> >> >> error, requiring APKBUILDs to explicitly opt out of = running a
> >> >> testsuite through $features.
> >> >>
> >> >> Thoughts?
> >> >
> >> > +1
> >> >
> >> > We have some packages that run 'make check' or s= imilar, but it would be
> >> > good to make it a separate step.
> >> >
> >> > The above plan sounds good to me.
> >> >
> >> > Thanks,
> >> > Timo
> >> >
> >> >
> >> > ---
> >> > Unsubscribe:=C2=A0 alpine-devel+unsubscribe@lists.alpineli= nux.org
> >> > Help:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0alpine-devel+help@lists.al= pinelinux.org
> >> > ---
> >> >
> >>
> >>
> >>
> >> ---
> >> Unsubscribe:=C2=A0 alpine-devel+unsubscribe@lists.alpinelinux.o= rg
> >> Help:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0alpine-devel+help@lists.alpinel= inux.org
> >> ---
> >>
> >>
>

--001a114198ee2d1b2e05470effa1-- --- Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org Help: alpine-devel+help@lists.alpinelinux.org ---