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@xxxxxxxxxxx > http://supercolony.gluster.org/mailman/listinfo/gluster-devel _______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://supercolony.gluster.org/mailman/listinfo/gluster-devel
