[blfs-dev] A question on tags

Qrux qrux.qed at gmail.com
Tue Feb 21 15:58:37 PST 2012


On Feb 21, 2012, at 3:43 PM, Bruce Dubbs wrote:

> Ken Moffat wrote:
>> At the moment, we have two varieties of tags for past LFS-releases
>> : built (known to build, but has not been tested), and checked
>> (builds, and works properly).  Am I alone in wondering if there is a
>> case for something in the middle, such as 'builds, and seems to
>> work'?

I think this, too, and I would call it 'run'.  To put correctness first, I would advocate this hierarchy:

	* "Tested"

Compiles, executes, passes regression (if it doesn't work from here, talk to the maintainer of the package, not BLFS).

	* "Run"

Compiles, executes (which should cover anything from no-idea-if-it-works-as-intended through I'm-pretty-sure-it-works-gud).

	* "Built"

Compiles (look-ma-no-hands..."Hey--'make' worked, and stuff got installed.  Everything else is on you, buddy).

IDK how the current "tagging" is done, but I think those are really the only "guarantees" you can ever hand out, and it's probably better not to hand anything out if there's any ambiguity.  It's probably a good time to start a matrix:

	i386-generic	x86_64-generic	(e.g., arm-generic, x86_64-core2, etc)
-------+---------------+---------------+---------------+-----
tested |               |               |               |
run    |               |               |               |
built  |               |               |               |
-------+---------------+---------------+---------------+-----

The first two columns I think are absolutely necessary.  BIND, for instances, went without verification on x86_64 before getting the "known to build and work properly on LFS-7.0" badge.  If there was a matrix, that'd be incredible.  IDK what kind of XML hacking would be needed for this, but something that was machine-parseable (say, to generate such a matrix every night) but also *easy to edit by hand* would be great, since Bruce's comment seems to imply that maintenance burden is a very real concern.

>> 
>> So, this *might*, for all I know, be the current state of "works
>> properly" but I think it would be much better to just say that it
>> seems to work - at least that is a step up from "I built it, but no
>> idea if it works" ?
> 
> I don't do a lot of user testing if it's not a package I usually use. 
> If the program starts, then it works as far as I'm concerned.  We may 
> have a configuration problem, but that can be fixed if we find it.  It's 
> not our purpose to do extensive user testing.

It's not about user-testing.  That's a whole other category.

But, you do have to verify that the instructions in the book work (assuming everyone has done all the prereqs, including LFS & deps correctly, and is making the necessary compensations--which didn't happen when we discussed the login.defs issue).

> For instance, if I build alsa, getting the speaker test to play white 
> noise is enough for me.  For ssh, can I connect to another system?  How 
> about Gimp?  Start it, scribble something, and save it is enough.

Forget about user-testing.  Rely on people handing in bug-reports for that.

> Doing something like Gnome is really hard.  You are trying to be 
> complete, but don't know a lot of the programs.  Sometimes built and not 
> tested is the right thing to say.  It just depends on your comfort 
> level, but I really don't want to add a third tag.

There's a middle ground between 'built' and 'tested', which is something like:

	"Does this executable run?"

Which is probably as far as the book can--and should--go.  I think what Ken is asking is a tag like: "I eyeballed this and it seems okay", which should be covered by 'run'.  And, if the book is going to support the building of X11 stuff (both Xorg and *all* the userspace stuff), then this category is probably necessary, since most of the GUI stuff doesn't come with regression tests.

	Q





More information about the blfs-dev mailing list