It's an extra interruption that's going to me make me marginally more
averse to mentoring bugs (in general, I would suggest that the mentee build
the try syntax using the syntax builder).
On Tue, May 20, 2014 at 12:46 PM, David Burns <dbu...@mozilla.com> wrote:
> 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> 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>
>>> 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> 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
>>>>> https://lists.mozilla.org/listinfo/dev-platform
>>>>>
>>>>> _______________________________________________
>>>> dev-platform mailing list
>>>> dev-platform@lists.mozilla.org
>>>> https://lists.mozilla.org/listinfo/dev-platform
>>>>
>>> _______________________________________________
>>> dev-platform mailing list
>>> dev-platform@lists.mozilla.org
>>> https://lists.mozilla.org/listinfo/dev-platform
>>>
>>
>
>
> _______________________________________________
> Sheriffs mailing
> listSheriffs@mozilla.orghttps://mail.mozilla.org/listinfo/sheriffs
>
>
>
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
