[python-committers] PEP 462: Workflow automation for CPython

[Donald Stufft]

For the record, I find the way Openstack does it very awesome, even if
I’m not a huge fan of gerrit itself. It’s also nice that repeated runs make
you file a bug for flaky tests and reference it because you can see which
bugs are causing the most heart ache in the test suite as far as flakiness
goes. This gives you a sort of impact ordered list of things to fix up.

On Jan 26, 2014, at 10:51 AM, R. David Murray <rdmurray at bitdance.com> wrote:

> On Sat, 25 Jan 2014 09:35:46 -0800, Eli Bendersky <eliben at gmail.com> wrote:
>> On Sat, Jan 25, 2014 at 7:13 AM, R. David Murray <rdmurray at bitdance.com>wrote:
>> 
>>> On Sat, 25 Jan 2014 06:59:19 -0800, Eli Bendersky <eliben at gmail.com>
>>> wrote:
>>>> workplace we had a similar process screwed on top of Jenkins - private
>>> test
>>>> runs wherein you provide a branch to CI and the CI tests that branch. In
>>>> fact, when your test may affect many different architectures, such "try
>>>> jobs" are the only way to do unless you really want to build & test a
>>>> branch on a few different OSes.
>>>> 
>>>> Once again, this almost always requires some dedicated developers for
>>>> watching the tree (Chromium has sheriffs, gardeners, etc.), I'm not sure
>>> we
>>>> have that for the CPython source.
>>> 
>>> What do sheriffs and gardeners do?
>>> 
>> 
>> I started replying but then remembered that it's actually all described
>> here - http://www.chromium.org/developers/tree-sheriffs
>> If you're interested in such things (build farms, CI, "process") that page
>> and links from it should provide you with a lot interesting information
> 
> I didn't read past the first part of that, where it said "closes,
> throttles and opens the tree" and "tracks down people responsible
> for breakage".  This is emphatically *not* the Zuul model, from
> what Nick has said.  In Zull, patches don't get *in* to the tree
> unless the buildbots are all green with the patch applied (so, no
> unit-test-discovered "breakage" can occur in the tree).
> 
> Donald answered my question about flaky tests: if a flaky test causes
> the failure, whoever is trying to get it integrated can trigger a new
> run (referencing the bug that documents the flaky test), and if that
> run passes, the patch gets committed.
> 
> This makes much more sense to me than the 'sheriff' approach, which is
> essentially what we have now, albeit with no formally appointed sheriffs,
> and no tree closures.
> 
> --David
> _______________________________________________
> python-committers mailing list
> python-committers at python.org
> https://mail.python.org/mailman/listinfo/python-committers


-----------------
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mail.python.org/pipermail/python-committers/attachments/20140126/79b48e9e/attachment.sig>