~alpine/devel

Re: [alpine-devel] Proposal: testsuite support in APKBUILDs

Details
Message ID
<34pj48.oko8l5.2tck5z-qmf@gmx.com>
Sender timestamp
1485911411
DKIM signature
missing
Download raw message
Hey.

I already explained previously how checks aren't tests, semantically. And just as well you can find similar explanations by searching "test vs check" on your favorite search engine. We also previously established that the functionality was much more important than its name, not that the presence of an existing implementation was the best reason to cut out any discussion.

At any rate, this is taking way too much of my free time, and I don't see the discussion going anywhere. So I agree to stop caring, it's not worth the effort. 

Theo out.

On Tue Jan 31 18:21:37 2017 GMT+0100, William Pitcock wrote:
> Hello,
> 
> On Tue, Jan 31, 2017 at 5:08 AM, 7heo <7heo@mail.com> wrote:
> > Hey again,
> >
> > On 1/29/2017 9:49 AM, William Pitcock wrote:
> >>
> >> Hello,
> >>
> >> On Fri, Jan 27, 2017 at 1: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 name
> >>> isn't 'make' (since it's about identical terms).
> >>
> >>
> >> Has very little to do with GNU software, "make check" is #2 most
> >> frequently used in APKBUILD to invoke the testsuite behind "make
> >> test".  "test" is a shell built-in and cannot be used, as others have
> >> said in the thread.  The reason why "make check" is used so
> >> frequently, is because those packages have an automake-based build
> >> system.
> >
> > Yes, it was my understanding that the choice of "check" as an alternative to
> > "test" isn't a core belief of the GNU community. However, it is proposed
> > here because it occurs often, and it occurs often because it is used in a
> > GNU software. That's nothing new and is what I meant: I do not want to
> > repeat the mistakes made by communities we do not wish to follow (please
> > tell me if you think I'm wrong), because of their choices and focuses.
> >
> > TL;DR: Why would we perpetuate a mistake "because it's popular"? I thought
> > that this was the very idea alpine was against.
> 
> I am not convinced it is a "mistake".  It can be explained that the
> "check" phase is "to run checks against the package."
> 
> >>> 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
> >>> likely effectively hinder the understanding of newcomers while lowering the
> >>> learning curve for GNU people/users.
> >>
> >> I'm not really convinced that any new packager will be hindered any
> >> further by that considering that we can explain it in the "how to
> >> write an APKBUILD" guide.  We should not make decisions based on
> >> people who do not read docs.
> >
> > Here, I couldn't disagree more. I would never ask every user, every
> > developer, ever person who ever uses a software to read their entire
> > documentation thoroughly. There are bits such as proc(5), queue(3) and
> > perf_event_open(2) that are just too big. And that is just the tip of the
> > iceberg. One of the main reasons why the UNIX philosophy is so popular among
> > seasoned geeks is because they can grok most things without having to
> > consult the documentation every ten minutes or so. And that is because of
> > the high reuse of ideas and concepts as much as the sensible choice of
> > vocabulary.
> 
> By docs, I mean the example APKBUILD which clearly shows what it is
> for.  If they can't look at the example and figure it out, then they
> probably aren't going to be able to figure out the rest of the
> APKBUILD, either.
> 
> >>> 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.
> >>
> >> That's not very nice.  We should, and do, welcome anyone who wants to
> >> contribute as long as their contributions are in line with the project
> >> overall.
> >
> > That is not what I said. Nor what I wanted to talk about. Attracting people
> > isn't at all the same as accepting them. What I meant is that we shouldn't
> > favor GNU contributors over random contributors.
> 
> We do not have any practice to attract any specific contributors, nor
> would our use of "check" as the testsuite invocation cause this.
> Perhaps the wording you used originally is unfortunate, but it reads
> differently.
> 
> >>> So, does anyone agree?
> >>
> >> I agree that some care should be taken to ensure the tests verb is
> >> well known.  This is why I chose "check" as an alternative to
> >> "testsuite" (since it is #2 behind "make test" which we can't use).
> >> The most preferable option would be "test" but it's not happening
> >> without a complete rewrite of abuild, which I don't see happening just
> >> to support this...
> >
> > I still fail to understand why "tests" isn't a viable, more fitting
> > alternative (after all, most of the time there will be more than one test).
> 
> I originally considered "tests" as an alternative to testsuite besides
> "check".  My conclusion was that people would likely mess up and do
> something like:
> 
> test() { ... }
> 
> which would break their APKBUILDs.  "check" on the other hand cannot
> have such a fatal error -- at worst you fail to override the default,
> while with "tests" if you forget to make it plural, you are overriding
> a shell builtin.
> 
> Most likely the GNU people came to the same conclusion, which is why
> they went with "check".  I chose "check" because Jakub mentioned that
> Arch was already using it and GNU software also uses it.  While it is
> true that Alpine is not about maintaining the status quo in cases
> where the status quo needs disruption, this is not really something we
> need to do differently just because we can.
> 
> At any rate, it is already in abuild and will be part of abuild 2.30,
> so I think it is not productive for you to continue beating a dead
> horse.
> 
> William
>
Reply to thread Export thread (mbox)