[Gluster-devel] Coming soon: Enforcing bug/version and git/branch for submitted patches in Gerrit

[Niels de Vos]

As agreed in yesterday meeting, Jenkins will now mark change requests
with Verified -1 whenever the branch does not match the version for
which the related bug was filed.

The "rh-bugid" Jenkins job has been disabled, as its check has also been
integrated in the "compare-bug-version-and-git-branch" job.

Do let me know if there are any issues. Thanks,
Niels


On Wed, Aug 13, 2014 at 07:19:41PM +0200, Niels de Vos wrote:
> Hi all,
> 
> in todays meeting, we briefly touched upon a long overdue item.
> 
> For being able to track changes, and confirm that they have been fixed 
> in certain releases, we need a bug per GlusterFS version if the change 
> will be submitted for different branches.
> 
> Only this way, we can change the status of a bug to ON_QA with a alpha 
> or beta version. It allows us to list all the bugs that have been fixed 
> for a particular release.
> 
> With a new Jenkins job[1], the bug/version and git/branch will be 
> checked, and an error is returned when there is a mismatch. So, if you 
> are working on a patch, and want to send the patch to multiple branches, 
> this is roughly what you need to do:
> 
> 0. let us assume you work on a patch for mainline (Bug #1)
> 1. you post a patch against the master branch (ChangeId A)
> 2. you move Bug #1 to status POST
> 3. smoke tests are running, bug is for mainline, change for master: OK
> 4. you decide that the change is important enough to get fixed in 3.6
> 5. clone Bug #1 (click link in upper right corner in the Bug), as Bug #2
> 6. backport[2] ChangeId A to git branch release-3.6, this is ChangeId B
> 7. move Bug #2 to status POST
> 
> This process should be familiar to most developers. If not, it is 
> probably time to check the "Bugs present in multiple Versions" paragraph
> of the Bug Triage Guidelines[3].
> 
> At the moment, the bug/version and git/branch check is not enforced yet.  
> The Jenkins job is running for each patch submission, but failures are 
> ignored. After some time (a week, or maybe two) we can turn the failures 
> into real errors. During this time, any feedback is much appreciated.  
> Additional features or checks can be added on request.
> 
> For example:
>   Should we allow submitting changes for bugs that are already in 
>   MODIFIED, ON_QA or CLOSED state? Probably not, but this tends to 
>   happen on occasion.
> 
> Please send any questions or comments to this list and/or me. If you 
> have particular failures when posting a change and need clarification, 
> let me know too.
> 
> Thanks,
> Niels
> 
> 
> [1] http://build.gluster.org/job/compare-bug-version-and-git-branch/
> [2] http://www.gluster.org/community/documentation/index.php/Backport_Guidelines
> [3] http://www.gluster.org/community/documentation/index.php/Bug_triage#Bugs_present_in_multiple_Versions
> _______________________________________________
> Gluster-devel mailing list
> Gluster-devel at gluster.org
> http://supercolony.gluster.org/mailman/listinfo/gluster-devel