On 19/08/2014 21:55, Benoit Girard wrote:
I completely agree with Jeff Gilbert on this one.
I think we should try to coalesce -better-. I just checked the current
state of mozilla-inbound and it doesn't feel any of the current patch
really need their own set of tests because they're are not time
sensitive or sufficiently complex. Right now developers are asked to
create bugs for their own change with their own patch. This leads to a
lot of little patches being landed by individual developers which
seems to reflect the current state of mozilla-inbound.
Perhaps we should instead promote checkin-needed (or a similar simple)
to coalesce simple changes together. Opting into this means that your
patch may take significantly longer to get merged if it's landed with
another bad patch and should only be used when that's acceptable.
Right now developers with commit access are not encouraged to make use
of checkin-needed AFAIK. If we started recommending against individual
landings for simple changes, and improved the process, we could
probably significantly cut the number of tests jobs by cutting the
number of pushes.
I agree we should try to coalesce better - however doing this via a
manual "let's get someone to push a bunch of checkin-needed patches in
one go" is suboptimal:
1) By tweaking coalescing in buildbot & pushing patches individually, we
could get the same build+test job per commit ratio as doing
checkin-neededs, but with the bonus of being able to backfill jobs where
needed. This isn't possible when say 10-20 checkin-neededs are landed in
one push, since our tooling can only trigger (and more importantly
display the results of) jobs on a per push level.
2) Tooling can help make these decisions much more effectively and
quickly than someone picking through bugs - ie we should expand the
current "only schedule job X if directory Y changed" buildbotcustom
logic further.
3) Adding a human in the workflow increases r+-to-committed cycle times,
uses up scarce sheriff time, and also means the person who wrote the
patch is not the one landing it, and so someone unfamiliar with the code
often ends up being the one to resolve conflicts. We should be using
tooling, not human cycles to lands patches in a repo (ie the
long-promised autoland).
Best wishes,
Ed
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
