On 07/06/2016 09:05 AM, Jamo Luhrsen wrote:
> (adding [releng] topic and integration list)
> 
> tl;dr:
>   lots of troubles and debug cycles happening because of new dev and 
> refactoring that we know
>   can be gated with already existing tests (IT, CSIT)
> 
> Josh,
> 
> I agree 100% with your sentiment and feel your pain.  This is something I 
> have lobbied for, for
> quite some time.  As Anil notes, the biggest push back is that it would 
> require too many resources
> to gate every patch set with our tests.  We did spend some time on the 
> whiteboard at the hackfest
> coming up with a plan.  Andy and Thanh were bringing up a test repo where we 
> can try this out and
> once we work out the quirks, OVSDB can try it first.
> 
> The basic idea is that *no* tests (except normal verify job) will run on a 
> gerrit patch, until
> a new category is given a +1 (I think we want to call it "approve", so we'll 
> have verify, code-review,
> and approve now).  That approve +1 would kick off all the tests (as defined 
> by the projects in their
> job yamls) and if they come back clean, then the patch can be submitted.
> 
> Someone can correct me if I got something wrong.

For those interested in what we were discussing at the hackfest and are
still testing. The modified workflow would end up looking something like
this:

* submit -> verify (Verify flag goes to +1 on success, -1 on fail just
like today)

* committer gives Code-Review +2 and new Approve to +1 ->
  defined csit / test jobs are run -> Failure (Verified -1)
                                   -> Success (Verified goes to +2)

* All values at max (managed exclusively by Jenkins) -> Submit code and
run merge to create artifacts and push them to Nexus

Some changes that folks may see in the above. There's a new column as
Jamo mentioned that committer would have rights over. The value would be
-1 .. +1, and a submitter of code would have -1 .. 0 access so they
could flag a change as not yet ready, without having to use drafts

Secondly, committers would _lose_ the verify rights as they would become
completely managed by Jenkins. The values would change from -1 .. +1 to
become -1 .. +2

Thirdly, committers would _lose_ the submit right. This would be
completely controlled by Jenkins based upon state transitions.
Effectively turning the "Approve +1" right that committers would be
gaining into what would effectively be a "conditionally submit this
code, provided all tests pass" operation.

-Andy-

-- 
Andrew J Grimberg
Systems Administrator
Release Engineering Team Lead
The Linux Foundation

Attachment: signature.asc
Description: OpenPGP digital signature

_______________________________________________
openflowplugin-dev mailing list
[email protected]
https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev

Reply via email to