On 2013-04-23 12:05 PM, Justin Lebar wrote:
The ratio of things landed on inbound which turn out to busted is really
worrying
On the one hand, we're told not to push to try too much, because that
wastes resources.
On the other hand, we're told not to burn m-i, because that wastes resources.
True!
Should we be surprised when people don't get this right 100% of the time?
No. But that's not what I was talking about. Whether something lands
directly on try is a judgement call, and some people may be better at it
than others. As someone who has stopped using try server as a rule
(because of the excessive wait times there, which I find unacceptable
for day-to-day work), I always ask myself what are the chances that this
thing that I want to push could bounce, and I test on try only when I
can convince myself that the chances are slow. All I was suggesting was
give people a way to assess whether they're good at making these calls,
and improve it if they're not.
Instead of considering how to get people people to strike a better
balance between wasting infra resources and burning inbound, I think
we need to consider what we can do to increase the acceptable margin
of error.
These are not either/or choices.
Note that we don't have enough capacity to turn around current try
requests within a reasonable amount of time. Pushing to inbound is
the only way to get quick feedback on whether your patch works, these
days. As I've said before, I'd love to see releng report on try
turnaround times, so we can hold someone accountable. The data is
there; we just need to process it.
If we can't increase the amount of infra capacity we have, perhaps we
could use it more effectively. We've discussed lots of ways we might
accomplish this on this newsgroup, and I've seen very few of them
tried. Perhaps an important part of the problem is that we're not
able to innovate quickly enough on this front.
We've been asking for more infra capacity for as long as I can remember,
and so far we've always had a shortage in that front (part of which is
due to the continuous increase in development pace, which is a good
thing), so I agree that the way to win this battle is to stop waiting
for that magical day when we have "enough" capacity and stat using it
more efficiently. What I suggested could be a part of that.
People are always going to make mistakes, and the purpose of processes
is to minimize the harm caused by those mistakes, not to embarrass or
cajole people into behaving better in the future. As Jono would say,
it's not the user's fault.
Nobody's blaming the user. We should just empower them to make better
choices.
Cheers,
Ehsan
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
