+1 for #3. And well articulated Lars (H). ------------------- Jesse Yates @jesse_yates jyates.github.com
On Mon, Jul 29, 2013 at 10:21 PM, Lars George <lars.geo...@gmail.com> wrote: > +1 for #3 > > On Jul 30, 2013, at 7:00, Nicolas Liochon <nkey...@gmail.com> wrote: > > > +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) > >> >
