On Sun, 30 Mar 2008, Steve M. Robbins wrote:
If I can be permitted a naive question: is Debian-Med restricted to a
single VCS for some reason?
I do not regard this question as naive and the answer is definitely _no_.
Last week I wrote a mail about this to Debian-Med list and DebiChem list
in CC but strangely enough it is not archived in both lists (at least
I can not find it) and thus I quote myself here and would like you to
read my position there starting from "Regarding the Debian-Med team ..."
So there is no need for a restriction and Debian-Med is a project to
support Free Medical Software and not to promote a certain VCS. So
people are perfectly free to choose - but it just helps to settle down
with at least as possible different tools. Until recently it just was
SVN exclusively but at least two members of our Alioth project claimed
that they want to work with git. I'm just trying to find a consensus
which might even end up that somebody else (perhaps cron - I don't know
whether this works, I do not know git) calls git2svn for these two
that we can stick to SVN with the tools around Debian-Med or whether
we should enhance theses tools to work on more than one VCS (but nobody
volunteered to actually write the code.
I find subversion fine, personally;
Same for me.
but if twelve others prefer git, can that not be accommodated?
Well, I have heard good reasons for the usage of git which did not convinced
me personally to spend some time to learn something new and change my
personal workflow. I would be willing to adopt my personal workflow
to git if I would see advantages for Debian-Med to switch at a whole -
but currently I see neither an advantage nor somebody willing to take
over the work. I'm very afraid that before we might have finished an
imaginary svn -> git conversion somebody else comes up who wants to use
just another VCS - so the whole point of a common VCS for the project
seems to be not possible to solve if people do not consider it as
important to adopt to a common arangement. We have no means to enforce
our policy and I don't think that the policy has to be a precondition
to work on the project. IMHO, the only chance to get people to follow
the policy is to make it so good and tools around the stuff we are doing
so cute that they _want_ to follow the policy. This is a really hard
job and I'm fighting along this line for 5 years now to make people
adopt the CDD idea in other projects to make them understand that
using a common technique has advantages they would like to have in
their own project as well.
So currently the usage of git instead of our common svn has the only
disadvantage that commits are not listed at
http://debian-med.alioth.debian.org/
This is obviousely not very convincible. But we might invent more
interesting features...
Kind regards
Andreas.
--
http://fam-tille.de
From [EMAIL PROTECTED] Wed Mar 26 14:50:18 2008
Date: Wed, 26 Mar 2008 14:50:18 +0100 (CET)
From: Andreas Tille <[EMAIL PROTECTED]>
To: Teemu Ikonen <[EMAIL PROTECTED]>
Cc: Debian Med Project List <debian-med@lists.debian.org>, [EMAIL PROTECTED]
Subject: Re: Build-dependency for rasmol: cbflib
On Wed, 26 Mar 2008, Teemu Ikonen wrote:
Rasmol upstream has now released version 2.7.4.2, which also contains
my GTK patches. I've made new packages of rasmol and the new
build-dependency cbflib. The source packages are at
http://esko.osmas.info/~tmx/cbflib/ and
http://esko.osmas.info/~tmx/rasmol/
Great!
I also changed the version control system for these packages to git,
and joined the Debian collab-maint group at alioth, the repositories
are accessible at http://git.debian.org/
If you maintain your packages in a VCS please add propper tags to
the control file. My wild guess is, that they should look like
Vcs-Browser: http://git.debian.org/git/collab-maint/cbflib.git
Vcs-Git: git://git.debian.org/git/collab-maint/cbflib.git
but please verify this - I have no experience with git. Please
add proper lines to debian/control. Moreover there are two
Build-Depends missing: m4, gfortran
If you try to use pbuilder to build the package it fails without
these build depends. Furthermore lintian throws an info notice:
I: cbflib source: source-contains-cvs-control-dir include/CVS
N:
N: The upstream source contains a CVS directory. It was most likely
N: included by accident since CVS directories usually don't belong in
N: releases. When packaging a CVS snapshot, export from CVS rather than
N: use a checkout. If an upstream release tarball contains CVS
N: directories, you usually should report this as a bug to upstream.
N:
Please teach upstream to distribute proper tarballs without CVS
directory.
So far for the packaging itself. For other readers I would like to
add the hint that IMHO the library should be packaged as pair of
lib/libdevel package but we might leave this for a later version of
the package if somebody volunteers to fix the build system regarding
this.
Team maintenance for these packages is ok, if the team in question
wants to work with git.
For the package in question the DebiChem team (in CC) comes into
mind as well. Moreover team maintenance does not necessarily
requires the use of a VCS. It is using a common list as Maintainer
and some Uploaders in the first place.
Regarding the Debian-Med team we just had the git issue arising
last week[1]. The issue has two sides:
1. We - the Debian-Med team - does not really want to exclude
people just because of some VCS preferences, we are less
people enough and need every helping hand.
2. On the other hand an individuum should recognize that staying
in a group has advantages and that it is sometimes not possible
to set preasure on the group like: I will join your team if
you are using bzr, darcs, ... (include your prefered VCS here)
because this would keep the group busy in handling different
VCS (believe me, git will not stay the latest and greatest)
and developing tools that add great value to maintenance like
our developer page[2] will become more and more complex for
less profit.
So I'm not against git, but I'm against adding just another VCS if
there are no clear reasons for this specified (I do not accept a
"personal preference" as a reason).
- What is the extra value that git adds to the Debian-Med project?
- Are you volunteering to enhance the group policy[3] to explain
how to use git?
- Are you volunteering to add git parsing code to the web tools
we have developed?
- Would git2svn be an acceptable alternative / compromise to
be able to cooperate?
- Would you volunteer to convert the existing SVN completely
to git and convince others to use git from a certain point
in time?
These questions are not particularly targetting at Teemu, but we
will have to deal with these sooner or later. So we should be
prepared to have a clear opinion how to proceed in the future
because I see no chance that the number of popular VCS will
decrease.
[1] http://lists.debian.org/debian-med/2008/03/msg00150.html
[2] http://debian-med.alioth.debian.org/
[3] http://debian-med.alioth.debian.org/docs/policy.html
--
http://fam-tille.de
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
