[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [gNewSense-users] KFV non-free reporting should recurse

From: Sam Geeraerts
Subject: Re: [gNewSense-users] KFV non-free reporting should recurse
Date: Sun, 29 Jun 2008 00:12:43 +0200
User-agent: Mozilla-Thunderbird (X11/20080420)

Bake Timmons wrote:
I wanted to point out an inconsistency in the KFV tables.

Here is a line from a KFV table (best with fixed width font) to remind
anyone who is new or rusty on this kind of detail:

Section | Adopter        | Adoption Date | Files in Section | % done | % free | 
All non-free SW reported | Summary Date |
pci     | NEEDS ADOPTING | ?             | 251              | 22.31% |22.31%  | 
N                        | 28 Jun 08    |

Of course, dates and adopters have no dependence on subsections.  All
other fields, however, do depend on not just the immediate content of
the directory (e.g., "pci" in this case) but also the subsections.

Thus, if any subsection, subsubsection, etc. has X number of files,
then that figures in the "Files in Section" total.  Likewise, if a
file anywhere is found to be non-free, then everything "up the chain"
*should be* affected.  However, *this* is not consistently done as it
stands.  Inevitably, the top-level sections (as they are right now at
least, kernel and kernel modules) should **eventually** have
(unfortunately but correctly) a value of "Y" as the value of "All
non-free SW reported".

Apart from being wrong, it is also less useful to put, say, "N/A" in
top-level section *just* on the basis of files in the immediate
corresponding directory.  The reader wants to quickly zero in on
problems and is best served by the correct organization of non-free

What do you think?  Unless I am wrong here, I will update kfv.el to do
this right.

I thought kfv.el was more for marking the freedom status per file and that the summary script bubbled all the numbers up the tree from the leafs on. Or do we have to manually update the percentages of every directory up the branch when we complete a section?

Anyway, I agree that it should work the way you say it should.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]