Re: [ovirt-devel] Gerrit parallel patch handling and CI (Or, why did my code fail post-merge)

2016-12-01 Thread Barak Korren
On 1 December 2016 at 19:19, Vojtech Szocs wrote: > > Thanks for sharing those links. > > I didn't know you're already working on adopting Zuul, my bad =) It ok, I guess oVirt Jira is not anyone's favorite reading material ;) > So the maintainer can simply express his/her

Re: [ovirt-devel] Gerrit parallel patch handling and CI (Or, why did my code fail post-merge)

2016-12-01 Thread Vojtech Szocs
- Original Message - > From: "Barak Korren" <bkor...@redhat.com> > To: "Vojtech Szocs" <vsz...@redhat.com> > Cc: "devel" <devel@ovirt.org> > Sent: Thursday, December 1, 2016 9:10:19 AM > Subject: Re: [ovirt-devel] Gerrit p

Re: [ovirt-devel] Gerrit parallel patch handling and CI (Or, why did my code fail post-merge)

2016-12-01 Thread Barak Korren
On 1 December 2016 at 10:44, Eyal Edri wrote: ...snip... >> We could make it a two-step operation where you indicate you want to >> submit, wait for the CI output and then click submit - but why not >> just let the system submit for you? ...snip... > Another option is not to

Re: [ovirt-devel] Gerrit parallel patch handling and CI (Or, why did my code fail post-merge)

2016-12-01 Thread Eyal Edri
On Thu, Dec 1, 2016 at 10:10 AM, Barak Korren wrote: > On 30 November 2016 at 19:12, Vojtech Szocs wrote: > > > > So before we adopt auto-submit-after-ci-pass (e.g. using Zuul, as Eyal > > mentioned in that thread), we should be able to manually trigger

Re: [ovirt-devel] Gerrit parallel patch handling and CI (Or, why did my code fail post-merge)

2016-12-01 Thread Barak Korren
On 30 November 2016 at 19:12, Vojtech Szocs wrote: > > So before we adopt auto-submit-after-ci-pass (e.g. using Zuul, as Eyal > mentioned in that thread), we should be able to manually trigger heavy > CI (check-merged) job from Gerrit web interface, is that correct? We could

Re: [ovirt-devel] Gerrit parallel patch handling and CI (Or, why did my code fail post-merge)

2016-11-30 Thread Vojtech Szocs
- Original Message - > From: "Barak Korren" <bkor...@redhat.com> > To: "Vojtech Szocs" <vsz...@redhat.com> > Cc: "devel" <devel@ovirt.org> > Sent: Wednesday, November 30, 2016 9:20:27 AM > Subject: Re: [ovirt-devel] Gerrit p

Re: [ovirt-devel] Gerrit parallel patch handling and CI (Or, why did my code fail post-merge)

2016-11-30 Thread Barak Korren
On 29 November 2016 at 19:34, Vojtech Szocs wrote: > > Question: after the patch is submitted in Gerrit (it's fully acked > and maintainer hits the "Submit" button), does Gerrit allow us to > run CI (e.g. `check-merged` script) *before* doing the actual merge? > > [In other

Re: [ovirt-devel] Gerrit parallel patch handling and CI (Or, why did my code fail post-merge)

2016-11-28 Thread Barak Korren
> > Let us now try the more lenient "rebase if needed", please. Moved. -- Barak Korren bkor...@redhat.com RHCE, RHCi, RHV-DevOps Team https://ifireball.wordpress.com/ ___ Devel mailing list Devel@ovirt.org

Re: [ovirt-devel] Gerrit parallel patch handling and CI (Or, why did my code fail post-merge)

2016-11-28 Thread Dan Kenigsberg
On Mon, Nov 21, 2016 at 03:55:46PM +0200, Barak Korren wrote: > > > > I enjoyed the freedom of cherry-pick, but after 2 broken nightly builds > > in the span of 10 days, I give up. Let's try ff-only. > > > All right, changed. Thanks. But it ruined my work experience. Manual rebase for every

Re: [ovirt-devel] Gerrit parallel patch handling and CI (Or, why did my code fail post-merge)

2016-11-21 Thread Barak Korren
> > I enjoyed the freedom of cherry-pick, but after 2 broken nightly builds > in the span of 10 days, I give up. Let's try ff-only. > All right, changed. -- Barak Korren bkor...@redhat.com RHEV-CI Team ___ Devel mailing list Devel@ovirt.org

Re: [ovirt-devel] Gerrit parallel patch handling and CI (Or, why did my code fail post-merge)

2016-11-20 Thread Dan Kenigsberg
On Sun, Nov 20, 2016 at 06:09:59PM +0200, Nir Soffer wrote: > On Sun, Nov 20, 2016 at 5:12 PM, Barak Korren wrote: > >> With the current setting (in vdsm), submitting a series of patches is > >> a huge pain. Sometimes refreshing the page and submitting the next > >> patch in

Re: [ovirt-devel] Gerrit parallel patch handling and CI (Or, why did my code fail post-merge)

2016-11-20 Thread Martin Perina
On Sun, Nov 20, 2016 at 9:18 PM, Sandro Bonazzola wrote: > Il 20/Nov/2016 15:08, "Barak Korren" ha scritto: > > > > Hi there, > > > > I would like to address a concernt that had been raised to us by > > multiple developers, and reach an agreement on how

Re: [ovirt-devel] Gerrit parallel patch handling and CI (Or, why did my code fail post-merge)

2016-11-20 Thread Sandro Bonazzola
Il 20/Nov/2016 15:08, "Barak Korren" ha scritto: > > Hi there, > > I would like to address a concernt that had been raised to us by > multiple developers, and reach an agreement on how (and if) to remedy > it. > > Lets assume the following situation: > We have a Git repo in

Re: [ovirt-devel] Gerrit parallel patch handling and CI (Or, why did my code fail post-merge)

2016-11-20 Thread Nir Soffer
On Sun, Nov 20, 2016 at 5:12 PM, Barak Korren wrote: >> With the current setting (in vdsm), submitting a series of patches is >> a huge pain. Sometimes refreshing the page and submitting the next >> patch in the series works, but sometimes you have to rebase again >> the next

Re: [ovirt-devel] Gerrit parallel patch handling and CI (Or, why did my code fail post-merge)

2016-11-20 Thread Barak Korren
> With the current setting (in vdsm), submitting a series of patches is > a huge pain. Sometimes refreshing the page and submitting the next > patch in the series works, but sometimes you have to rebase again > the next patches in the series, and in the worst cases, you have to > do several

Re: [ovirt-devel] Gerrit parallel patch handling and CI (Or, why did my code fail post-merge)

2016-11-20 Thread Nir Soffer
On Sun, Nov 20, 2016 at 4:07 PM, Barak Korren wrote: > Hi there, > > I would like to address a concernt that had been raised to us by > multiple developers, and reach an agreement on how (and if) to remedy > it. > > Lets assume the following situation: > We have a Git repo in