[Debichem-devel] Bug#866417: bkchem is marked for autoremoval from testing

[Stuart Prescott]

Hi Daniel,

I'm aware that you have misgivings about git-buildpackage; note that use of 
git-buildpackage is absolutely not required in order to package things in git. 
You can store the package in git and then run dpkg-buildpackage -S yourself. 
There are alternative tools like gitpkg too. From what you write in #796816, a 
few lines of shell script would do all that you want, not using "gbp 
buildpackage" at all. Pointing at numbers of bugs is not a useful argument for 
whether tools are suitable or not -- take a look at the number of bugs against 
subversion, dpkg, apt or src:linux.

I'm surprised that you can't achieve what you want with either a tiny change 
to your setup or with a few lines of shell script to call gbp to build the 
source package and then push it to your builder. Yes, this will take a little 
time. I have no expectation that gbp is a drop-in replacement for svn-bp any 
more than git is a drop-in replacement for svn or sbuild a drop-in replacement 
for pbuilder. Sure, there's a cost in conversion. 

You say that git makes it impossible for you to contribute and that is simply 
not going to be true. It might make it slower for you to contribute initially 
and it might even mean some downtime in your contributions. It is definitely 
not going to be impossible, however.

That you are currently the only person maintaining some of these packages is a 
significant problem. I have wondered several times how much of that is because 
no-one other than you can be bothered dealing with subversion any more. I know 
that I have not contributed fixes to packages because I've not had a working 
svnbp setup for close to a decade and can't be bothered dealing with the 
debichem svn which is so utterly different to any other team's svn that I ever 
dealt with. The mailing list shows that I'm not alone. Team members dealing 
with team packages as if they were doing NMUs isn't team work.

Is it possible that an insistance on sticking with svn effectively cuts off 
others from contributing? Debichem is a small team and we can't afford to be 
pushing away contributions. We have had several situations of late where RC 
bugs have been open for weeks and you have not been able to deal with them. We 
all get busy, that's not a problem and that's why we have maintenance teams; 
what is a problem is making it hard for others to help out.

A single contribution from someone else fixing a bug in a package for you will 
give you back whatever time is involved in converting your workflow from svn 
to git. A second contribution puts you ahead and you keep winning from there. 
I fixed an RC bug in bkchem the other day for you so there's the downpayment 
on your time for conversion :)

I know that, to fit in with various teams, I have altered my workflow several 
times over my years of Debian package maintenance. Working across several 
teams even means using several different workflows at the same time for 
different packages. Sometimes, the long term sustainability of the team and 
the packaging requires that.

There are some things that can't be ignored

* alioth is going away

* svn on alioth is going away

* contributions are being pushed away by the use of svn

* converting in a hurry at the last minute before alioth is decommissioned is 
going to be error prone, stressful for all involved and likely to be at a time 
when you (and the people helping with the conversion) have even less time to 
invest in workflow rather than packages.

Perhaps we would be better investing the time in fixing the tooling or the 
workflow and converting to git rather than arguing about it and then ending up 
in a black hole in a few months.

regards
Stuart


-- 
Stuart Prescott    http://www.nanonanonano.net/   stuart at nanonanonano.net
Debian Developer   http://www.debian.org/         stuart at debian.org
GPG fingerprint    90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7