[Gluster-Maintainers] Requesting separate labels in Gerrit for better testing results

[Niels de Vos]

On Thu, Jan 14, 2016 at 11:51:15AM +0530, Raghavendra Talur wrote:
> On Tue, Jan 12, 2016 at 7:59 PM, Atin Mukherjee <atin.mukherjee83 at gmail.com>
> wrote:
> 
> > -Atin
> > Sent from one plus one
> > On Jan 12, 2016 7:41 PM, "Niels de Vos" <ndevos at redhat.com> wrote:
> > >
> > > On Tue, Jan 12, 2016 at 07:21:37PM +0530, Raghavendra Talur wrote:
> > > > We have now changed the gerrit-jenkins workflow as follows:
> > > >
> > > > 1. Developer works on a new feature/bug fix and tests it locally(run
> > > > run-tests.sh completely).
> > > > 2. Developer sends the patch to gerrit using rfc.sh.
> > > >
> > > > +++Note that no regression runs have started automatically for this
> > patch
> > > > at this point.+++
> > > >
> > > > 3. Developer marks the patch as +1 verified on gerrit as a promise of
> > > > having tested the patch completely. For cases where patches don't have
> > a +1
> > > > verified from the developer, maintainer has the following options
> > > > a. just do the code-review and award a +2 code review.
> > > > b. pull the patch locally and test completely and award a +1 verified.
> > > > Both the above actions would result in triggering of regression runs
> > for
> > > > the patch.
> > >
> > > Would it not help if anyone giving +1 code-review starts the regression
> > > tests too? When developers ask me to review, I prefer to see reviews
> > > done by others first, and any regression failures should have been fixed
> > > by the time I look at the change.
> > When this idea was originated (long back) I was in favour of having
> > regression triggered on a +1, however verified flag set by the developer
> > would still trigger the regression. Being a maintainer I would always
> > prefer to look at a patch when its verified  flag is +1 which means the
> > regression result would also be available.
> >
> 
> 
> Niels requested in IRC that it is good have a mechanism of getting all
> patches that have already passed all regressions before starting review.
> Here is what I found
> a. You can use the search string
> status:open label:Verified+1,user=build AND label:Verified+1,user=nb7build
> b. You can bookmark this link and it will take you directly to the page
> with list of such patches.
> 
> http://review.gluster.org/#/q/status:open+label:Verified%252B1%252Cuser%253Dbuild+AND+label:Verified%252B1%252Cuser%253Dnb7build

Hmm, copy/pasting this URL does not work for me, I get an error:

    Code Review - Error
    line 1:26 no viable alternative at character '%'
    [Continue]


Kaushal, could you add the following labels to gerrit, so that we can
update the Jenkins jobs and they can start setting their own labels?

http://review.gluster.org/Documentation/config-labels.html#label_custom

- Smoke: misc smoke testing, compile, bug check, posix, ..
- NetBSD: NetBSD-7 regression
- Linux: Linux regression on CentOS-6

Users/developers should not be able to set these labels, only the
Jenkins accounts are allowed to.

The standard Verified label can then be used for manual verification by
developers, qa and reviewers.

Thanks,
Niels
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://www.gluster.org/pipermail/maintainers/attachments/20160114/9eed6986/attachment.sig>