--6e7ZaeXHKrTJCxdu Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable There's not much we can do if we don't change the way we work, as you should know, most of the patches are sent during the same days just before the release, that is a huge temporal overload of the system, and even if we can alleviate it a bit (we are working on that too) there's no easy way we can adapt to such a high load increase. Though, in any case, you can (as maintainer) set the CI+1 flag yourself and merge, I agree that we should be able to test everything that goes in the branch before merging. One way to reduce exponentially the workload would be to do the merges to master in batches, that requires a bit of extra work on the developer side,= let me explain (just a random not really though through proposal): * The developer works on a temporary personal branch, there he creates a lo= t of patches, as many as needed, but no CI will automatically run on it * Whenever the deveoper wants to merge he's changes, instead of cherry-pick= ing every related change, creates just a squashed or merge=B9 commit into the destination branch * Then CI will run automatically on that branch as it does now =B9 a squashed commit will not retain the history, the merge commit will allow you to retain the intermediate commits) The big advantage of this approach is that instead of having to rebase tent= hs of patches each time and wait for tenths of jobs to finish, for each person= al branch you only have to wait for one job and you only have to rebase one commit. That, applied to all the patches, will reduce considerably current = and future loads on jenkins, so the jobs will end faster and everyone will be happier :) What do you think? On 10/22, Roy Golan wrote:

As you probably know the CI jobs for ovirt engine takes ages. After it completes, you need to pray that the tree didn't change otherwise gerrit refuse to merge and we over it again. =20 Please disable it for now on *master* as we can't merge quick enough. =20 Stable branches doesn't change that often so its a win. We don't risk them and they anyhow makes less noise. =20 Thanks, Roy

_______________________________________________ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra

--=20 David Caro Red Hat S.L. Continuous Integration Engineer - EMEA ENG Virtualization R&D Tel.: +420 532 294 605 Email: dcaro@redhat.com Web: www.redhat.com RHT Global #: 82-62605 --6e7ZaeXHKrTJCxdu Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJWKeKvAAoJEEBxx+HSYmnDREAH/0NOFEcXzVQKHaHUkNjmb8el P8n/GZbtAPgWneAjLJS+7zGUduDMy710cZ8UPvy9qM7gq/kQ9uQyZVKTuCvKm94g ul/R4zPBmW8VubRpC2lLGzz+qivzRayrinN/C01CfsiflolfpKeT53r3JuM3WWfX L+IHS06c3TNR5Gt856vAUV9y4WtT0pri+A1e7Oyg0uK52rrgciC2BR/wPeYDEpIA K08i+HbFZcwBEiGiR0Pp/ACDQy01FPORBZu0kISOGjCwLVA81i1YhimpVnFUNrNb R8Bzbc/EGQn+TiAMjk0Hm/SL9ndhg8TlmNo7XbmRPF+EDfcCKvWLITOFuu5xvY8= =3M1d -----END PGP SIGNATURE----- --6e7ZaeXHKrTJCxdu--