[blfs-dev] A question on tags
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
I think this, too, and I would call it 'run'. To put correctness first, I would advocate this hierarchy:
Compiles, executes, passes regression (if it doesn't work from here, talk to the maintainer of the package, not BLFS).
Compiles, executes (which should cover anything from no-idea-if-it-works-as-intended through I'm-pretty-sure-it-works-gud).
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.
More information about the blfs-dev