mdadm 2.4.1-1 ready for tests

[martin f krafft]

also sprach Henrique de Moraes Holschuh <hmh at debian.org> [2006.05.17.2210 -0500]:
> mdadm is a *critical* part of a system that uses linux software
> raid. Anything that helps users understand all the important
> changes an update will imply is always uselful. 

Of course, but if there weren't any important changes, doesn't it
suffice that a bug is just fixed? As in: previously mdadm did that
wrongly, and that's fixed. Why should a user care how it was fixed?

Also, what you are saying leads me to believe that you would want me
to document *all* important changes, whether respective Debian bugs
existed or not. NEWS.Debian is clearly a better method for such
announcements, but you *should* try to keep the stuff there down to
a minimum, IMHO.

In any case, I *will* go through the fixed-upstream bugs again to
make sure that the fixes do not have implications for users who
weren't affected by the bug.

> Anything that helps a developer easily track down what *exacly*
> caused a bug to be closed can be very useful, too.

I would expect a developer to know to turn to the upstream changelog
for such information. Apart, the Debian changelog would be
hopelessly long if I had to specify "what *exactly* caused a bug to
be closed."

> but adding the main points there is *very* appreciated by many of
> us.

This argument stands. I'll consider it.



also sprach Stefano Zacchiroli <zack at debian.org> [2006.05.17.2217 -0500]:
> I see debian work as tailoring upstream one so that it best fits
> our users. Selecting the appropriate information from the upstream
> changelog that describe how bugs reported in our BTS got closed is
> part of such tailoring.

Yes, but see above. A bug that existed previously which is now fixed
is in and of itself appropriate information: the problem now does
not exist anymore.

> Beside that and more practical: why documenting "closes:" in
> debian/changelog if the users have no way to understand them? If
> it is only for automatically closing bugs with the upload there is
> something wrong with the usage of the instrument.

Is there? I am telling the user that his/her bugs were closed by
upstream, or have been "obsoleted" by the new release.

So as you can see, I disagree. However, I do understand that mdadm
is kind of critical, so I will reconsider and might change the
changelog when I upload to unstable.

-- 
Please do not send copies of list mail to me; I read the list!
 
 .''`.     martin f. krafft <madduck at debian.org>
: :'  :    proud Debian developer and author: http://debiansystem.info
`. `'`
  `-  Debian - when you have better things to do than fixing a system
 
http://kirch.net/unix-nt/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature (GPG/PGP)
Url : http://lists.alioth.debian.org/pipermail/pkg-mdadm-devel/attachments/20060518/8f8505d5/attachment.pgp