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 -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: https://lists.debian.org/[email protected]
