How to create a Git repository in Debian Science (Was: Jmol: Seeking new maintainer or considering removal)
Hi Georges,
since it might be of general interest I describe all the steps to create
an expeyes in Debian Science git right on the list as an example for
others.
On Sat, Mar 08, 2014 at 04:25:27PM +0100, Georges Khaznadar wrote:
>
> I used SVN formerly, but Git is increasingly used out there, so I learned
> a part of Git. I am now more proficient with Git, which provides some
> additional features, even despite my poor knowledge.
I admit I was also only teached by my packing team mates into Git and
for the packaging you really need only a subset of Git features. So I'd
recommend to stick to this (for the same reason you mentioned above).
> > http://debian-med.alioth.debian.org/docs/policy.html
> >
> > is quite helpful when seeking for SVN or Git. I personally learned the
> > Git workflow by using this document. Since the Debian Science policy at
> > some point in time was derived from this document it is basically
> > exchanging the base URL. DebiChem has not yet such a document
> > (unfortunately) but it is also quite the same. Feel free to name a
> > certain package you want to start with and I'd happily volunteer to
> > inject it into a VCS of your choice (SVN or Git + team you consider
> > reasonable).
>
> A package which deserves this enhancement is 'expeyes'. I maintain its
> upstream source tree in https://github.com/expeyes/expeyes-programs/,
> the last packaged version is available by the tag 'v3.1.7'
>
> I tried to watch the directory /git/debian-science in git.debian.org
> It provides no script setup-repository, and applying blindly
> ../debian-med/setup-repository would be a mistake since a few parts of
> that script are hard-wired to use 'debian-med'.
Ahhh, Debian Science decided for
/git/debian-science/packages
and there is a setup-repository script.
> As creating the first upstream repository may be a little tricky (I
> think about the hooks which must fit real services), I shall gladly
> accept your proposition of injecting 'expeyes'.
OK, I did:
On Alioth:
tille@moszumanska:/git/debian-science/packages$ ./setup-repository expeyes 'hardware & software framework for developing science experiments'
Initialisierte leeres gemeinsames Git-Repository in /srv/git.debian.org/git/debian-science/packages/expeyes.git/
Locally I did:
$ apt-get source expeyes
$ mkdir expeyes
$ cd expeyes
$ git init
$ git import-orig --pristine-tar ../expeyes_3.1.6.orig.tar.gz
$ cp -a ../expeyes-3.1.6/debian .
$ git add debian
$ git commit -a
$ git remote add origin ssh://git.debian.org/git/debian-science/packages/expeyes.git
$ git push origin master
$ git push --all --set-upstream
$ git push --tags
$ dch --team
$ vi debian/control
$ git commit -a
$ git push
I took all this from Debian Med policy with the only exception that the
repository on alioth is not debian-med but rather debian-science/packages.
I'd recommend you use
gbp-clone ssh://git.debian.org/git/debian-science/packages/expeyes.git
to get the result. When using git-buildpackage gbp-clone and gbp-pull
are your friends since these are regarding all branches you need.
> > > Is there a solution for "low-noise contributors"?
> >
> > If you fear those mailing lists it also helps to inject the packages
> > there (which means adding the team mailing list as maintainer and you as
> > uploader) and afterwards simply subscribe the package in PTS which keeps
> > you informed about exactly these packages but leaves other team members
> > a chance to cooperate with you on the packages in VCS.
>
> Such a solution seems nice: I must get the bug reports about the
> packages I care, and people must know easily whom to talk when they want
> to exchange privately about a package.
As long as you do not get annoyed if people (like me) CC the relevant
list to keep others informed ... (as I'm currently doing) that's fine.
> Archives of Debian-med feature a traffic of about 10 messages per day;
> Debian-science's traffic is 10 times lower, Debichem-devel 5 times lower
> (those rough numbers are valid for last month)
>
> The problem for me is the mix of "automated" e-mails (^Bug#,
> MIGRATED, Processing.*changes, ACCEPTED), together with handwritten
> e-mails which deserve more general attention in my opinion... hmmm... I
> never thought about it in this way: maybe procmail rules would be
> efficient to sort them out.
+1
> Thank you in advance for the Git repository.
This was a pleasure. Just tell me if you need more detailed advise.
Kind regards
Andreas.
--
http://fam-tille.de
Reply to: