[Clfs-dev] Code Review Tools

George Makrydakis gmlistbox at obsethryl.eu
Thu Oct 23 10:42:37 PDT 2008


On Thursday 23 October 2008 16:53:59 Ken Moffat wrote:

Hi Ken.
[snip]
>
>  As an editor, my view of bugs in clfs is that they fall into the
> following categories:
>

I agree with what you say. What do you think that could attract more people in 
clfs?

>
>  For the xml in the book, I don't think "code review" either happens
> or is necessary.  Provided the book validates and renders, that
> should be enough.  Sometimes, people might make stylistic comments
> but they can do that do that from the rendered book.  Sometimes, we
> change something and accidentally replace an instruction for another
> architecture (I know I've done this).  Anyone who looks at the
> commits can review them, but these problems are usually less than
> obvious - they're one of the downsides to how clfs is marked up.

Hmm, I do consider xml to be code as well, but I can see your point. I think 
that right now yes, it may not be necessary given the amount of steady 
editors. Yes, docbook is one of the problems btw.

>  Where people are writing code, code review is good.  In my opinion,
> what clfs needs is more people to use it and to comment on it,
> particularly for non-x86_64 (even x86 appears to be a minority
> interest here).

Do you totally exclude joined, live review on the parts that are related to 
the build process itself? Right now, in view of both the markup and the 
amount of people involved in the editing process - communication through the 
list, emails, IRC -  it may not be immediately necessary. But do you think 
that should separation between the scripts and the actual text be in the 
standard norm of editing clfs in some future (not far away hopefully) 
actually takes place would bring such a need? I think that a "code" review 
tool integrating with the bugs whether textual or not, could be of help.

This is just something I am thinking of course, nothing I am proposing or 
anything. Just wanted to see what the list here thinks regarding this.

> ĸen

George



More information about the Clfs-dev mailing list