Move bugs to ON_QA based on snapshot builds?
Allon Mureinik
amureini at redhat.com
Wed Jan 28 08:46:36 UTC 2015
----- Original Message -----
> From: "Lior Vernia" <lvernia at redhat.com>
> To: devel at ovirt.org, infra at ovirt.org
> Sent: Wednesday, January 28, 2015 10:44:44 AM
> Subject: Move bugs to ON_QA based on snapshot builds?
>
> Hello everyone,
>
> I wanted to suggest that we automate the change of oVirt 3.6 bug status
> from MODIFIED to ON_QA based on nightly snapshot builds.
>
> The motivation should be clear: when bugs are fixed on the master
> branch, the fix becomes readily available for verification as soon as
> the next snapshot is built (and there's indeed someone to verify on the
> master branch - the same person who was working on the master branch and
> opened the bug!).
>
> We currently only move them to ON_QA on milestone builds (e.g. alpha,
> beta), but I don't think that's right for an open source project - the
> status of bugs (targeted to the nearest release) should be up-to-date
> with the actual state of the master branch.
>
> We've encountered the problem testing features for 3.6 the last couple
> of weeks, and since it's gonna be a long version this situation will
> likely occur often. So far I've been moving bugs to ON_QA myself, but I
> don't really want to follow the snapshot builds manually (nor move the
> bugs to ON_QA as soon as they're merged, in case the snapshot build
> doesn't happen).
>
> The downside would be that bugs could be VERIFIED at an early point in
> the development, and later regressions could occur that would render the
> verification obsolete. But this could happen just the same between
> release milestones...
>
> Thoughts?
I'm all for this.
By the time we reach Alpha, we'll have several hundred bugs in MODIFIED - if all of these are dumped to ON_QA simultaneously it will be impossible to manage/prioritize.
+1.
>
> Yours, Lior.
> _______________________________________________
> Infra mailing list
> Infra at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/infra
>
More information about the Infra
mailing list