> > In the same exaggerated view, Jesse's premises: > - Actual user/developer testing is more valuable than review and refactoring > - Colorary: merging code with bugs is acceptable, we want the bug reports > - Endless code churn due to review/refactoring may actually introduce > bugs not present in the first version > > Please tell me if I'm wrong. > > From my point of view, this is all about tradeoffs and you two stand > on different positions in these tradeoffs. Example: > - Time time you save by not doing all the refactoring/bikeshedding can > be spent doing bug fixing or reviewing/testing someone else's patches. > - But the question is: which one is more worth it? An hour > refactoring/rebasing so the code behaves exactly like $reviewer wants, > or an hour staring at bugzilla or reviewing/testing patches? > - From my point of view, it seems Daniel assumes people will always > spend 0 time fixing bugs, that's why he requests people so much > refactoring: the tradeoff slider is completely at one side. But that's > kind of a vicious/virtuous cycle: the more he increases his "quality > standards", the more we'll spend time on the refactorings, so we'll > spend even less time on bugzilla", so Daniel will increase the > standards even more due to even less time spent on bugzilla, and so > on. Here is the thing, before Daniel started making people write tests and bikeshedding, people spent 0 time on bugs, I can dig up countless times now I've had RHEL regressions that I've had to stop merging code to get anyone to look at. So Jesse likes to think that people will have more time to look at bugzilla if they aren't refactoring patches, but generally I find people will just get moved onto the next task the second the code is merged by Daniel, and will fight against taking any responsibility for code that is already merged unless hit with a big stick. This is just ingrained in how people work, doing new shiny stuff is always more fun than spending 4 days or weeks to send a one liner patch, so really if people thinking we just need to merge most stuff faster is the solution they are delusional, and I'll gladly stop pulling until they stop. I've spent 2-3 weeks on single bugs in the graphics stack before and I'm sure I will again, but the incentive to go hunting for them generally comes from someone important reporting the bug, not from a misc bug report in bugzilla from someone who isn't a monetary concern. So Jesse if you really believe the team will focus on bugs 2-3 months after the code is merged and drop their priority for merging whatever cool feature they are on now, then maybe I'd agree, but so far history has shown this never happens. Dave. _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
