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

Re: ITP: HTSeq



Hello Diane,

On Thu, Aug 01, 2013 at 10:31:09PM -0700, Diane Trout wrote:
> I git rm'ed the files that get generated by the build process and added a 
> debian/gbp.conf file to filter them out of master next time someone does a gbp 
> import-orig.
> 
> I think the entries in debian/source/options will keep debuild's orig diff 
> from complaining about those build-generated files as well.

Fine, git-buildpackage works now.  Nice lesson also for me about
debian/gbp.conf.  I'm not yet that confident with gbp and I'm learning
myself - so please take everythiing I say in this with a grain of salt.

> > Two additional remarks:  If you have *really* good contacts to upstream
> > you can start nitpicking and might give them a hint about the lintian
> > info (which you get via lintian -I) about
> 
> I saw the couple of spelling errors, but as they haven't gotten back to me yet 
> for the fixes to the setup.py, I thought I should wait before sending more 
> patches.

Perfectly fine.  That's why I was stressing the "really" above.  There
is no point in spending time into spelling if upstream let you wait for
other things.  The perfect is the enemy of the good and most probably we
can do more good things in other fields than teaching upstream
orthography.

> > The other thing is that I noticed you have implemented means to rename
> > original upstream version 0.5.4p3 to 0.5.4.3 per uversionmangle in
> > d/watch.  I just want to mention that leaving the 'p' inside the version
> > string would be perfectly OK.  There is no rule that enforces numbers
> > and '.' exclusively.  Feel free to leave it as it is currently if you
> > have your reasons to do so - I just want to mention that it is not
> > needed and in some case it could lead to confusions.
> 
> I undid the mangling, I looked at the debian policy and as long as the version 
> number sort correctly letters are ok. 

Yes, that's what I mean.

> > The next step would be to file an ITP bug report.  Do you want to do
> > this yourself or do you want me to do this (on behalf of the team - so
> > the package wil remain yours).
> 
> I'd like to submit the ITP, though as I'm still learning how to make a correct 
> ITP I'd like a review first.

+1

> Also while I was working on the ITP I changed my previous description a little 
> bit.

Changing is fine.  There is also no strong need to stick to the ITPed
text in the final upload.  Frequently ITPs get aged and upstream evolves
- so that is totally normal.

When looking below just to make sure you are using `reportbug wnpp`:
You can manually send mail to submit@b.d.o but the recommended way is to
use reportbug interface (but I guess you just have choosen this text to
let us know the whole picture).

> --[ITP]--
> To: submit@bugs.debian.org
> Subject: ITP: htseq -- high-throughput genome sequencing analysis.
> 
> Package: wnpp
> Severity: wishlist
> Owner: Diane Trout <diane@ghic.org>
> X-Debbugs-CC: debian-med@lists.debian.org
> 
>     Package name: htseq
>          Version: 0.5.4p3
>  Upstream Author: Simon Anders <sanders@fs.tum.de>
>              URL: http://www-huber.embl.de/users/anders/HTSeq/doc/overview.html
>          License: GPL-3+
> Programming Lang: Python
>      Description: HTSeq can be used for a number of common high-throughput 
> genomics analysis tasks.
>  .
>    * Getting statistical summaries about the base-call quality scores to
>      study the data quality.
>    * Calculating a coverage vector and exporting it for visualization in
>      a genome browser.
>    * Reading in annotation data from a GFF file.
>    * Assigning aligned reads from an RNA-Seq experiments to exons and
>      genes.
> 
> --[ITP]--

I usually append the text in a separate paragraph:

The package is maintained in Debian Med team and prepared for upload in
Git at git://git.debian.org/git/debian-med/python-htseq.git .

Thanks for your work on this

     Andreas.

-- 
http://fam-tille.de


Reply to: