your patch https://gerrit.ovirt.org/#/c/40346/ broke oVirt vdsm jobs

[David Caro]

On 05/05, Dan Kenigsberg wrote:
> On Tue, May 05, 2015 at 10:11:09AM +0200, David Caro wrote:
> > On 05/05, Max Kovgan wrote:
> > > hi, Dan.
> > > makes sense to me to focus on 2 use cases:
> > >  - pre-commit hook running everything jenkins is running - locally
> > Maybe pre-push instead, that will leverage a bit the local work
> > >    - pros:
> > >      - nearly identical checks/tests jenkins would running
> > >      - doesn't care about IDE/editor
> > >    - cons:
> > >      - slower
> > >      - can be annoying to commit (locally) broken code for later squashing
> 
> If something is too anoying to be run (such as blocking every patch for
> 3 minute unit tests, when the poor developer only wants to post his
> patch and go home) - developer would find a way to skip it.
> 
> > > 
> > >  - editor/IDE marriage with tests/checks running
> > >    - pros:
> > >      - dev has full control over what runs in checks/tests
> > >      - allows to commit "dirty" commit
> > >      - shorter ==> quicker than the quickest jenkins option
> > >    - cons:
> > >      - depends on IDE/editor support
> > >      - less checks/tests => higher risk
> 
> +1. It boils down to developer and maintainer prudence.
> I have such a plugin in my ViM for static testing; Ido (and everyone
> else) should have one, too. I'm less sure about auto-running `make
> check` at rundom points in time.
> 
> > >
> > > I did both with: intelliJ/PyCharm and vim, almost 100% sure PyDev allows this.
> > > 
> > > either allows ease of running tests - in 1st case upon git commit, in the
> > > latter - via a button/shortcut in the devtool.
> > > I can help with setting up either to an early adopter.
> > > Then give it a week or two to get some feedback later how well it goes.
> > > 
> > > Besides, we're also trying to speedup jenkins response all the time
> 
> I would not mind to BLOCK merging before jenkins hook has responded -
> assuming that I (as a branch maintainer) can remove the jenkins reviewer
> from gerrit. There could be emenrgencies that cannot wait for the
> response. And of course, as a maintainer, I must be able to override the
> decision of the robot (by removing it from the reviewer list).

I'm actually working on adding a new flag 'Continuous Integration' that can
only be set by maintainers and the ci bot, and that requires +1 to merge (where
-1 does not block).

Does that make sense to you? (that way you can't rebase and merge before ci
runs and -1, it's easier to handle permissions, it's easier to spot on the ui,
is clearer it's purpose and does not overload another flag).

> 

-- 
David Caro

Red Hat S.L.
Continuous Integration Engineer - EMEA ENG Virtualization R&D

Tel.: +420 532 294 605
Email: dcaro at redhat.com
Web: www.redhat.com
RHT Global #: 82-62605
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: <http://lists.ovirt.org/pipermail/infra/attachments/20150505/73fdd945/attachment.sig>