bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Olemis Lang <>
Subject 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
Date Fri, 22 Mar 2013 15:59:04 GMT
On 3/22/13, Ryan Ollos <> wrote:
> On Thu, Mar 21, 2013 at 9:42 PM, Olemis Lang <> 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 .



View raw message