Home | About | Sematext search-lucene.com search-hadoop.com
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB
 Search Hadoop and all its subprojects:

Switch to Threaded View
HBase >> mail # dev >> Resolved JIRAs


Copy link to this message
-
Re: Resolved JIRAs
Hmm... That would would be difficult to track in bulk, though.
It's true that I have closed all 0.94.x issues when 0.94.x is released. That has been very helpful to identify jiras that folks mislabel later (which happens very frequently).

The argument could also be made that *any* release should lead to closing the issue (as long as it has a fix for said version, of course).At that point the code is out in the wild and is used, any change now should require a new jira.

-- Lars

----- Original Message -----
From: Andrew Purtell <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Cc:
Sent: Monday, July 29, 2013 12:19 PM
Subject: Re: Resolved JIRAs

On Mon, Jul 29, 2013 at 11:06 AM, Lars George <[EMAIL PROTECTED]> wrote:

> That is exactly my point, ie the former case. If I commit to all major
> branches within a day as is common, but the branches release at various
> times, who is going to close the issue? The release manager who releases
> first?
IMHO:

The commiter should set the state to 'Resolved' after the change is applied
to all desired target branches.

The RM for the _last_ affected release should set the state to 'Closed',
essentially garbage collecting when refcount goes to 0.

--
Best regards,

   - Andy

Problems worthy of attack prove their worth by hitting back. - Piet Hein
(via Tom White)
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB