Hello Julien, On Fri, 1 Sep 2017 17:53:03 +0200 Julien Cristau <jcris...@debian.org> wrote:
> On 09/01/2017 12:57 AM, Alexander Gerasiov wrote: > > Hello Julien, > > > > On Thu, 31 Aug 2017 22:15:04 +0000 > > ow...@bugs.debian.org (Debian Bug Tracking System) wrote: > > > >> This bug was not a request for packaging a new upstream version, so > >> this changelog entry isn't appropriate. > > Could you please explain your point? > > > > There was several bugs in upstream code which leads to incorrect > > behavior on some architectures. > > We have fixed them in current upstream code, and current upstream > > version was uploaded into archive. This really fixes #867376, you > > can see this on > > https://buildd.debian.org/status/package.php?p=uncrustify > What I mean is that when closing bugs in your changelog entry, it > should actually describe what fixes the bug. So "New upstream > release (closes: #nnn)" implies that #nnn was about packaging a new > upstream release. "Fix vanilla flavor to not taste like chocolate > (closes: #mmm)" implies that #mmm is about something being wrong with > the vanilla flavor of ice cream. Ah, totally lost this mail, so reply just now. In generally I agree with you, that changelog should be meaningful. But in this case you're wrong (from my point of view). We have sigfault in the app. User reports "%appname segfault when %something" I look through the code and see pointer dereference, so I create commit not with "Fix sigfault", but with "Do some checks on pointer dereference when ... This should fix #issuenumber". Or may be you mean, that I should write "New upstream release. Fixes disk overflow on some archs. (Closes: #number)" There is some good point in this, I agree, but still no reason to reopen the bug, I think. =) -- Best regards, Alexander Gerasiov Contacts: e-mail: g...@cs.msu.su Homepage: http://gerasiov.net Skype: gerasiov PGP fingerprint: 04B5 9D90 DF7C C2AB CD49 BAEA CA87 E9E8 2AAC 33F1
