Erik Huelsmann wrote:
> On 12/7/05, Gale, David <David.Gale@hypertherm.com> wrote:
>
>>Erik Huelsmann wrote:
>>
>>>On 12/7/05, Gary Feldman <svnul4228@marsdome.com> wrote:
>>>
>>>>Erik Huelsmann wrote:
>>>>...
>>>>
>>>>>I didn't say you have no problems. We just tell you that it's
>>>>>intended behaviour atm (and thus not a bug, which is non-intended
>>>>>or plain incorrect behaviour).
>>>>
>>>>First, reporting that a file was added when in fact it was the
>>>>result of a rename is plain incorrect behavior. The log entries
>>>>should accurately report what operations took place.
>>>>
>>>>But let me put on my QA hat for a moment, and say that this is a
>>>>poor definition of a bug (old IEEE taxonomies not withstanding). A
>>>>coding bug is when the code doesn't do what the programmer intended.
>>>>This is a requirements bug, but it's a bug nevertheless.
>>>
>>>THEN FIX IT!
>>
>>Erik, I must say that this isn't a good response. Gary has posted twice
First, I want to thank David for jumping in here. I am, in fact, a software
engineer, but my expertise is in software quality, processes and tools - in
other words, I help teams apply tools such as Subversion to improving both their
productivity and quality, sometimes with coding, sometimes with coaching.
As David speculated, and my inability to respond promptly shows, I barely have
the time to keep up with this mailing list, let alone fix bugs in unfamiliar
code - especially when I'm sufficiently familiar with Subversion to know that
it's been discussed before, and for whatever reason, is non-trivial.
>>in this thread, both times complaining that the attitude of "this is the
>>way things work right now, so it's not a bug" is annoying &
>>unbeneficial--a sentiment which I happen to agree with.
>
>
> I'm sorry for my childish reaction, but it's exactly the harping on
> "it's a bug" which triggered it. I already admitted that it's not an
> ideal situation. Also, the team has already acknowledged that this is
> not the final state of things. Past discussions on the dev@ list and
> issues recording those discussions are artefacts of it.
I understand how frustrating it can be to see the same issue raised so often,
knowing that it's not a one line fix, and feel like everyone is picking on your
or the other folks on the Subversion team for not getting it fixed yesterday.
But that wasn't my intent. I was triggering specifically on the issue of how to
classify this problem. Perhaps I've been exposed to the "That's not a bug, it's
a feature" mentality for too many years. But as I said, quality is one of my
hats, and I know enough about the people side of software to know how important
it is to avoid the double standard of issue classification, even when it's just
in casual conversation.
So let me say that I have enough respect for the Subversion team to know that
they're all aware of the issues around move/rename, and they have been for at
least as long as I've been using Subversion, coming up on two years. And I know
they want to see this fixed, but it's a harder problem than it seems. But at
the same time, I'll continue to correct people who appear to be treating coding
bugs as a special case, more embarrassing than other bugs.
...
> In OSS, people scratch their own itches, if this is his itch, he
> should see to it that it gets scratched. Not by reiterating "it should
> be fixed" but by taking apropriate action. Others have talked about
Apart from the fact that I never said that, there's a huge variety in the way
open source software development takes place. If it really were the case that
people always scratch their own itches, then either Mozilla would have passed
Outlook, Lotus Notes, and all of Google by now, or else 90% of the contributors
to the Mozillazine bug forums would have to be told to go away since they're
just reporting bugs without fixing them. Software engineering is a team effort,
but there are many different ways to contribute besides coding.
Gary
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Dec 13 00:33:32 2005