undefined | Better HN

0 pointspja14y ago0 comments

Thanks. Presumably if we're talking about 1 CL / month this is more like a feature checkin to the release branch, rather than individual working commits given the context?

(1 local WIP commit per month really would be slacking off!)

0 comments

3 comments · 1 top-level

jrockway14y ago· 2 in thread

CLs become one perforce commit, but their lifetime is more like a git branch. I try to keep CLs under 100 delta lines. (In contrast, I try to keep git commits around 10 delta lines.)

People that only write one CL a month have probably written a fairly large amount of code, but are being blocked on reviews. When I see a review for more than 100 lines of code, I immediately think, "I'll do this later" or "Oh good, I'm only CC'd on this review; ignore." If the person doesn't have anything else to work on, this blocks him until I feel like diving into 1000 lines of code I've never seen before. Conversely, if I got one 30 line CL every day for a month, I would probably immediately review each, turning the one-CL-a-month guy into a 30-CLs-a-month guy with the same amount of code.

pjaOP14y ago

Thanks for the clarification.

(Also, you just made CLs sound like yet another metric that can be gamed by the appropriately cynical employee. Ouch.)

rictic14y ago

I haven't heard anyone besides mchurch cite number of CLs as a productivity measure. Lines of code sometimes, but not CLs. Sometimes it's just not worth it to break a large, cross-cutting change up into small chunks.

That said I do vastly prefer smaller CLs because the review process goes so much better.

j / k navigate · click thread line to collapse