[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