Mailing-List: contact clerezza-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: clerezza-dev@incubator.apache.org
Received-SPF: pass (nike.apache.org: local policy)
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Apple Message framework v1077)
Subject: Re: Resolving / Closing issues
From: Tsuyoshi Ito <tsuy.ito@trialox.org>
In-Reply-To: <4B7CDEE2.7060005@trialox.org>
Date: Thu, 18 Feb 2010 10:13:19 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <02300CEA-BFC1-4A82-AC17-79D6D660E875@trialox.org>
References: <bfcea8c71002171305xe65b2a6oc435bd92302a82f2@mail.gmail.com>
 <4B7CDEE2.7060005@trialox.org>
To: clerezza-dev@incubator.apache.org

Ok for me.

Tsuy

On Feb 18, 2010, at 7:32 AM, Hasan wrote:

> supported
>=20
> hasan
>=20
> On 02/17/2010 10:05 PM, Reto Bachmann-Gmuer wrote:
>> I suggest the following usage of the Jira issue resolved and closed.
>>=20
>> - An issue is marked as resolved if the developer would like to have
>> somebody look at, depending on the level of confidence the developer
>> has in the proposed solution, the urgency of the issue and the number
>> of projected and files affected[1] the proposed resolution is in =
trunk
>> or in an issue branch. The issue will stay with this status till
>> somebody reviewed the proposed solution and either closes or reopens
>> the issue. To prevent that many do the same review at this stage, the
>> reviewer adds the comment "Review" when they start. Any committer may
>> request a proposed solution to be removed from trunk, this has the
>> same effect as a veto on a closed issue.
>>=20
>> - An issue is marked closed either by the developer or the reviewer
>> when the proposed solution has been committed to trunk and no second
>> opinion is explicitly wished. With the closure of an issue a lazy
>> consensus vote for 72h is opened on the proposed solution. If a veto
>> is cast the issue is reopened and the person committing the solution
>> must undo the change immediately [2] (but everybody else is free to =
do
>> so), if more recent patches require the vetoed issue, the conflicting
>> patches are removed and the respective issues reopened as well.
>>=20
>>=20
>> Reto
>>=20
>>=20
>> See also: http://www.apache.org/foundation/voting.html
>>=20
>> 1. If an issue affects many projects and file it gets harder to merge
>> it back, so the cost of the branch is higher. If an issue branch is
>> wished for an issue affecting many projects (I'd say, more than 4) it
>> might be better clone the whole parent into the issue branch rather
>> than the individual projects.
>> 2.It need not disappear from the history, but the truk version must =
be
>> changed back as if the change had never happened, an article on how =
to
>> "rollback": =
http://jacwright.com/blog/75/how-to-roll-back-changes-using-subversion/
>>  =20
>=20
> --=20
>  Hasan Hasan
>  trialox AG
>  Binzm=FChlestrasse 14, CH-8050 Z=FCrich
>  Tel: +41 44 635 7577
>  Fax: +41 44 635 7574
>  URL: http://trialox.org
>=20

--trialox ag--------------------------------------

Tsuyoshi Ito
Binzmuehlestrasse 14
CH-8050 Z=FCrich
Tel. +41-44 635 7577
Fax +41-44 635 7574
URL: http://trialox.org