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

Re: Bug#689041: RFS: orthanc/0.2.1-3 [ITP] -- Lightweight, RESTful DICOM server for healthcare and medical research



Hi Sebastien,

On Tue, Oct 09, 2012 at 11:04:40AM +0200, Sebastien Jodogne wrote:
> 
> (1) Should I create a Subversion tag for the upload by myself, or is
> this the responsibility of the uploader of the package?

I think we do not have any written rule for this.  I personally ask the
sponsee to add the tag once the package is *accepted* in unstable.  For
the case it doese not pass ftpmaster I do not see any reason for tagging
because the package has never hit the official mirrors.
 
> (2) I am not sure to understand how I should cope with the unit tests:
> a. Are they to be automatically run as a part of the build process
> (if the CMAKE_CROSSCOMPILING flag is OFF)?
> b. Are they to be distributed along with the Orthanc binaries (e.g.
> under the name "/usr/share/orthanc/UnitTests")?
> c. Are they to be simply ignored (as it is the case for now)?

The tests should be run in the packaging process using identical files
that will be inside the package.  If  dh_auto_test  might not trigger
running the test suite you should probably enforce this using

  override_dh_auto_test

> (3) I would like to put my code on Subversion for backporting
> Orthanc to squeeze:
> a. Can I do it now, or should I wait for the sid package to be ready?

We do not have much examples for maintaining backports in SVN (probably
because most (if not all) of our packages build nicely on backports.  If
you need to change something I would consider it a good idea if it is
accessible via SVN.  For this I do see two options:

  1. Either really do the tagging of the upload before the package is
     in unstable while beeing prepared to deal with some rejection from
     ftpmaster - finally it is no real harm if we might remove a tag and
     add a proper one in case of some changes needed at ftpmaster request
  2. or you jast maintain backports in a branch which is fine as well

Feel free to decide which way might fit your workflow best.

> b. If I can work on this right now, how should I call this package
> (orthanc-0.2.2-6~bpo60+1 apparently [1]), and in which directory
> should I put the code in Subversion?

In the case of the second way use

   trunk/packages/orthanc/branches

otherwise you might like to keep working in trunk in case you only need
to change the d/changelog file for this and use proper tagging.

BTW, I personally prefer a versioning 0.2.2-1 for the first upload of a
package (independently what might have previousely existed on
mentors.d.o) but if Matthieu was fine with sponsering, yes the suggested
naming for the bpo package seems to be reasonable.
 
> We are working hard at the CHU of Liège on Orthanc, as it will
> greatly ease our data management for clinical processes.

Good luck with this.

Kind regards

         Andreas.

-- 
http://fam-tille.de


Reply to: