Re: [Savannah-hackers-public] Re: [Savannah-register-public] [task #9048] Submission of Mudlet

[Sebastian Gerhardt]

Hi Ted,


On Fri, 2009-01-23 at 19:05 -0500, Ted Smith wrote:
> Taking stab #2 at the whole "reviewing projects" thing -- My notes on
> this project:

thanks for your help.
I saw the first maintainer still hasn't answered yet. Do you think we
should give him a time limit?


> LuaGlobal.lua -- no copyright statement
> dlgTimersMainArea -- no copyright statement (file is trivial)
> dlgSystemMessageArea.cpp -- no copyright statement (file is trivial)
> dlgTriggersMainArea.cpp -- no copyright statement (file is trivial)
> ctelnet.cpp -- GPL seems applied incorrectly, copyright date range
> 
> No copyright notice in /src/ui (XML data files)
> No copyright notice on flowchart in /src/doc
> No copyright notice pertaining to any of the images, in /src or in 
> /src/icons
> No overarching project README
> Dependancies not clear (QT4, Lua, ?qcsi?)
> 
> Uses term "linux" in name of linux.conf, and in about_dialog.ui.
> 
> "Documentation" has no license.
> 
> Project already has its own website and sourceforge account.
> 
> *NB*: I do not have KDevelop installed and thus could not browse the
> source the way the developer intended.
> 
> Should I clean this up into something that can be sent to the developer?

This looks fine to me. Of course, some flaws are more serious than
others and I usually try to hint the maintainer about this. For example,
the unclear licensing of the media files will certainly block the
package until this has been sorted out whereas the README is more like a
recommendation. If the sparse documentation has no explicit license text
in them, it would be ok if the author writes about this in the README.

I woulnd't object if a file is called "linux.conf". Often, targets in
makefiles are labeled "linux" too and we don't mind. But in any
"advertising" context, we should be firm. (Program output and dialogs,
project description, etc.)

As regarding the trivial files, I rate them on the question whether they
will be likely to grow in the course of time. If they do, the maintainer
can as well put proper copyright&licensing text in them right away. And
if we tell him now, he will most probably keep up this practice in the
future. The same goes for the date ranges.

The maintainers are welcome to have they own project homepages but they
should give a statement about what they plan to do with the sourgeforge
account.

Again, thanks for you help in reviewing such a big package.

Sebastian