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 >> Closing issues (as opposed to Resolving).


Copy link to this message
-
Re: Closing issues (as opposed to Resolving).
If we later figure out that an issue caused a bug (even after a release),
will we be able to mention that in the original JIRA?  I find it useful to
be able to track that, particularly for forward/backport purposes.
Also, can we reopen issues after they have been closed?  If so, what's the
point of closing?

Greg

On Fri, Aug 31, 2012 at 10:53 AM, Jonathan Hsieh <[EMAIL PROTECTED]> wrote:

> Hey all,
>
> I propose that we close issues after a release is done.
>
> Close is stronger than resolve -- I believe it makes the issue essentially
> read only.  There are many resolved issues from 0.20, 0.89, and 0.90.6 <
> that could be closed, (as well as issues from 0.92.1, and 0.94.1..
>
> This would force discussion on old topics to new jiras and make things a
> little tidier.
>
> Thoughts?
>
> Jon.
>
> --
> // Jonathan Hsieh (shay)
> // Software Engineer, Cloudera
> // [EMAIL PROTECTED]
>
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