On Wednesday 2013-04-03 17:02 -0400, Justin Lebar wrote:
> > If it's not worth the 2 minutes for an engineer to request approval, it's 
> > likely not worth uplifting the code change. And if approved, the bug is 
> > uplifted automatically by sheriffs.
> 
> It's a bit frustrating to be told that the work I claim is distracting
> is in fact not a drag on my productivity.  I think I'm probably a
> better judge of what is and isn't a drag than anyone else.
> 
> An approval request is not two minutes of work.  It involves a context
> switch back to bug after it's landed.  It usually involves some
> back-and-forth in the bug.  It involves looking up bugs to fill in the
> "regression caused by" field.  It involves keeping track of bugs to
> make sure that the ones you care about get plus'ed.  These small
> context switches have an outsized cost for engineers; see [1].

There's also the cost of the things that don't get uplifted, because
people forget about them, or because people who are less core to the
project (like me) don't know what the current standards are and
worry about making too many requests for the current standards.
That's a cost in bugs that people spend time filing and debugging
that have already been fixed.  There's the cost in testing that the
bug exists on a particular branch in order to figure out whether
approval requests for that branch are needed.  (I think I've seen
people not bother; if a bug was reported on v1-train, then it's
probably not a problem on v1.0.1, so why bother asking for uplift
there?  Another cost of branches.)

The cost of the context switching is also really substantial.  The
rules that approval shouldn't be requested until after review means
that the developer has to load everything back into memory in order
to write the approval request that could have been written quickly
right after the patch was written.

-David

-- 
𝄞   L. David Baron                         http://dbaron.org/   𝄂
𝄢   Mozilla                           http://www.mozilla.org/   𝄂
_______________________________________________
dev-b2g mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-b2g

Reply via email to