On Wed, Mar 26, 2008 at 2:50 PM, Andreas Tille <[EMAIL PROTECTED]> wrote: > On Wed, 26 Mar 2008, Teemu Ikonen wrote: > 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
Oops, indeed these were missing, I've now added the Vcs fields to both rasmol and cbflib and fixed the build-deps. I also forgot to close some bugs in the rasmol changelog. The packages have been updated to fix these issues. > > 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. Again, I have nothing against changing the Maintainer field to e.g. DebiChem in these packages, if this does not impose a workflow I consider sub-optimal. Let me expand a bit on how I think version control should be used in packaging: When I check out a packaging branch from a VCS repository, the result should be a working tree containing the whole upstream source plus debian files and modifications. One should be able to build binaries right away with debian/rules binary, and a source package with dpkg-source, given an orig.tar.gz. With git and pristine-tar, the orig.tar can be very easily generated from the repository with close to zero additional space cost. What kind of a source package is then generated from the VCS sources is a somewhat unrelated issue. The traditional diff.gz with all the changes applied to the source is nice for simple packages with only small changes. Having quilt / dpatch patch stacks inside the diff is ugly and needs extra build-depends, but allows for separation of patches for different functionality, which is nice. I think a good compromise would be the wig and pen source package format ( http://www.dpkg.org/dpkg/NewSourceFormat ) with support for unpacking and packing the source with applying and generating patch sets automatically in dpkg-source, but its implementation is apparently prevented by some strange dpkg politics. A source package format containing a VCS repository is too much crack for my taste, and imposes a tool preference to anyone working with the package. I recently made scripts which flatten an arbitrary number of feature branches in a VCS (git in this case) to series of patches, so generating source packages in e.g. quilt format out of VCS repositories is possible in principle, it just needs tools which are not standard or well known (or in this case even published). > 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. Just a note, distributed VCS's are converging fast and converting from one repository format to another is already easy. Probably (hopefully) in the future this conversion will be made automatically, so that different programs can push and fetch from each others repositories transparently. Regarding your developer page, writing a small post-commit / post-update script which updates the "recent activity" section in the Debian Med page should be possible for any VCS. This hook should then be installed on every VCS repository on alioth which is part of Debian Med. > - What is the extra value that git adds to the Debian-Med project? The same as in every other distributed VCS, disconnected operation and very easy branching and merging. > - Would git2svn be an acceptable alternative / compromise to > be able to cooperate? Two-way syncing between SVN and most other distributed VCS is possible (I've tried it with bzr and git). The problem here is not really subversion, but svn-buildpackage, which encourages storing only the debian dir. I suppose it would be theoretically possible to write scripts which synchronize this kind of partial branches with a branch containing the full source and applies patches etc., but this would be a lot of work for an application that is Debian specific and IMO not a recommended way to maintain packages in a VCS anyway. Disk is cheaper than peoples time. > - Would you volunteer to convert the existing SVN completely > to git and convince others to use git from a certain point > in time? Even in team maintenance there are people who work more on some packages than others and these persons should decide for themselves what tools they want to use. Although I don't have that much interest in Debian Med or DebiChem, or the tools you have, it would not hurt to make the projects more VCS agnostic. > [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 Best, Teemu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
