Bug#330824: I dont believe this bug was acted on properly

Sat Nov 5 17:12:25 UTC 2005

Back-handed passive-agressive statements are not productive, but instead
provoke angry responses, but lets not get angry. I believe that we can
discuss this in a rational way, discussing the technical details, rather
than resorting to flaming.  Please believe me when I say that I
re-opened this bug not to spite you or to flame you, but because it
seemed as if it wasn't actually fixed. I'm sorry if my message came
across in any other way, it was not intended to be so.

> I guess you believe this is release-critical.  I require a bit of
> convincing on that score.  I almost tagged this one wontfix just now,
> but I'll give you a chance to rebut first.

If you will allow me to rephrase this in a different way, "Why did you
not change the severity of the bug when you reopened it? Do you think
that it is still release-critical?"

Actually the reason why I did not change the severity of the bug was
because I did not even look at it from the beginning, I assumed the
original bug was set to a severity level that made sense, and because I
felt as if the bug had not been acted on that the original severity
level probably still applied. Had I noticed that it was set to such a
high severity level, then I probably would have noted that in my
response, suggesting that it probably should be lowered. However, I am
not a huge fan of changing the severity of someone else's bug, on
someone else's package, I prefer to instead suggest that it be changed,
rather than barge in and do it myself.

My guess is that the release-critical nature of the original severity of
the bug was due to the FHS violation, which was actually fixed. So I
agree that the severity should be lowered, and I apologize for
overlooking this.

>>This did not happen with any of the example files with 1.2.3dfsg1-1,
>>they all still appear in /usr/share/subversion/hook-scripts.
> 
> 
> Many of the files there are usable in situ.  Moved to the examples
> directory, they wouldn't be (thanks to Policy about gzip).  I'm not
> interested in breaking people's repositories arbitrarily, which is what
> would happen if people *are* using these things in situ.  If I break
> someone's repository with a svn upgrade I want to at least have a good
> reason.

This makes a lot of sense. I was not aware that the example files are
actually usable in situ. I only saw that the bug was closed and the
example files were not moved as the bug suggested. This was an
indication to me that the bug report had not been acted on properly. If
you had sent a message to the report clarifying this, it would have
helped and I would not have thought that the issue had been overlooked.

>>It seems to me that the hot-backup.py script should be restored to
>>its original useful place (as a script that some backup programs
>>use)
> 
> 
> Did you read NEWS.Debian.gz?
> 
>   The other script affected is /usr/lib/subversion/hot-backup.py, which
>   has now moved into /usr/share/doc/subversion/examples.  It was never
>   a supported executable (or it would live in /usr/bin).  It is also no
>   longer needed, because "svnadmin hotcopy" now includes the same
>   functionality.  Please use "svnadmin hotcopy" instead.

Somehow I missed this, my apologies.

Seems odd to include this at all if it is unsupported. Additionally, the
examples/ directory seems like a strange place to put scripts, but
nevertheless, thats up to you.

Knowing this and the details about the .example files convinces me that
this bug actually should be closed. I'm sorry to have bothered you.

Micah
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFDbOf59n4qXRzy1ioRAsekAJ9RoalwcpuLhoX6PxRtlY6aejMe3wCfd1vz
yHZmEUV+0bU/62mxkRE9Jiw=
=Ct2k
-----END PGP SIGNATURE-----