savannah-hackers-public
[Top][All Lists]
Advanced

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

Re: [Savannah-hackers-public] my intro


From: hiren
Subject: Re: [Savannah-hackers-public] my intro
Date: Thu, 11 Dec 2008 09:24:29 +0200

On Wed, 2008-12-10 at 17:10 -0600, Karl Berry wrote:
> gnu in project name:          Pass
> 
> It's ok to have "gnu" in the project name if it is a gnu package.  I
> don't see how your script can easily have access to that bit, though.  I
> suggest saying "yes" or "no" instead of "Pass or "Fail"; that will
> remind humans that it's a factor.

cool, will adjust.

> 
>     -- Searching for file 'license' in any case in root dir
> 
> The license file is most often named "COPYING".  It should accept
> anything starting with that.

okay will do, beside "COPYING" or "LICENSE", is there other files we
should look for, do we have a convention about what files to accept as a
license file?
I've seen some with LEGAL as well, not sure if that was a license
though.

> 
>     address@hidden:~/Desktop/tempcontent$ ./gnu_chkproj.pl -v
> 
> Perhaps the verbose output should always be shown (ie, no verbose flag).
> The humans running this should not blindly take its results on faith.

cool, I'll leave the diagnostic messages to a debug flag, and remove the
verbose.

> 
>     any comments/suggestions are welcome.
> 
> In terms of the code, here are some suggestions:
> 
> 1) I suggest having a main() function and making the top-level code do
>    basically nothing but load packages and call main.
> 
> 2) You don't check the status of the second call to chdir.
> 
> 3) I suggest using #!/usr/bin/env perl; that will work on more systems.
>    And there is no need for a #! line on the .pm file; it isn't used there.
> 
> 4) I suggest renaming the script to, say, "sav_chkproj" right now,
>    before the "gnu" goes any farther.  This isn't about GNU packages,
>    it's about savannah.
> 
> 5) I suggest keeping source lines to <= 79 chars.
> 
> 6) I suggest an explicit return 0, or perhaps returning 1 if anything
>    fails and 0 if all is well.  In any case, falling off the end is not
>    good.

all sound good to me, will adjust.
thanks for your feedback!

> 
> Best,
> Karl





reply via email to

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