+1 for #3 as well Le 30 juil. 2013 06:44, "Ted Yu" <yuzhih...@gmail.com> a écrit :
> I would lean toward #3. > > Cheers > > On Mon, Jul 29, 2013 at 9:30 PM, lars hofhansl <la...@apache.org> 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 <enis....@gmail.com> > > To: "dev@hbase.apache.org" <dev@hbase.apache.org>; lars hofhansl < > > la...@apache.org> > > 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 <la...@apache.org> 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 <yuzhih...@gmail.com> > > >To: dev@hbase.apache.org > > >Cc: lars hofhansl <la...@apache.org> > > >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 <apurt...@apache.org> > > 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 <la...@apache.org> > > 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 <apurt...@apache.org> > > >> > To: dev@hbase.apache.org > > >> > Cc: > > >> > Sent: Monday, July 29, 2013 12:19 PM > > >> > Subject: Re: Resolved JIRAs > > >> > > > >> > On Mon, Jul 29, 2013 at 11:06 AM, Lars George < > lars.geo...@gmail.com> > > >> > 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) > > >> > > > > > > > > >
