Hi,
just one point I always forget to append at the end of my mails: I'm
personally quite irritated when the language a program is written in is
part of the name. Considering a
linux-c/asm
apache-c
kde-c++
eclipse-java
...
you get the idea. From a users perspective it is perfectly
uninteresting in what programming language some software is written in.
Just a personal hint.
On Wed, Nov 06, 2013 at 04:43:13PM -0500, Yaroslav Halchenko wrote:
> On Wed, 06 Nov 2013, Andreas Tille wrote:
> > > > In any case it has several advantages to at least maintain a clone in
> > > > one of our repositories at git.debian.org because we have some tools
> > > > browsing the repositories and doing some general analysis over the
> > > > VCS status. It would be good if we could do this also for mne-python
> > > > but the NeuroDebian people might have the last word in case they agree
> > > > that they take over the package. In any case it would be really
> > > > interesting to describe the workflow they are using in some kind of
> > > > policy document.
>
> Hi guys -- nice to see a live discussion ;)
:-)
> Indeed we do not have yet as clear policy/workflow as Debian Med does...
The workflow as described in policy is a consequence of enabling
effective cooperation in a larger team and (as I mentioned before) the
fact that some tools are relying on the existence of certain files at
certain places (debian/ dir in VCS at {git,svn}.debian.org).
> in majority of the cases I am trying to "integrate" packaging within the
> (clone of) upstream repository, so to bring lives of both
> "developments" into a single history. Thus it is not an 'overlay'
> repository as Debian Med usually does, but rather a 'debian' branch
> which contains the packaging and merges from upstream's master or
> release branches (if those are divergent from master, it becomes a bit
> more dance). I guess this should be the major difference from how
> Debian Med does it, right Andreas?
I think this is correct. The rationale why we are importing only
released tarballs is, that usually a Debian package is based on a
downloadable release tarball provided by upstream. "Usually" means that
I'm aware that since the advent of Git some people found other ways to
do so and I do not intend to block people from finding new ways which
might fit better under certain circumstances. Debian Med is kind of
conservative to lower the entrance barrier from a packagers point of
view.
The point in policy where it is described is here:
http://debian-med.alioth.debian.org/docs/policy.html#git-tips
In case we might agree to follow this I'd volunteer to create such a
repository based on the last released tarball (version 0.6) and the
current packaging stuff - if this is not to divergent from what is
needed for the 0.7 release. In the later case it might be a good
idea to have some v0.7~rc1 tarball with the current state and I'll
base everything on this until v0.7 is out. For the future I would
like Alexandre to become a member of the Debian Med team and do the
needed updates in the Git repository at git.debian.org/debian-med.
> > "Having in both" is the wrong expression. Debian Med is pure Debian and
> > thus we bring the package into official Debian and it is available for
> > all users in medicine and neuroscience. You might like to understand
> > the idea of Debian Pure Blends[1].
>
> I guess Alexandre meant "in both Debian and NeuroDebian", because we
> would immediately provide backport builds for all supported Debian and
> Ubuntu releases.
Yep. I think I understand what Alexandre meant - we just tried to
explain from different angles.
> I am yet to do thorough review, so if you have a moment indeed it would
> be helpful... e.g. overlooked adding debian/upstream file ;)
It would be easy for me to write such a file if I'd get some link
to the publication. The documentation of debian/upstream files can
be found here:
https://wiki.debian.org/UpstreamMetadata#Fields
It is sufficient to provide the Reference fields only and for the
sake of simplicity I'm always using this very easy template:
http://anonscm.debian.org/viewvc/debian-med/trunk/package_template/upstream?view=markup
> and
> actually this upcoming release AFAIK is rushed to get mne-python
> publication out (so it could be added to debian/upstream for
> references), right Alexandre? ;-)
If you are in a pre-publication phase please think about my hint about
possibly removing the programming language from the name.
Kind regards
Andreas.
--
http://fam-tille.de
--
To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20131106220616.gc13...@an3as.eu
