[cle-release-team] Sakai Bug Bash

[Matthew Jones]

Okay, I left off the reporter of the issue (if they have that
permission). However usually the reporter isn't the one verifying the fix.
More often it's the either the Assignee (not ideal) or neither of these
people.

As far as the SAK project goes, the only users in the project role QA *are*
the sakai-QA group  so it's essentially the same thing. And this group of
154 users is at least 150 users more than those who are actually doing QA.
:) This might be different for some other projects though who might have a
different QA role.

On Wed, Jun 27, 2012 at 11:44 AM, Aaron Zeckoski <azeckoski at unicon.net>wrote:

> "The way this is currently setup, users have to be in the group
> "sakai-QA" (around 140 seemingly random people) or an Administrator to
> execute and see the transition to "tested"."
>
> This is not actually right.
> The workflow in face allows all of the following people:
>
> Only the reporter of the issue can execute this transition.
> — AND
> Only users with Resolve Issues permission can execute this transition.
> — OR
> Only users in project role QA can execute this transition.
> — OR
> Only users in group sakai-QA can execute this transition.
> — OR
> Only users in project role Administrators can execute this transition.
>
> Hope this helps
> -AZ
>
>
> On Wed, Jun 27, 2012 at 11:07 AM, Matthew Jones <matthew at longsight.com>
> wrote:
> > The way this is currently setup, users have to be in the group "sakai-QA"
> > (around 140 seemingly random people) or an Administrator to execute and
> see
> > the transition to "tested".
> >
> > Also which list are you verifying? I'd start with verifying the "to be
> > merged" prior to adding flagging ones that need to be merged to this
> list.
> >
> https://jira.sakaiproject.org/secure/IssueNavigator.jspa?mode=hide&requestId=13119
> >
> > I believe the workflow should have the person that fixes the issue
> generally
> > flag it initially as a merge candidate or not.
> >
> > Did you have some other filter that lists blockers/criticals fixed that
> are
> > only in trunk and aren't flagged for merge?
> >
> > On Wed, Jun 27, 2012 at 10:45 AM, Beth Kirschner <bkirschn at umich.edu>
> wrote:
> >>
> >> Hi Aaron,
> >>
> >>   The UM team is trying to QA resolved Blocker & Critical bugs, but
> we're
> >> running into JIRA workflow problems (some staff can only select "Close
> >> without testing", others can't select anything to indicate an issue has
> been
> >> verified). We're testing on a local trunk build, due to problems on the
> >> nightly2 server at the moment. Any idea how to resolve the workflow
> issues
> >> in JIRA? For now, we're selecting "Close without testing", and then
> adding a
> >> comment that the issue has been tested.
> >>
> >>   If the JIRA workflow is working correctly, I believe the intent is to
> >> mark the issue is "Verified" (by selecting "Tested"), and if not already
> >> set, we're setting the 2.9.x status to "merge" -- is this correct?
> >>
> >> Thanks,
> >> - Beth
> >>
> >> _______________________________________________
> >> cle-release-team mailing list
> >> cle-release-team at collab.sakaiproject.org
> >> http://collab.sakaiproject.org/mailman/listinfo/cle-release-team
> >
> >
> >
> > _______________________________________________
> > cle-release-team mailing list
> > cle-release-team at collab.sakaiproject.org
> > http://collab.sakaiproject.org/mailman/listinfo/cle-release-team
> >
>
>
>
> --
> Aaron Zeckoski - Software Architect - http://tinyurl.com/azprofile
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/cle-release-team/attachments/20120627/1e7419f8/attachment-0006.html