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
bq. another way to do this is not have issues that target multiple
branches/releases.

+1

On Mon, Jul 29, 2013 at 2:34 PM, Andrew Purtell <[EMAIL PROTECTED]> wrote:

> > The argument could also be made that *any* release should lead to closing
> the issue
>
> For issues that have multiple commit/target versions, we can close it after
> the first release goes out but then we can't change it's state if there's
> an issue with another branch/release, maybe as simple as making sure it got
> committed there or (re)testing. That could be fine, I have no strong
> opinion.
>
> Or another way to do this is not have issues that target multiple
> branches/releases.
>
>
> On Mon, Jul 29, 2013 at 2:22 PM, lars hofhansl <[EMAIL PROTECTED]> wrote:
>
> > 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)
> >
> >
>
>
> --
> 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