[cle-release-team] [sakai2-tcc] Sakai CLE 2.9.0 release status

Mon Mar 26 16:38:15 PDT 2012

Also, couldn't we just do

Open->In Progress->Resolved (Ready to Test)->In Progress->Closed (Verified)

Or would having essentially two In Progress (In Progress - Development/In
Progress - Testing) be more used? Maybe this is what you're thinking.

And as far as not being able to edit closed tickets, you can add a property
jire.issue.editable to the "Closed" step to make it editable. I'm pretty
sure this works and we were using it on the UMich workflow if this is
desired globally.

https://confluence.atlassian.com/pages/viewpage.action?pageId=193300072

On Mon, Mar 26, 2012 at 7:21 PM, Sam Ottenhoff <ottenhoff at longsight.com>wrote:

> My vote would be for not changing anything. This status seems the same
> as In Progress to me. I have never spent more than 30 mins testing a
> single jira issue. I don't see concurrent testing as a major issue
> right now.
>
> On 3/26/12, Steve Swinsburg <steve.swinsburg at gmail.com> wrote:
> > Oops, I forgot a status of ours. We have Testing in between Ready for
> Test
> > and Closed.
> >
> > Anyway, I am -100 the idea of closing tickets as an indicator they are
> > tested. It was what we used to do in Jira 3 and worked ok, but in Jira 4,
> > closing the tickets means they need to be reopened before you can edit
> them,
> > ie to change the merge flag. This just disrupts everything and sends out
> new
> > notifications. Closing should mean its done, all work including QA is
> done,
> > all merges are done, move on. I know you aren't suggesting this Matthew,
> > just wanted to put it out there as an issue.
> >
> > I think a new field that indicates that an item is being tested is fine.
> But
> > you are also going to need one to indicate testing is complete.
> >
> > So the workflow could be:
> > Ticket created - Open/Unresolved
> > Developer works on ticket     - In progress (not always used, doesn't
> matter too
> > much)
> > Developer resolves ticket - Resolved
> > QA person takes ticket - Testing
> > If issues in testing, reopen.
> > If no issues from testing, Verified/Testing complete
> > Merges are done and issue edited to set appropriate values on branch
> merge
> > status fields
> > Issue closed.
> >
> > cheers,
> > S
> >
> > On 27/03/2012, at 10:06 AM, Matthew Jones wrote:
> >
> >> Well, as far as merging, the merging is indicated by the Merge status
> >> dropdown which mirrors the statuses of the the other fields including
> >> Merge, Resolved (Ready for Testing?), Closed (Tested).
> >>
> >> I believed that the ideal workflow involved closing the original ticket
> >> (which means it was verified) before the merge could happen. The branch
> >> manager would then set the merge drop down to Resolved. Then QA would
> test
> >> the branch, and set the Merge flag to Closed after they verified a
> branch.
> >> But we never had enough QA lately to test the initial issue, let alone
> >> whether or not the merge worked. And Sam is the only one really doing
> >> branch management.
> >>
> >> So we'd basically just merge as soon as that flag was set, if the issue
> >> was really a bug.
> >>
> >> I'm not against this new status, I just feel like it would be used as
> much
> >> as the "In Progress" status is. I can definitely see the value if there
> >> are multiple QA testers and they don't want other people duplicating
> >> effort. This rarely happens when fixing bugs though.
> >>
> >> -Matthew
> >>
> >> On Mon, Mar 26, 2012 at 6:27 PM, Aaron Zeckoski <azeckoski at unicon.net>
> >> wrote:
> >> We have an extra step of merging into branches at the moment which
> >> means we (Sakai) have something between Testing complete and Closed so
> >> that adds a bit more complexity and my preference is to take baby
> >> steps and not overcomplicate things.
> >>
> >> For now, I think we should just add an extra step in between the
> >> current "Resolved" and "Tested" statuses which indicates it is being
> >> tested. I don't think we should reassign it because that has some
> >> negative consequences in terns of reopening and it seems overly
> >> complex to create a subtask every time a ticket is being verified.
> >>
> >> If anyone is hugely against trying this for now then please let me
> >> know. Otherwise I will proceed with this first thing tomorrow.
> >>
> >> This stuff can all be changed later of course.
> >>
> >> -AZ
> >>
> >>
> >> On Mon, Mar 26, 2012 at 6:13 PM, Steve Swinsburg
> >> <steve.swinsburg at gmail.com> wrote:
> >> > At ANU we renamed some of the existing statuses and added a couple
> more.
> >> >
> >> > So our workflow is:
> >> >
> >> > Open/Unresolved
> >> > In Progress
> >> > Resolved
> >> > Staged for Test (you could eliminate this one, it just signals that an
> >> > issue
> >> > is on the testing server)
> >> > Ready for Test
> >> > Closed
> >> >
> >> > In regards to reassigning tickets when working on them, I think that
> is
> >> > important so that people know what is happening. If more work needs to
> >> > be
> >> > done, just reassign back to the original developer who worked on it.
> >> >
> >> > Alternatively we could start using the Project Roles more, and have a
> >> > defined set of QA people, then adjust the notification scheme so that
> >> > those
> >> > people get notified at the appropriate time.
> >> >
> >> > cheers,
> >> > Steve
> >> >
> >> > On 27/03/2012, at 4:51 AM, Matthew Jones wrote:
> >> >
> >> > Yea Jira never really had any good way of dealing with this (identify
> >> > who is
> >> > testing it), and we've talked about it in the past. At Michigan we
> ended
> >> > up
> >> > using a completely separate system (Pivotal Tracker) to manage the QA
> >> > process because Jira alone just was not doing it. I believe that
> >> > solution
> >> > really ended up making things a lot more clearer than trying us use
> >> > wiki's,
> >> > jiras, text documents and emails.
> >> >
> >> > For multiple users on the same issue, the only really good idea they
> >> > have is
> >> > for subtasks (
> >> >
> https://confluence.atlassian.com/display/JIRA/How+do+I+assign+issues+to+multiple+users
> >> > )
> >> > and I'd even suggested in the past that we could use a plugin like the
> >> > "Create subtask on transition"
> >> > (
> https://studio.plugins.atlassian.com/wiki/display/CSOT/Jira+Create+Subtask+for+transition
> >> > )
> >> > which would automatically create a subtask on each issue when it hits
> >> > resolved that essentially was "Test SAK-XXXXX". When this was resolved
> >> > then
> >> > both the parent and subtask were closed.
> >> >
> >> > However in the past this was basically dismissed because, well we've
> got
> >> > hundreds of issues in the resolved state and nobody was reviewing them
> >> > anyway (no QA) so what's the point? It just creates more useless
> tickets
> >> > that won't be reviewed.
> >> >
> >> > I think the tester can watch it, the tester can comment "I'm testing
> >> > it",
> >> > but that should be about it. If we had people doing full time testing
> >> > and
> >> > actually caught up (where all of these issues were closed) then that's
> >> > fine.
> >> >
> >> > Is there a reason we can't just RENAME the current status from saying
> >> > "Resolved" to "Resolved - Ready for Testing" and "Closed" to "Closed -
> >> > Issue
> >> > Verified". What would another state get us?
> >> >
> >> > On Mon, Mar 26, 2012 at 1:35 PM, Noah Botimer <botimer at umich.edu>
> wrote:
> >> >>
> >> >> I don't disagree. The emails are handy, and why I often Watch issues
> >> >> I've
> >> >> touched. Maybe that can be an automatic part of marking something
> >> >> Resolved
> >> >> (getting added as a watcher)?
> >> >>
> >> >> I was also reminded of something last week -- some people get tons of
> >> >> JIRA
> >> >> emails and they often go to a folder or just overlooked. In that
> mode,
> >> >> a
> >> >> direct contact is the only effective way forward, and it is probably
> a
> >> >> good
> >> >> practice anyway if there are questions.
> >> >>
> >> >> I think you're right about status + fix version, but I am interested
> in
> >> >> "who has the ball", which leaving the developer assigned doesn't seem
> >> >> to
> >> >> indicate.
> >> >>
> >> >> Thanks,
> >> >> -Noah
> >> >>
> >> >> On Mar 26, 2012, at 1:21 PM, Bryan Holladay wrote:
> >> >>
> >> >> I'm not a big fan of re-assigning jira's for testing.  When you do
> >> >> that, the person who was originally assigned won't be notified of any
> >> >> comments/etc unless they physically clicked "watch" in the ticket.
> >> >> This is usually the person you want fixing any bugs found.
> >> >>
> >> >> how about:
> >> >>
> >> >> Resolved + Fix version means it's ready for testing
> >> >> Closed + fix version means it's tested and confirmed
> >> >>
> >> >> -Bryan
> >> >>
> >> >> On Mon, Mar 26, 2012 at 1:11 PM, Noah Botimer <botimer at umich.edu>
> >> >> wrote:
> >> >>
> >> >> Is this something we can handle with assignment of the issue? Any
> >> >> mechanism is going to require some diligence to be useful -- they're
> >> >> all
> >> >> roughly equivalent there. But, I think the "who is the contact for
> this
> >> >> issue?" question is pretty important. If you are going to commit to
> >> >> testing
> >> >> it (claim it), assigning to yourself is a good way to do that.
> >> >>
> >> >>
> >> >> I am just a little hesitant to add more interim states -- our
> workflow
> >> >> and
> >> >> reports are complicated enough as it is. If it's a matter of access,
> >> >> our few
> >> >> known QA folks should definitely be able to assign/unassign issues
> >> >> across
> >> >> the board.
> >> >>
> >> >>
> >> >> This is just a thought -- I won't be hurt if we end up with another
> >> >> status. I just think Resolved + Unassigned is a good way to say "this
> >> >> needs
> >> >> testing" and Resolved + Assigned is a good way to say "this is being
> >> >> tested". It may alternatively make sense to set up a mail
> group/account
> >> >> like
> >> >> KERNEL TEAM for QA, and make it the default assignee for newly
> resolved
> >> >> issues (for an activity email push for those interested and easier
> >> >> reports
> >> >> of items needing to be tested).
> >> >>
> >> >>
> >> >> Thanks,
> >> >>
> >> >> -Noah
> >> >>
> >> >>
> >> >> On Mar 26, 2012, at 12:53 PM, Aaron Zeckoski wrote:
> >> >>
> >> >>
> >> >> It isn't too much trouble. I could probably get to that later today.
> >> >>
> >> >> -AZ
> >> >>
> >> >>
> >> >>
> >> >> On Mon, Mar 26, 2012 at 12:48 PM, Diego del Blanco Orobitg
> >> >>
> >> >> <diego.delblanco at samoo.es> wrote:
> >> >>
> >> >> Ok, Simple way at this moment: add a comment with the "testing"
> message
> >> >> in
> >> >> the Jira.
> >> >>
> >> >> Anyway, maybe "testing" intermediate status between Resolved-fixed
> and
> >> >> Verified can be useful but as you say if doing it it's not too much
> >> >> trouble.
> >> >>
> >> >>
> >> >> Diego.
> >> >>
> >> >>
> >> >>
> >> >>
> >> >> -----Mensaje original-----
> >> >>
> >> >> De: azeckoski at gmail.com [mailto:azeckoski at gmail.com] En nombre de
> Aaron
> >> >> Zeckoski
> >> >>
> >> >> Enviado el: lunes, 26 de marzo de 2012 13:39
> >> >>
> >> >> Para: Diego del Blanco Orobitg
> >> >>
> >> >> CC: Miguel Carro Pellicer; Rob.Egan at marist.edu;
> >> >> cle-release-team at collab.sakaiproject.org
> >> >>
> >> >> Asunto: Re: [cle-release-team] [Building Sakai] [WG: Sakai QA] Sakai
> >> >> CLE
> >> >> 2.9.0 release status
> >> >>
> >> >>
> >> >> I would encourage you ro think of a process that uses jira itself as
> a
> >> >> way
> >> >> to know if an issue is being tested. This may be an adjustment in the
> >> >> JIRA
> >> >> workflow but I can make that without too much trouble. The problem
> with
> >> >> the
> >> >> google docs thing is that it doesn't scale up very well and it
> requires
> >> >> insider knowledge so it is a barrier to community participation.
> >> >>
> >> >>
> >> >> Also, in the current workflow, there is a "Verified" status which is
> >> >> what
> >> >> issues should be set to when testing is complete. So anything not
> >> >> verified
> >> >> yet will be marked as "resolved - fixed" and once testing is complete
> >> >> it is
> >> >> marked as "verified".
> >> >>
> >> >>
> >> >> -AZ
> >> >>
> >> >>
> >> >>
> >> >> On Mon, Mar 26, 2012 at 6:58 AM, Diego del Blanco Orobitg
> >> >> <diego.delblanco at samoo.es> wrote:
> >> >>
> >> >> Dear Rob:
> >> >>
> >> >>
> >> >> We are going to begin to test the jira issues as Aaron said. To
> >> >> coordinate
> >> >> with you and don't duplicate work, we can create a shared document
> (in
> >> >> google docs or in a confluence page...), where each time one of us
> >> >> selects a
> >> >> jira to test, we need to add it to the document, so it's easy to
> check
> >> >> if an
> >> >> issue is "in use" at that moment. There is only need to search in the
> >> >> document. If it's not, then it's free.
> >> >>
> >> >>
> >> >> And in that way we have the full list of jiras tested by each one
> too.
> >> >>
> >> >>
> >> >> Aaron do you think this is good way or do you recommend other way as
> >> >> can
> >> >> be to put comments directly on Jira's indicating that we are working
> on
> >> >> this
> >> >> issue?
> >> >>
> >> >>
> >> >> I think in the shared document will be quicker to search "free
> issues"
> >> >> to
> >> >> work with.
> >> >>
> >> >>
> >> >> Other question... Once tested a Jira if everything is ok.. do we need
> >> >> to
> >> >> modify something in the Jira (add a comment or change state) or only
> >> >> communicate it to the team?
> >> >>
> >> >>
> >> >> Thanks
> >> >>
> >> >>
> >> >> Diego.
> >> >>
> >> >>
> >> >>
> >> >> -----Mensaje original-----
> >> >>
> >> >> De: azeckoski at gmail.com [mailto:azeckoski at gmail.com] En nombre de
> >> >>
> >> >> Aaron Zeckoski Enviado el: viernes, 23 de marzo de 2012 22:36
> >> >>
> >> >> Para: Miguel Carro Pellicer; Rob.Egan at marist.edu; Diego del Blanco
> >> >>
> >> >> Orobitg
> >> >>
> >> >> CC: Sam Ottenhoff; cle-release-team at collab.sakaiproject.org
> >> >>
> >> >> Asunto: Re: [Building Sakai] [WG: Sakai QA] Sakai CLE 2.9.0 release
> >> >>
> >> >> status
> >> >>
> >> >>
> >> >> Samoo guys,
> >> >>
> >> >> Here is the filter of items to QA in order for 2.9. There are quite a
> >> >> few
> >> >> (over 600) and there will be more coming in the following weeks.
> >> >>
> >> >> Just start cranking through them and you can give a status update at
> >> >> the
> >> >> meeting next week.
> >> >>
> >> >>
> >> >>
> https://jira.sakaiproject.org/secure/IssueNavigator.jspa?mode=hide&req
> >> >>
> >> >> uestId=13243
> >> >>
> >> >>
> >> >> I am copying in Rob from Marist since he does some QA as well and you
> >> >> guys
> >> >> might want to coordinate some.
> >> >>
> >> >>
> >> >> -AZ
> >> >>
> >> >>
> >> >>
> >> >> El 22/03/2012 14:07, Aaron Zeckoski escribió:
> >> >>
> >> >>
> >> >> Yes, they are always at 10am US NY time on thursdays.
> >> >>
> >> >> I will double check with the group and send you something later today
> >> >> (maybe a JIRA filter with a series of tickets in it).
> >> >>
> >> >> -AZ
> >> >>
> >> >>
> >> >> On Thu, Mar 22, 2012 at 9:03 AM, Miguel Carro Pellicer
> >> >> <miguel.carro at samoo.es> wrote:
> >> >>
> >> >>
> >> >> Got it, i think we can help in those activities.
> >> >>
> >> >>
> >> >> Assign me some Jiras and we will verify/validate each ticket in the
> >> >> affected QA servers. Additionaly, we can propose a solution if the
> Jira
> >> >> requires a developer intervention.
> >> >>
> >> >>
> >> >> Usually the meetings are at the same hour? We're in GMT+1
> >> >>
> >> >>
> >> >> Regards, Miguel.
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>
> >> >> _______________________________________________
> >> >> 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
> >> >
> >> >
> >> >
> >> > _______________________________________________
> >> > 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/20120326/0ba5477b/attachment-0006.html 