incubator-clerezza-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tsuyoshi Ito <tsuy....@trialox.org>
Subject Re: Resolving / Closing issues
Date Thu, 18 Feb 2010 09:13:19 GMT
Ok for me.

Tsuy

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

> supported
> 
> hasan
> 
> On 02/17/2010 10:05 PM, Reto Bachmann-Gmuer wrote:
>> I suggest the following usage of the Jira issue resolved and closed.
>> 
>> - 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.
>> 
>> - 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.
>> 
>> 
>> Reto
>> 
>> 
>> See also: http://www.apache.org/foundation/voting.html
>> 
>> 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/
>>   
> 
> -- 
>  Hasan Hasan
>  trialox AG
>  Binzmühlestrasse 14, CH-8050 Zürich
>  Tel: +41 44 635 7577
>  Fax: +41 44 635 7574
>  URL: http://trialox.org
> 

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

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





Mime
View raw message