[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: closing upstream bugs with debian/changelog



Branden Robinson <branden@debian.org> wrote:
> 
> If the Debian changelog is going to be used to close bugs in the Debian
> BTS, it needs to explain why those bugs are being closed.  The above

I understand that you set yourself at a standard above the rest of us
which is all good, but this is not how the majority of Debian developer
operate.

The majority of them are happy with the notion of closing a bug by
sending a message to xxxxxx-done@bugs.debian.org outlying the version
number of the package that it is fixed in.

> quoted snippet of Debian changelog, in which (as it turns out) a lot of
> bugs were closed even though the new upstream release had little to
> nothing to do with those bugs' resolution, is a good example why the
> maintainer/uploader's understanding of why the bug is closed needs to be
> stated, not left to interpretation.

Sure.  I am not defending the changelog entry that started this thread
in any way.  I'm just making sure that those reading the thread get a
balanced view on the subject of including upstream changes in the Debian
changelog.

> Permit me to offer an example:
> 
>  * new upstream release
>    - XFree86 X server now supports ATI Radeon Mobility (Closes: #196810)
>    - XFree86 X server now supports Intel i845G (Closes: #184322)
>    - XFree86 X server now supports Intel i865G (Closes: #221686)
>    - XFree86 X server now supports SiS 650, 651, and 740 (Closes: #183619)
 
> In the above, anyone who cares to read the entry can clearly understand
> the justification for the bug's closure, and the maintainer/uploader
> clearly not simply closing irrelevant bugs with the Debian changelog out
> of laziness.

It is good to see that you're not being lazy.

However, it is my firm belief that all bug submitters should respect
your work by actually verifying for themselves that the bug is indeed
fixed.  After all, you might have made a simple typo/think in writing or
verifying the fix to the bug.  It'd be a pity if it weren't picked up just
because the submitter was complacent.

Besides, you can also provide the explanation by posting them to the
BTS directly.  Granted this is not as convenient as slipping them into
the Debian changelog, but alas we don't put things in the Debian
changelog just because it is convinient.  Otherwise we'd be closing
bugs fixed in past Debian versions (or bugs that aren't bugs at all)
using the Debian changelog.

So I personally find this argument to be very weak in terms of
motivating me in putting explanations next to bug closures caused
by upstream changes.

> "Herbert Xu would never do such a thing" is not a valid defense.  Our
> changelogs need to be accessible to those who are not aware of your
> reputation within the Debian Project.

Good to see the good old Branden Robinson again.  It's rather
disconcerting to not see personal attacks from you in mailing lists.
It makes want to double-check the signature to make sure that
it really is you.
-- 
Debian GNU/Linux 3.0 is out! ( http://www.debian.org/ )
Email:  Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt



Reply to: