It doesn't feel like a quick |hg qimport bz://123456; hg qref -m "<my
favourite try syntax>"; hg try| would really put a dent in a mentors
productivity. If someone has already put in the effort to update the bug
with try syntax why not just do 1 more step and push to try?
David
On 20/05/2014 19:33, Bobby Holley wrote:
Can we get a stopgap solution in the mean time?
How about this: If a sheriff comes across a checkin-needed bug without
a try push, _and_ the most-recent comment in the bug includes a
try-chooser string that the path author would have used if {s,}he had
try access, the sheriff can push to try on the author's behalf?
On Tue, May 20, 2014 at 2:01 AM, Ed Morley <emor...@mozilla.com
<mailto:emor...@mozilla.com>> wrote:
Autoland should solve that use case :-)
https://bugzilla.mozilla.org/show_bug.cgi?id=657828
On 19 May 2014 22:01:25, Jonas Sicking wrote:
Try-from-bugzilla would be awesome!
/ Jonas
On Mon, May 19, 2014 at 1:53 PM, Bobby Holley
<bobbyhol...@gmail.com <mailto:bobbyhol...@gmail.com>> wrote:
(Reducing the thread scope for the followup)
One issue I often run into is that the contributor doesn't
have access to
try, and pushing it on their behalf disrupts the rhythm of
the other things
I'm doing. If we go forward with this, can we also get
some kind of
sheriff-assisted try push flag? Something like try-needed?
On Fri, May 16, 2014 at 1:54 PM, Ryan VanderMeulen <
rvandermeu...@mozilla.com
<mailto:rvandermeu...@mozilla.com>> wrote:
As many of you are aware, the sheriff team has been
assisting with landing
checkin-needed bugs for some time now. However, we've
also had to deal with
the fallout of a higher than average bustage frequency
from them. As much
as we enjoy shooting ourselves in the foot, our team
has decided that we
needed to tweak our process a bit to avoid tree
closures and wasted time
and energy.
Therefore, our team has decided that we will now
require that a link to a
recent Try run be provided when requesting checkin
before we will land the
patch. To be clear, this *ONLY* affects checkin-needed
bugs where we're
assisting with the landing. We have no desire to
police what other
developers do before pushing. As has always been the
case, developers are
expected to ensure that their patches have received
adequate testing prior
to pushing whether they are receiving our assistance
or not.
Our team is also not going to dictate which specific
builds/tests are
required. We're not experts in your code and we'll
defer to your judgment
as to what counts as sufficient testing. As mentioned
earlier today in
another post, if in doubt, we do have a set of general
best practices for
Try that can be used as a guide [1]. We just want to
ensure that patches
have at least received some baseline level of testing
before being pushed
to production. We've been testing the water with this
policy for the past
couple weeks and have already seen a reduction in the
number of backouts
needed.
For those of you mentoring bugs for new contributors,
please also keep
this in mind in order to keep patches from being held
up in landing. And
consider vouching for Level 1 commit access to further
empower those
contributors!
Thanks!
-Ryan
[1]
https://wiki.mozilla.org/Sheriffing/How:To:Recommended_Try_Practices
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
<mailto:dev-platform@lists.mozilla.org>
https://lists.mozilla.org/listinfo/dev-platform
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
<mailto:dev-platform@lists.mozilla.org>
https://lists.mozilla.org/listinfo/dev-platform
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
<mailto:dev-platform@lists.mozilla.org>
https://lists.mozilla.org/listinfo/dev-platform
_______________________________________________
Sheriffs mailing list
sheri...@mozilla.org
https://mail.mozilla.org/listinfo/sheriffs
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
