Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

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


Copy link to this message
-
Re: Resolved JIRAs
+1 for #3 as well
Le 30 juil. 2013 06:44, "Ted Yu" <[EMAIL PROTECTED]> a écrit :

> I would lean toward #3.
>
> Cheers
>
> On Mon, Jul 29, 2013 at 9:30 PM, lars hofhansl <[EMAIL PROTECTED]> wrote:
>
> > As long as we all agree. :)
> >
> > We have three options:
> >
> > 1. separate jiras for each version
> > 2. last release closes jira
> > 3. first release closes jira, separate jiras needed for further changes
> >
> > It should also be easy to determine which jiras need to be close and be
> > able to do that in bulk. That is easy in #1 and #3, but hard for #2.
> > #1 and #2 are easier to understand.
> > #3 can be confusing.
> > #1 is cumbersome.
> >
> > My vote would remain with #3.
> >
> > -- Lars
> >
> >
> >
> > ________________________________
> >  From: Enis Söztutar <[EMAIL PROTECTED]>
> > To: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>; lars hofhansl <
> > [EMAIL PROTECTED]>
> > Sent: Monday, July 29, 2013 7:01 PM
> > Subject: Re: Resolved JIRAs
> >
> >
> >
> > I think it makes sense to group fix versions in the same jira as long as
> > there is no significant time delay between patches getting in. First
> > release closing the issue also makes sense, since closing is basically
> > marking the issue as complete. If addendums are needed, we can do another
> > jira.
> >
> >
> >
> > On Mon, Jul 29, 2013 at 2:45 PM, lars hofhansl <[EMAIL PROTECTED]> wrote:
> >
> > Yeah, but that would be a lot of extra jiras to file.
> > >I think we can co-fix issues across multiple branches exactly until one
> > of them is released.
> > >
> > >We should not add new patches over long time spans to the same jira
> > anyway.
> > >
> > >
> > >
> > >-- Lars
> > >
> > >
> > >
> > >----- Original Message -----
> > >
> > >From: Ted Yu <[EMAIL PROTECTED]>
> > >To: [EMAIL PROTECTED]
> > >Cc: lars hofhansl <[EMAIL PROTECTED]>
> > >Sent: Monday, July 29, 2013 2:39 PM
> > >Subject: 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