[Neurodebian-upstream] Debian package for mpi4py

[Yaroslav Halchenko]

Hi Yuri,

> I have found your ITP bug, but no other information so far. Do you
> already have a git repo with some basic stuff in?

if you want to help with packaging and co-maintain, or even take over
so we then only mentor/sponsor your uploads into Debian and
provide backports (if any) from neuro.debian.bet -- you are welcome to
do so!

We have filed an ITP but haven't looked at packaging it yet besides
creating a "proper" GIT clone of the SVN... I could push it if you
like so you could use it too to track SVN repository from GIT.

> (1) unfamiliar with git-based packaging stuff / repo layouts (for my
> personal projects I just track debian folder and for mc we have svn)

Well, if you jump-in, whatever fits you best would work for us.
Only that we would really prefer use of GIT for packaging, but it is
also not too critical since we could interact with out via git svn.

For GIT packaging I am using git-buildpackage which makes things
easier I think.  For the basic intro, enjoy Guido's talk at debconf10
http://penta.debconf.org/dc10_schedule/events/634.en.html or just
glimpse through the documentation
http://honk.sigxcpu.org/projects/git-buildpackage/manual-html/gbp.html
or little howtos like http://workaround.org/debian-git-comaintenance

ourselves we quite often diverge from the flow where packaging is based
on top of upstream source distribution tarballs imported into VCS (or
just with --overlay feature, similar to svn-buildpackage's
mergeWithUpstream).  Some projects (including .orig.tar.gz) get built
directly from GIT VCS which is either reliably linked to upstream SVN or
just an additional branch within (e.g. scikits.learn [1]) or outside
(e.g. joblib [2]) of upstream GIT repository.

Basing on upstream VCS is done for easier interactions between packaging
and upstream -- so we could easily build from any snapshot of upstream
repository (e.g. when upstream informs us that release is coming sooon);
or cherry-pick/commit necessary fixes directly upstream (if they grant
us permission) while upstream is getting ready to kick out a new
release.  Also with such setup 'debcheckout' provides user with a
complete repository not only for packaging but also for upstream, so
people could get involved and contribute with ease.

[1] https://github.com/scikit-learn/scikit-learn
[2] https://github.com/yarikoptic/joblib

> (2) don't want to re-invent the wheel if you already have something to
> start with, I'd rather take this and update it to the usable condition

smart decision ;)  So, just decide how do you want to proceed (just take
over or co-maintain)... 

-- 
=------------------------------------------------------------------=
Keep in touch                                     www.onerussian.com
Yaroslav Halchenko                 www.ohloh.net/accounts/yarikoptic