[Debian-med-packaging] Glasso, QUIC ...

[Laszlo Kajan]

Hello Matyas!

>> I got the approval for OSS involvement. Now I am bogged down on one issue... I hoped you may have some insight.
> 
> This is great news!

You may want to consider doing a Mentoring of the Month [1] with Andreas Tille.

[1] http://wiki.debian.org/DebianMed/MoM

>> It is about revision control and project maintenance. The background: The QUIC code was developed at UT Austin and we used CVS, because that was
>> supported. Finally a git server is available (gitolite) and I converted the CVS repo to git. I started to use git and now that is my choice for
>> new projects.
>>
>> However, I have a hard time figuring out a good setup that would work for distributing the code under debian (and else?) while doing development
>> on related code. (At UT we are currently working on a version of QUIC to run on very large matrices.)

Let us put git TAG-based releases aside now. Normally the workflow is like this:

1: Upstream (you) release a new version of QUIC as a quic-X.Y.Z.tar.?z.

2: There is a Debianization held in a VCS somewhere on alioth.debian.org. The essence of this Debianization is a debian/ directory that holds
all files necessary to create a Debian (and derivatives) package out of the upstream tarball.

3: Your upstream tarball is combined with the Debianization, and a new Debian package is built.

As you see, the Debianization is kept well separated from the upstream code. This is good because the group of people likely to modify the
upstream and the Debianization is quite different. Since the Debianization lives in its own repository, you do not need to worry about this
part, when designing your upstream repository. All you need to do is bring out your releases as neat .tar.?z archives.

>> My usual setup (until now) at UT as a student was to have a project directory for the latex files and under it a Code directory for the scripts
>> and programs. Under this Code dir I have the Makefile and else that is needed to produce the Matlab and R packages.
>>
>> Recently someone contacted me and told me they made a Python wrapper for the QUIC package with the code distributed on github. (pyquic)
>>
>> So I am trying to figure out how can I structure the repos so that I would allow outside contributions, while have some development that is not
>> public (new versions not ready to distribute before publishing for example). I thought using git submodules and I am reading up on that.
>>
>> So the goal is that I would have only a single repo for the QUIC code, but it could be a part of my research paper repo and the debian/R package
>> repo, would allow the python wrapper etc. I am realizing that this is not as easy to structure as I originally thought.

As stated above, you do not need to worry about the Debian part of the story. When upstream gets combined with the Debianization, any /debian
directory that comes from upstream is discarded anyway (dpkg-source(1), Format: 3.0 (quilt)).

>> Maybe this is not something you could comment on. If you can point me to someone that you know has a similar problem and found a good solution,
>> I would appreciate a pointer... Maybe I should post on a git forum...

Some of the Med Team know a lot about git. Sure, the more you ask the better! :)

Best regards,
Laszlo