5:32 p.m.
This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--dwEQhFbDne1LuxvT2FdGb3GL2Q2diT44q
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Wed 21 May 2014 04:28:10 PM CEST, Itamar Heim wrote:
On 05/21/2014 05:25 PM, Eyal Edri wrote:
>
>
> ----- Original Message -----
>> From: "Itamar Heim" <iheim(a)redhat.com>
>> To: "Sandro Bonazzola" <sbonazzo(a)redhat.com>, "David
Caro"
>> <dcaroest(a)redhat.com>
>> Cc: "infra" <infra(a)ovirt.org>
>> Sent: Friday, May 16, 2014 9:48:19 PM
>> Subject: Re: About merging patches without tests
>>
>> On 05/16/2014 05:38 AM, Sandro Bonazzola wrote:
>>> Il 16/05/2014 10:37, David Caro ha scritto:
>>>> On Fri 16 May 2014 09:33:44 AM CEST, Sandro Bonazzola wrote:
>>>>> Il 15/05/2014 18:46, David Caro ha scritto:
>>>>>> Hi!
>>>>>>
>>>>>> From time to time we have some patches that are merged to
maste=
r
>>>>>> branches
>>>>>> without having been tested mostly because the developer merges
be=
fore
>>>>>> having any
>>>>>> response from the jenkins system.
>>>>>>
>>>>>> Merging one of those patches makes any following test run on
that=
branch
>>>>>> to
>>>>>> fail, and creating a lot of noise and trouble around all patches
=
and
>>>>>> jobs.
>>>>>>
>>>>>> So I wanted to stat a little discussion to bring up ideas on how
=
to
>>>>>> prevent
>>>>>> that. Some random thoughts:
>>>>>>
>>>>>> * -1 the patch at jenkins job start, and reset to 0 on success
or=
infra
>>>>>> failure,
>>>>>> and keep -1 if jenkins failure
>>>>>> * Only send a message to the patch with 'jenkins jobs
started'
>>>>>
>>>>> I think that something like "jenkins jobs started, please
don't me=
rge
>>>>> until they finish" should be enough.
>>>>>
>>>>>> * Setup zuul as gateway, and make it block the patches if they
do=
not
>>>>>> pass the tests
>>>>>>
>>>>>>
>>>>>>
>>>>>> Cheers!
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Infra mailing list
>>>>>> Infra(a)ovirt.org
>>>>>> http://lists.ovirt.org/mailman/listinfo/infra
>>>>>>
>>>>>
>>>>>
>>>>
>>>> Usually the flow is reabase -> submit, that is done pretty easily f=
rom
>>>> the ui, and it does not give too much time to check
any comments (t=
he
>>>> rebase and submit buttons are on the top, and the
comments show at =
the
>>>> end).
>>>> So doing that will not help on that case, as the developer would no=
t
>>>> see the comment before submitting. I think we should
block, at leas=
t
>>>> for a couple minutes, so he has to read the comments
to be able to
>>>> submit.
>>>>
>>>> We had that before also, adding a comment when the jobs start, but =
we
>>>> removed it by developers request iirc
>>>
>>> Also recently you can just press submit and it automatically rebase =
before
>>> merging.
>>> So maybe yes, just a message isn't enough
>>
>> its not possible to wait for the job on a simple rebase usually - too=
>> many collisions possible.
>
> we're mostly talking about jobs that fail to compile, i think in those=
cases,
> it worth to wait for jenkins job to finish.
if the previous patch failed to compile - i agree.
if a rebase of a patch that passed previously, waiting for another roun=
d of
jobs isn't practical if other merge in the meantime. I'd
say:
- wait for it if last patch is several days old.
- make sure to check the email from automation post the merge and rever=
t/fix
if it broke in a short loop.
Maybe we can retake the initiative of testing 'on demand', meaning,=20
that the high load jobs only run after a maintainer +1 and a verified=20
+1, that added to the extra flag might help ease the load and keep=20
master stable:
Devel sends patches/rebase/whatever, verifies +1, then a maintainer=20
reviews +1 -> jenkins job starts and adds the 'tested' flag when=20
finished -> maintainer can submit
But e will need some control over the maintainers of each project (we=20
have more or less that already as gerrit groups and permissions).
--
David Caro
Red Hat S.L.
Continuous Integration Engineer - EMEA ENG Virtualization R&D
Email: dcaro(a)redhat.com
Web: www.redhat.com
RHT Global #: 82-62605
--dwEQhFbDne1LuxvT2FdGb3GL2Q2diT44q
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAEBAgAGBQJTfMclAAoJEEBxx+HSYmnDS04H/RA+Y+oM9pvZYa+KzUHDLv+E
ZAZfHzrb4R1XWFI77FQS13vCBN1AHJ+msJhffgXnfRIJSfD/DxOtQ688We5aeSWD
GFKr9sc+weqH5WovflDeECeX+o1wYTeiMJbFm9tyAjmfqjU917Pvh26D63+g8gcs
JX1Ksvs92ExXpk+Kz9NzUJqrOtFIsfUMEamdlDW2cL8wi0d9vYcoch96bspvvmdz
0qwVDnB8zTl/GcjDkGV2a/SLlFL8WktvY1GTXhfvwsyTcB9sGSZkEF4JrufZsNcr
LdtpO4yiKUKmFAF0Nx4UgNv2ildSg7vTRftRatWLQe/UgIC2FYITN1lFcTxz2eE=
=K7ee
-----END PGP SIGNATURE-----
--dwEQhFbDne1LuxvT2FdGb3GL2Q2diT44q--