Rethinking how we do reviews

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, 2016-04-06 at 13:55 +0530, Arun Raghavan wrote:
> On Tue, 2016-04-05 at 19:28 +0300, Tanu Kaskinen wrote:
> > You didn't directly address my earlier point of reviews saving time. I
> > hesitate to accept your proposal because I believe that reviews save
> > time overall (our time and our users' time), since there are fewer bugs
> > to investigate and fix later. Do you believe differently?
> 
> I thought I did, but to be explicit -- I have a different perspective
> on this. I think we're balancing code quality vs. developer motivation,
> and with the current resources that we have, the negative impact on
> developer motivation is higher than the positive impact on code
> quality.

Ok, the term "code quality" confused me earlier, it looked like
avoiding the question. You seem to equate "code quality win" with "time
saved thanks to catching bugs and other issues early". So you think
that the maintainer time that we lose due to motivation losses is
higher than the maintainer time that we save with reviews. I estimate
that differently.

(I didn't reply to all your points, because it seemed that everything
boils anyway down to our different estimates of the tradeoffs.)

-- 
Tanu


[Index of Archives]     [Linux Audio Users]     [AMD Graphics]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux