Mailing-List: contact dev-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@jackrabbit.apache.org
Received-SPF: pass (hermes.apache.org: domain of jukka.zitting@gmail.com
 designates 66.249.82.232 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition;
        b=K0drwmT66zu49AutXZjaaz1SO8ADF1UrEl6pLnAx50SXRH488HOgSUqErM10iyxv23hWOh/9M3TUqBPeiXxVtk0NuBw2rKnNOeWEZiOegL0DT78Izi7xxMwD6X6u8wFDFnmam+ymBOLukDNG2YtY3c06F7QbwxjudLC94qDotgg=
Message-ID: <510143ac0611290345k4db86a3fn9cfd923e5cdf867e@mail.gmail.com>
Date: Wed, 29 Nov 2006 13:45:39 +0200
From: "Jukka Zitting" <jukka.zitting@gmail.com>
To: dev@jackrabbit.apache.org
Subject: Jira guidelines
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Hi,

In order to make our issue tracker better support the release process
I had to again tweak some issues as you've probably noticed by the
number of recent Jira notifications. To make things easier I'd like to
propose the following general guidelines for working with Jira issues:

* Issue Type

Generally only "Bug" issues are considered for inclusion in patch releases.

* Affects Version(s)

Use this when entering "Bug" reports. Select all the release numbers
where you believe the reported issue to occur. If you don't know or if
the issue was introduced just recently in trunk, just leave the field
empty. Leave this field empty also when entering feature or
improvement requests.

Selecting also old release numbers makes it easier for people that are
running older versions to quickly determine whether a reported bug
affects their installation or not.

* Fix Version(s)

This field is essential for the release process. Generally you should
fill it when resolving an issue; use the release numer of the release
that's next planned from trunk (normally the next minor x.y release).
If the issue is a bug report and you think the fix is safe enough to
be included in a patch release (i.e. it shouldn't introduce any
regressions), you can also select the next planned patch release
number (x.y.z).

You can also enter a target release number here already before the
issue is fixed if you consider that the issue is essential for the
release. This allows us to better track the progress towards a
release.

* Resolution

Always use the resolution "Fixed" when resolving an issue that you've
solved. All other resolutions will invalidate the issue so that it
won't be included in any change histories or known issue lists.

* Closing an issue

Issues should be closed (as opposed to resolving them) only when
they've been included in an official release. Thus only the release
manager should ever need to close issues.

Note that a closed issue should never be reopened since it's
considered a part of an existing release. File a new issue that links
back to the closed one if you find that the resolution in fact doesn't
work.

BR,

Jukka Zitting