Development process and ... WAS: [REGRESSION] What should be italics is rendered as bold text WAS: svn commit: r1456892 - /incubator/bloodhound/trunk/bloodhound_theme/bhtheme/htdocs/bloodhound.css

[Olemis Lang <ol...@gmail.com>]

On 3/22/13, Ryan Ollos <ry...@wandisco.com> wrote:
> On Thu, Mar 21, 2013 at 9:42 PM, Olemis Lang <ol...@gmail.com> wrote:
>
[...]
>
> So basically you have replied to my commit that *did not* introduce the
> problem, stated that there was a problem and that the line in question
> should be reverted "to what it was before"

yes . I meant «without the bold styling in WikiFormatting» ...

> and told me to fix it

very wrong . I never said Ryan . I never said «search is all wrong» .
I said «this is breaking WikiFormatting»
;)

> even
> though you have not yet determined who introduced the change in question or
> when this regression may have been was introduced.
>

yes, I was very busy doing some other stuff and discovered this by accident .

> If you'd like a change to be made, determine who made the change

sometimes time matters :) . Proposed improvement was so tiny that I
did not consider appropriate to waste my time diving too much into the
subject . If you notice to some extent Greg is right . In order to
change a single line of code people has sent a fabulous number of
messages , just to finally fix it and apply a patch .

BTW, I'm not saying that there is no point in discussing some subjects
in the ML .

> in
> question and raise the issue with that person so that you can have a
> productive discussion about the change.

I'd rather suggest another thing if you do not mind .

This is what I did :

  1. Use Firebug to detect css rule
  2. Use local blame tool to find latest changeset modifying that line
      * I was working on bep_0003_multiproduct so result was
        «sync merge from trunk» by jure
  3. Switch back to default (i.e. trunk) branch
  4. Repeat (2)
      * ... found target changeset
  5. Read changeset summary to see what ticket it was for
      * nothing
      * jftr , else add comment in ticket
  6. Search i.a.o/bh looking for changeset ID
      * nothing
      * jftr , else add comment with reference to <somewhere>
  7. time ticking out : quick resolution
      * /me had no idea of why this was added in there and maybe
        someone else knew what all this was about in 5 seconds
  8. is there any chance to comment on lines in source code ?
      * no
  9. is there any chance to comment on a changeset ?
      * yes
  10. search my inbox looking for target changeset ID
  11. send message

So, my point is I did not sent that message to deliberately cause a
flamewar . Notice the considerable amount of time I spent on a single
line to propose a more than obvious change for a more than justified
reason ; and everything  caused by the lack of traces leading to
something explaining why this line was in there . Only 5 seconds
needed to add #whatever in commit messages . That explains why I
*require* adding #whatever in my team .

Now add the time spent in writing this message to kindly request for
tolerating some inaccuracies when reporting this kind of trivial
issues (opposite to more complicated situations)

[...]

= too much wasted time , so I will try not to follow this thread .
Hope you don't mind .

-- 
Regards,

Olemis.

Re: Development process and ...

[Branko Čibej <br...@wandisco.com>]

On 22.03.2013 16:59, Olemis Lang wrote:
> On 3/22/13, Ryan Ollos <ry...@wandisco.com> wrote:
>> On Thu, Mar 21, 2013 at 9:42 PM, Olemis Lang <ol...@gmail.com> wrote:
>>
> [...]
>> So basically you have replied to my commit that *did not* introduce the
>> problem, stated that there was a problem and that the line in question
>> should be reverted "to what it was before"
> yes . I meant «without the bold styling in WikiFormatting» ...
>
>> and told me to fix it
> very wrong . I never said Ryan . I never said «search is all wrong» .
> I said «this is breaking WikiFormatting»

You replied to a mail that had nothing to do with the reported bug. A
conversation on a mailing list is significantly different than face to
face, and correct context is a lot more important. In this case, you
should either have found the actual commit that caused it and replied to
that, or simply reported the bug without referring to any particular
commit; it would have caused less confusion all around.

In any case, the bug is now fixed and the worst thing that can happen is
starting a flame war about what was actually said and how it should be
interpreted. That goes for everyone involved. Let's just move on and, in
future, remember to re-read mails and think about how they can be
interpreted before sending them.

-- Brane

-- 
Branko Čibej
Director of Subversion | WANdisco | www.wandisco.com