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

Re: [MoM] incorporating phyutility into the packages



Hi Stephen,

On Thu, Mar 20, 2014 at 10:05:16PM -0400, Stephen Smith wrote:
> Hopefully, yes! I have tracked down as best I can, all the authors of
> the original JEBL and the LGPL version that it was under. These have
> been added to the copyright.

Looks good to me.

> The removal of the dep of jebl2 was pushed
> and the adding of the bug number was done. So, I think that is it?

Nearly.  I stumbled upon the manpage where help2man did a bad job.  Due
to a bug it did a repeated output (which I deleted).  You should also
always call help2man with '--no-info' option since otherwise it appends
a paragraph which directs to a texinfo manual which usually never
exists.  Help2man was also unable to detect the proper name of the
program and in the NAME section it added "don't" as name.  This is
fixed.  I did some more syntactical fixes since I could imagine that you
might not be that used to manpage editing.  As a hint for editing
manpages:  I'm usually using mc (MidnightCommander) and when pressing F3
on a manpage it is rendered like with man - so you can quickly check
your edits.

So far for the syntactical things in the manpage, but there is some
missing content.  The DESCRIPTION section is somehow suboptimal and you
are refering to "the documentation" - but where is this.  At least not
in the package and thus a link would be helpful.  Please also provide a
simple example since I'm not sure whether I've got the SYNOPSIS correct
(please also check this).  The goal of the manpage should be to provide
some quick entry for users or some reminder how to use it after having
read the extensive docs without forcing them to reread the docs over and
over.

> Let
> me know if there are additional things that need to be done or other
> testing that I should do. 

If the manpage is fixed I will upload the package.  If you are unsure
about the syntax please just inject the content and remind me to check
again.

For future upstream versions I would like you to consider two things:

  1. It might make sense to rely on the maintained jebl2 instead of
     maintaining a private jebl (otherwise I's recommend to explain
     your reasons for sticking to jebl in some README to let others
     understand.

  2. We try to provide unit tests as much as possible (see the current
     discussion about reproducible science on the Debian Med mailing
     list).  These could be run at package build time and also later
     using autopkgtest in an automated process.  So if you could provide
     such tests this would be really great (independently from the
     Debian packaging for sure to let others profit from it as well)

Kind regards

     Andreas.


-- 
http://fam-tille.de


Reply to: