Hi Niels, Niels Thykier wrote: > I understand that you are unsatisfied with this proposal and that is > fair.
Thanks. > Though from my point of view, your email makes it hard for me to want to > engage with you to find a solution that would (ideally) satisfy your desires I'm sorry, but at that point I have to say the very same about your previous e-mail. IMHO this is not a one-sided thing. See below for an explanation. > as well as solve the underlying problem that Steve wants to have > solved. Well, your proposal IMHO shoots wide of the mark and only leaves very few room for discussion. (If you think, I'm totally wrong here, please see below for a possibility where we might have misunderstood each other.) Actually I was totally fine with what Steve requested. Additionally, cloning bug reports for lintian and lintian-brush already sounds very final, too. (Except for the mentioned, IMHO very minor details around debian/README.Debian and debian/TODO, which IMHO also overshoot.) > Notably, nowhere in your email can I see any attempt from you to say > "Could we find an alternative where single binary source packages > can still leverage this short cut, because I find it very valuable?" > in a neutral or constructive manner. Mostly because Steve's suggestion was totally fine for me, just caring about multi-binary packages and forbidding non-prefixed debhelper files there. This makes sense! Which is also why I haven't joined the discussion so far. His proposal was sane and affects likely only a few packages where multi-binary packages have non-prefixed debhelper files, which is bad thing and can easily lead to barely visible packaging errors as with the case in which he ran into initially. (Actually I ran into such issues in the past, too, when switching single binary packages to multi-binary packages. But even before Steve's bug report, I was generally aware of that issue.) But the proposal in your previous mail (at least as far as I understand it even after reading it a second time) goes much farther and wants to forbid non-prefixed debhelper files "generally". And I read this "generally" as "for any package, single- as well as multi-binary packages". And that's what I'm not happy with at all. Maybe it was meant differently (if so, please elaborate), but that's how I understand "generally". (And I know, we're both no native English speakers, so any of us might be wrong here. That's something which I indeed didn't take into account when I wrote that other mail out of frustration.) Additionally the phrase "I am open to not installing them [debian/README.Debian, debian/TODO] by default if one of you are willing to drive the discussion on debian-devel to assert there is consensus for that." implies for me that there is no room for discussion on any other part of your proposal. > Instead, it feels to me like you are dumping your frustration on me It _is_ frustration, that's very correct. Like on that chomping changelog thingy which — as far as I can see — has only been discussed on debian-devel (which I and probably many other DDs don't have time to follow due its huge amount of traffic), but not in any debhelper bug reports — which I do follow, because I have an interest in debhelper and that it is cared about — nor has the discussion about it announced on debian-devel-annoucne (which IMHO should be done for any discussion on major changes in Debian's tool chain or central packages). > and have given up on working with me in solving the problem in the > best way for all parties (including you!). Not specifically on working with you as a person but with those who currently drive the way in which debhelper moves. (Until recently I was really glad that the policy strongly recommends the usage of debhelper. In the meanwhile my opinion on this had changed. But you're now on a good way to revert that. :-) I though was — until now — a bit surprised about you seemingly not being open for discussion. So I'm quite glad about your most recent mail (the one I'm replying to now) which shows again the Niels I knew. > I find emails like this super draining on my motivation. I have no > interest in spending my volunteer time working with people that > writing emails phrased such that they make me feel like that person > has given up on me. Yes, and my motivation to help with debhelper in case of something happens (like what happened to lintian) has drained a lot recently, too. If I would have been in Uploaders, I would have removed myself from Uploaders after my previous mail. > I ask that you rephrase your email in a way where I do not feel you have > given up on working with me, Oh, ok, so there's still more room for discussion than your last mail suggested — and despite there are already bug reports against lintian and lintian-brush? So let's start! My suggestions ordered by my personal preference: * Implement what Steve actually asked for and don't overshoot: Apply the rules you've proposed solely for multi-binary packages and leave the handling of single-binary as it is: No warnings, no rejections. A lintian check can be done in addition to that warning, although I see it's main purpose in doing statistics on that. I currently imagine a classification-style lintian check with these variants: * no-debhelper-files * single-binary-no-prefixes * single-binary-prefixes * single-binary-mixed * multi-binary-no-prefixes-at-all * multi-binary-no-prefixes-for-first-package * multi-binary-mixed-for-first-package * multi-binary-prefixes (I hope I have covered all possible variants) In addition we can issue a (single) warning for * multi-binary-no-prefixes-at-all * multi-binary-no-prefixes-for-first-package * multi-binary-mixed-for-first-package * single-binary-mixed * Add a dh option to still allow non-prefixed debhelper files (and scrap that idea of a lintian check for it as it IMHO would be very redundant and unnecessarily complex and error-prone in case it has to parse dh commandline options, too.) * Writing a dh plugin which overrides the restrictions you proposed. (This was actually my plan — as a third party plugin — until your most recent mail on which I'm replying now. Given my work on debhelper so far as well as having written one debhelper plugin, I totally feel capable of writing such a plugin.) > if you want me to engage any further with you. I hope we can agree > on that minimum baseline for future communication. Sure, but then please do the same and discuss such bold debhelper changes first and also not just on debian-devel but at least also on debhelper-devel or even better, in a debhelper bug report instead making such a thing a fait accompli (fsck, I first wrote "fail accompli" here — probably a Freudian typo :-) for those subscribed to debhelper-devel. And please don't overshoot feature requests _and_ then present your proposal as fait accompli either, and encourage discussion instead of sounding as if you want to suppress it. Regards, Axel -- ,''`. | Axel Beckert <a...@debian.org>, https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `- | 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE