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

[Daniel Leidert]

Hi Stuart,

> 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.

I'm well aware of that. In fact:

> 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.

No, it would not. IMO the only thing you read and understood in my
bug report, was the part about moving the resulting source package.
Indeed, this could maybe be done in a different way. But git-bp is
also broken related to the configuration of layouts?! Please read both
bug reports. So being completely broken, I'd have to copy and move things
around manually. But thn why should I use a VCS in the first case?

> Pointing at numbers of bugs is not a useful argument
> for > whether tools are suitable or not

Of course it is. Many of those reports have probably been raised by people
like me, trying to switch from $(VCS) to Git. In my special case, it is
even a real bug, because the programming in git-bp regarding the variable
extension in hooks/commands follows no logic. This can easily be fixed and
if the author/maintainer is not able to do this, then the project should
help.

[..]
> I'm surprised that you can't achieve what you want with either a tiny
> change

Please stop assuming this. You can read all about my setup here [1]. You
are free to try yourself and come up with suggestions.

[..]
> Sure, there's a cost in conversion.

Please note, that I already put effort in this more than two years ago.
I also put the effort in checking the cause for the problem and reporting
it. So please stop this patronizing behaviour of yours.

> 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.

Stop this, please. I'm well aware of the situation. I'm not willing to
accept, that this misguided move will make things ten times slower for me.
I can easily setup a running subversion server and maintain the packages
I care about myself. AFAIK there is no requirement to team-maintain
anything. This is still much faster than what you propose. And I also find
it inapropriate, that you are trying to decide about my time.

> That you are currently the only person maintaining some of these packages
> is a
> significant problem.

Really? In which regard? Before you answer: please check the bug count
on your own packages.

> I have wondered several times how much of that is
> because
> no-one other than you can be bothered dealing with subversion any more.

Would you mind telling me on which occassion you have wondered about me?

> 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

Interesting. But above you raised the claim, that I should do that.

> 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.

That is simply not true. It is a standard layout, which was also used
on other projects.

> The mailing list shows that I'm not alone.

Who you are referring to? I havn't seen any other constributor saying his
mind and I have only made a decision for packages for which I feel
responsible.

> Team members dealing
> with team packages as if they were doing NMUs isn't team work.

This was never the case here. And you haven't done a thing?! You did one
upload, that changed the VCS without any permission by the maintainer(s)
and that could have easily done as NMU in accordance to the Debian
policy. So what do you think, qualifies you for such a comment?

[..]
> 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.

You are the only one pushing away contributors atm. And this in an
inapropriate way. Ah and the rest of your writings is a fairytale. The
debichem project has grown in contributors over the years. I cannot
remember any discussion, that we would need to move everything to Git
to get contributors.

> 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.

Would you mind enlighten me, which situations you are referring to? There
was one bug in c-m-d, which was fixed via NMU in *days* in accordance to
the Debian policy. Are you referring to bkchem, the package you uploaded
recently? This is your argument? A minor change in debian/control, that
could have been done easily via NMU? And "weeks" here means 2,5 weeks,
right, with several holidays and my own birthday in it?

And JFTR: That change was so important, that you didn't even have the
politeness to ask the maintainers, if it is ok to change the VCS?
Something even Andraes did. And *that* was your very first thing you did
in a team
you are new to. Now please stop talking about behaviour.

[..]
> I know that, to fit in with various teams, I have altered my workflow
> several
> times over my years of Debian package maintenance.

I'm a bit longer around in Debian than you and one of your fellow DDs.
Maybe you wanna re-think your behaviour and your attitude. When I read
your mail, I feel patronized by someone, who is rude, disrespects team
mates and fellow DDs and hasn't earned any of my respect.

[..]
> There are some things that can't be ignored

I hereby say it again: I'm not ok with moving travis, shelxle,
gnome-chemistry-utils, gamgi, gabedit and chemical-mime-data to Git.

Regards, Daniel