JIRA Workflow Updates/Status

[Andrew Bayer]

So at yesterday's governance meeting (http://meetings.jenkins-ci.org/jenkins/2011/jenkins.2011-02-09-19.04.html), we decided the following things in re: JIRA:

- To get rid of the Verified state, transitioning all bugs in that state currently to Closed.

- Bugs will enter resolved state when the code fixing the bug is built - this will be done by ci.jenkins-ci.org, looking for [FIXED JENKINS-XYZ], [FIXES JENKINS-XYZ], or [FIX JENKINS-XYZ] in the commit comment.

- Bugs will enter the closed state when the code fixing the bug is actually released. This will be done via new automation to be added to the HPI plugin's release process and new scripting in the core release process.

- All bugs that are currently marked as resolved and entered the resolved state at least six months ago today (Aug 10 2010) will be transitioned to the closed state. We'll do this again periodically.

I've removed the Verified state from our JIRA workflow, and have transitioned the previously Verified bugs to Closed. I'm in the process of moving the old Resolved bugs to Closed now.

I think we also do need an addendum to the policy for going into resolved/closed - for duplicates, Not a Bug and other situations where there's no actual code being changed, I think the state should still go to Resolved, and then I'll set up a periodic check for bugs that have gone into Resolved without code changes and transition those to Closed automatically. I think that's easier than making people resolve and close such issues by hand, or confuse things by going straight to Closed from Open, but I'm open to suggestions. =)

A.

[Mirko Friedenhagen]

Hm, I just had written up something at
http://wiki.jenkins-ci.org/display/JENKINS/Issue+Tracking. So removing
VERIFIED is final? Then I should adapt the page probably.

Regards
Mirko

--
http://illegalstateexception.blogspot.com/
https://github.com/mfriedenhagen/
https://bitbucket.org/mfriedenhagen/

[Andrew Bayer]

Yeah, Verified is gone. =)

A.

[Mirko Friedenhagen]

Hello,

I updated http://wiki.jenkins-ci.org/display/JENKINS/Issue+Tracking
again to include my understanding of the government meeting's
decision.

Regards
Mirko

[Nathan Parry]

> Bugs will enter the closed state when the code fixing the bug is actually released ... via new scripting in the core release process.

Could this also create an appropriate 'fix version' and apply that to
the bugs? (Or do we want to walk before we try to run)

--
Nathan

[Andrew Bayer]

We can definitely put something in a comment or somesuch with the fix version, working towards actually doing the *real* fix version stuff when we get the project split up nicely.

A.

[Erik Ramfelt]

It was up for discussion during the meeting, and it was agreed that we
would try the old suggestion that split up the issues into four
groups, core, plugins, security and infrastructure. That way core can
start using fix versions which is probably most important. And in a
couple of month we will see if we want separate projects for plugins,
because that would require some administration effort to set up.

I think this is a good way forward.

Regards
//Erik

[mlb5000]

It sounds like you're making some good strides towards making Jira
more usable for all sides. My bad for missing the governance meeting
and not being able to provide my feedback, work's been nuts :{. Props
to @abayer for bringing this to the top. It sounds like the old
VERIFIED state was being used like VERIFIED FIXED? It might be nice
to have an ACKNOWLEDGED state in between New and Open. It would be a
nice way to let contributors know that there are bugs to be looked
at. I know it would certainly help me right now as I try to clear out
some of the older bug reports. I also agree with making VERIFIED
FIXED a workflow action to go from RESOLVED->CLOSED as was agreed upon
in the meeting.

It's also good that you're moving towards fix versions. It's
important to have versions defined in Jira so that users can specify
in their reports the 'Affected Version(s)' for bugs. Also, if we keep
up with specifying affected versions users can search for all bugs
that affect various versions of Jenkins to be better informed when
deciding whether or not to upgrade. Not to mention the developers
will have information for git diff-tree.

