gnewsense-users
[Top][All Lists]
Advanced

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

Re: [gNewSense-users] Re: KFV back end / Code Review Programs


From: Karl Goetz
Subject: Re: [gNewSense-users] Re: KFV back end / Code Review Programs
Date: Thu, 10 Jul 2008 11:19:12 +0930

On Wed, 2008-07-09 at 17:02 -0400, Danny Clark wrote:
> Bake Timmons wrote:
> > Danny Clark <address@hidden> writes:
> > 
> >> (Q1) Is a version control program not used just because no one has had
> >> time to implement it, or are there arguments against it?
> > 
> > Lack of time has been my impression of the problem.  The wiki tables
> > have been a quick and easy solution, but just a first step.  I agree
> > with your comments and am eager to help adapt KFV Mode to a better
> > back end.  I would be surprised if git were not the most efficient
> > back end.
> 
> Git is efficient, but also a real pain in the ass to work with
> (extremely nonobvious behavior - and this is coming to me from top
> percentile programmers (former OLPC colleagues), not newbies), and it is
> not (yet) well integrated with a bunch of other tools.

Git and i have a hate-hate relationship ;) that said, the idea (using a
destributed RCS) is totally sound imo.
I'm still musing how w would setup all this $stuff.

> 
> As I recall this is partly because Linus wanted git to be more of a core
> library that others wrote front ends to, but I think he has since
> changed course, and is trying to make git easier to use. I'm not sure
> what the current state of that is, as I haven't touched git in >6 months.
> 
> > Moreover, I hope that this new back end could be adapted for *all*
> > freedom verification work, including what gNewSense started to do for
> > packages (PFV).  One difference between KFV and PFV is that PFV
> > typically involved looking not at a file of source code but at a file
> > of license text that covered a whole package.
> 
> Or even a step beyond that, to freedom verification work even for
> non-gNS projects, and then have the gNS-specific stuff be separated out
> (there really shouldn't be that much packaging code that's separate from
> the pristine sources).
> 
> This seems like it's abstractable to "we need to maintain a database of
> information about a set of files that changes over time, and have nice
> front ends to maintaining that information". I have to think that there
> are - or really should be - nice Free Software products / sites covering
> that problem space. Fossology - http://fossology.org/ - was recently
> pointed out to me, but I haven't had a chance to look at it in depth yet.

Fossology was meantiond back in feb/march iirc. I was playing with it
back then (as was someone else?). I never got far with it though - i
managed to find more bugs then i was willing to deal with. I'm looking
at trying the latest release RSNish again.

> 
> I have a few related memos circulating around the FSF offices about
> this, so soon I should have rms etc. opinions.
> 
> Also re: PFV, I just had a talk with Deb (IRC freedeb), maintainer of
> directory.fsf.org, and it turns out that there are plenty of cases where
> you need to look at every file with packages as well, or at least use
> some simple (grep/keyword) heuristics to scan through the files. She has
> some nice (but internally-focussed) write-ups on how she does that that
> may make it to the resources section of the FSF website in the fullness
> of time.
> 

That would probably be handy for all.


-- 
Karl Goetz <address@hidden>

Attachment: signature.asc
Description: This is a digitally signed message part


reply via email to

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