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
> 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.
And: I did say that I understand that the current scheme can be
causing him problems in managing the source control process.
So, repeating "it's a bug; it should be fixed" doesn't help.
> Neither of Gary's posts have indicated that he is a programmer, or that he can
> spend several hours a night (thank you for your willingness to do that,
> by the way) working on fixing this behavior. Sniping at him like this
> is extremely unprofessional.
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
hiring capacity to develop higly wanted features, if he's not a coder,
why not do the same?
> Better would be to be to point out Issue 898, "implement true renames",
> which (if fixed) would actually change the current behavior to match
> what has been asked for in this thread. Since Issue 898 is classified
> as a "DEFECT" rather than an "ENHANCEMENT" or "FEATURE", it would
> appear
> that the dev. community agrees that this is, in fact, a bug. Also,
> there are (currently) 50 votes for this issue--the second highest issue
> by votes in the Issue Tracker, making it fairly clear that the user
> community also feels fairly strongly that this is a major issue.
That being noted, I must say that I don't know of any developer who
uses votes to direct development attention.
> Of
> course, reading through the comments for 898 make it clear that fixing
> this will be a fairly involved process.
That's exactly the problem. This is *really* hard to get right. You've
come to expect from us to build our software conforming to very high
quality standards. This one takes a lot of effort to do right the
first time, because there are several edge cases in the versioned
backend alone, making only some members of the dev team fit to the
task...
bye,
Erik.
Received on Thu Dec 8 11:29:33 2005