Re: Bug#910446: NMU diff (substantive patches in git-format-patch form)
- Date: Mon, 15 Oct 2018 09:35:52 +0200
- From: Guido Günther <agx@xxxxxxxxxxx>
- Subject: Re: Bug#910446: NMU diff (substantive patches in git-format-patch form)
On Sun, Oct 14, 2018 at 10:55:10PM +0100, Ian Jackson wrote:
> Guido Günther writes ("Re: Bug#910446: NMU diff (substantive patches in git-format-patch form)"):
> > On Sun, Oct 14, 2018 at 03:36:49PM +0100, Ian Jackson wrote:
> > > Hi. I fixed this bug, and some other FTBFS, and am about to upload
> > > the result. I'm doing this myself, right away, because this is an RC
> > > bug which has triggered the autoremover to want to remove dgit.
> > >
> > > Following the recommendation in dev ref 5.11.1, I have not use
> > > DELAYED; and because I doubt that actually uploading it now will cause
> > > you any difficulty. I hope that's OK.
> > >
> > > The patches I made are attached. You can also find this as a git
> > > branch, here:
> > That's actually not what I prefer since I
> Sorry about that. But,
> I did look in the bug  before starting work, this lunchtime UK
> time, and there was no response there.
>  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=910446
> I have just checked the bug again, and your message to it crossed with
> my decision to go ahead with the upload. The timestamp on the
> relevant .changes file shows that I did my formal build-for-upload at
> 14:28 UTC. I and evidently spent a few minutes getting my NMU diff
> email into shape and I sent that email at 14:36 and did the actual
> dgit push at 14:37.
> Your message to the bug was at 14:31 UTC. I confess didn't check the
> bug again in the 9 minutes between `dgit sbuild' and `dgit push'.
> To be honest, if you had said any time in the past week, in the bug,
> that you were intending to fix it I would have been quite happy to
> leave the work to you. But there was nothing from you in the bug and
> the upstream git server (which I was able to see via http, even if the
> git interface was giving me trouble) showed no recent activiy.
To be honest I saw that bug but forgot about it until I saw the
autoremoval mail. I then notified the BTS so reverse dependencies don't
need to worry.
> > - there's plenty of time until the autoremoval hits us
> I'm generally quite busy and I had time and headspace to do this
> technical work now. I wasn't confident that that would occur again in
> the next few weeks.
> I'm sorry to be told that I have engaged in "sub par interaction". I
> was trying to help. Can you explain to me what concrete problem my
> action has caused you ?
It's not that much trouble for me but rather sad that people spent time
on (in this case) just tedious work while they could fix other stuff
in the same time since the maintainer is already on it.
> I appreciate that being the recipient, several times a year, of
> autoremoval notifications (not just from gbp) is a hazard of sitting
> on top of a large dependency stack. But it would be nice to be able
> to at least fix these things oneself without being criticised.
> It would be really helpful if people would respond to RC bugs *before*
> their entire reverse dependency stack has received an `autoremoval'
Yept, that's totally true but I think the reverse holds as well: if
things are flagged check with the maintainer(s) how this happened
(in this case it was just an oversight). They might either be working on
a fix or might be happy about an NMU.
> I guess I can be criticised for not emailing the bug before starting
> work. Looking at my irc transcript it looks like I started at 12:00
> UTC or so. Of course once one has started on something like this it
> is very discouraging to be told to stop and throw one's work away -
> and I guess your message to the bug was prompted by the autoremoval
> mail which had been sent ovrnight, so an additional mail from me would
> have waited anyway. So probably in this case if I had emailed the bug
> at 12:00ish UTC it would have made no difference.
That's why I at least check with maintainers before starting work on
things. Even then it doesn't always help to avoid duplicated work (since
some times there's more than two parties involved) but most of the time
I should have used better words in my previous mail. Sorry if this came
over rougher than it meat to be.