On Dec 8, 2005, at 6:26 PM, 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
>> 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.
I totally agree with Erik. Bug is bug and it should be fixed
immediately. Why must there a vote system to vote for fixing a bug?
We can vote for new features and that's correct use of voting. But
not for bugs. I think (personally) that the dev community has
completely wrong idea (perhaps) using the vote system.
Just my 2 cents.
--
"If you missed the rising sun and the morning dew, don't miss the
beautiful sunset." -- Adrian Hoe inspired by Michal Nowak, June 15 2004
http://adrianhoe.com
Received on Fri Dec 9 10:03:00 2005