On Mon, 16 Apr 2007, Heikki Toivonen wrote:
perceived regression happened because a new feature was added then the
regression is also bogus. If the perceived regression is because a bug
was fixed then the regression is still bogus.
I disagree. It is certainly possible to make a performance regression
bug as part of adding a new feature or fixing another bug. You just
can't know it without checking. Hence, I have filed perf regression bugs
as reminders that these should be checked.
My point was that you (or whoever files the bug) should do the checking.
Talking to the developer instead of filing a bug is a welcome move.
If you are asking me to understand each checkin well enough to know if a
change was due to a bug, I think you are asking too much. For example,
if you check in a fix to some repository bug and I notice performance
got slower, there is basically no way I would be able to tell if you
made a mistake or not. Of course if somebody, including me, changes
code I do know, I will be able to do an effective code review looking
for performance problems.
Yes, there is a way. Ask me about the change before filing the bug.
Bugzilla is not a substitute for human interaction on a small project like
ours.
Generally speaking I would be looking at days or weeks or even more per
checkin for me to ramp up my understanding of the code that changed to
be able to say with any certainty if the checkin was buggy or not. I
just don't think that would be a good use of my time, considering the
person who checked in would be done in a few hours at most.
Agreed. Hence my point about talking to the developer first.
If you do think we need someone other than the person who made the
checkin to understand all the code before filing perf regression bugs,
then I think we need someone more knowledgeable than me to review all
the checkins. Peer reviews? Chandler benevolent dictator?
Peer reviews can be very useful, especially during a period like the one now.
During a "new feature" phase they are mostly useless, especially when applied
to performance.
Andi..
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "chandler-dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/chandler-dev