@Erik, does this mean there will be "Core", "Plugins", "Security", and
"Infrastructure" projects in the Jira instance? This is really the
only way to facilitate tracking of Jenkins releases and the bugs that
go with them.

On Feb 10, 5:28 pm, Erik Ramfelt <eramf...@gmail.com> wrote:
> It was up for discussion during the meeting, and it was agreed that we
> would try the old suggestion that split up the issues into four
> groups, core, plugins, security and infrastructure. That way core can
> start using fix versions which is probably most important. And in a
> couple of month we will see if we want separate projects for plugins,
> because that would require some administration effort to set up.
>
> I think this is a good way forward.
>
> Regards
> //Erik
>
>
>
>
>
>
>
> On Thu, Feb 10, 2011 at 23:18, Nathan Parry <npa...@gmail.com> wrote:
> >>  Bugs will enter the closed state when the code fixing the bug is actually released ... via new scripting in the core release process.
>
> > Could this also create an appropriate 'fix version' and apply that to
> > the bugs?  (Or do we want to walk before we try to run)
>
> > --
> > Nathan
>
> > On Thu, Feb 10, 2011 at 2:48 PM, Mirko Friedenhagen

> > <mfriedenha...@gmail.com> wrote:
> >> Hello,
>
> >> I updatedhttp://wiki.jenkins-ci.org/display/JENKINS/Issue+Tracking

[Alan Harder]

On 2/10/11 11:14 AM, Andrew Bayer wrote:

- Bugs will enter resolved state when the code fixing the bug is built - this will be done by ci.jenkins-ci.org, looking for [FIXED JENKINS-XYZ], [FIXES JENKINS-XYZ], or [FIX JENKINS-XYZ] in the commit comment.

Please make the parsing work well for the rare case where a commit is related to multiple issues...
[FIXED JENKINS-ABC JENKINS-DEF] or [FIXED JENKINS-ABC] [FIXED JENKINS-DEF] ?

- Bugs will enter the closed state when the code fixing the bug is actually released. This will be done via new automation to be added to the HPI plugin's release process and new scripting in the core release process.

Cool!  I assume it'll double-check the issue is still in resolved state before closing, in case there was a commit that fixed it, but it got reopened before release..

    - Alan

[Andrew Bayer]

Re: the parsing - I'll see what the JIRA plugin's already capable of. =)

A.

[mlb5000]

On second thought, it wouldn't really be an acknowledged state, it
would be an acknowledged workflow action going from NEW->OPEN. Then
contributors can sort through bugs in the NEW state and verify that
that are real.

Maybe we could apply some heuristic to existing issues to put existing
bugs into the new state? Something like 'resolution = unresolved and
assigned = EMPTY and type = bug'?

The latter would be less important than the former though. It may just
be that we need to wade through the existing bug reports to narrow
them down by hand (which for me is probably a good exercise)

[Ullrich Hafner]

On 02/11/2011 06:33 AM, mlb5000 wrote:
> On second thought, it wouldn't really be an acknowledged state, it
> would be an acknowledged workflow action going from NEW->OPEN. Then
> contributors can sort through bugs in the NEW state and verify that
> that are real.
>

I think having such a kind of quality gate for new issues would be a
good thing for both contributors and reporters:
- the reporter sees that someone actually looked at the issue and
accepted it as valid (NEW->OPEN). If something is missing then the
reporter gets a fast feedback to provide more information (Comments in a
NEW issue).
- the committers see, which issues are already verified. So committers
just can pick an open issue and work on a resolution.

> Maybe we could apply some heuristic to existing issues to put existing
> bugs into the new state? Something like 'resolution = unresolved and
> assigned = EMPTY and type = bug'?

Maybe we should change that only for issues without comments.

> The latter would be less important than the former though. It may just
> be that we need to wade through the existing bug reports to narrow
> them down by hand (which for me is probably a good exercise)

Actually, I think we need to look at all of the bugs and evaluate
them... This is quite some work, but this could be split into several
work packages and could be done in parallel.

Ulli