Mailing-List: contact dev-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@hbase.apache.org
Received-SPF: pass (athena.apache.org: domain of jesse.k.yates@gmail.com
 designates 209.85.128.177 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <E3238AF0-E9F8-44EB-8989-45F9FBDF1331@gmail.com>
References: <7368BDF3-2E34-4E64-AFC8-DFCE73D94334@gmail.com>
 <CAPcDmStGt5fajgoNf1gR756v-b+wU8hX-u0UWqSoo5V+FcnFaA@mail.gmail.com>
 <3DF26257-5FA2-4461-8398-6699A5975428@gmail.com>
 <CALte62y4j2T7gFccwLcDb3=C90dA_kS=y4+f5agJavr0n3X3sQ@mail.gmail.com>
 <CAPcDmSuxZnOPE=iBXT8xvc=FLj6P_iSj9zRiLapqxQp3A2nCxg@mail.gmail.com>
 <1375118586.10392.YahooMailNeo@web140603.mail.bf1.yahoo.com>
 <50628CC9-D908-4DE1-9A21-1D3D3C382245@gmail.com>
 <CA+RK=_BjWVr=ZTmNY=-1Gzc0N3vJeWwsv3rcW_dZsZo25vVX2g@mail.gmail.com>
 <1375132924.28691.YahooMailNeo@web140605.mail.bf1.yahoo.com>
 <CA+RK=_A38Hq4hb2_ZxftkLkjR2v+EWOGx4PkM_u8gpQoz4rzRg@mail.gmail.com>
 <CALte62zuBHu3yvCOAU-9ZJkTf-5eAeqza9C2unQG2ije7_6Yfg@mail.gmail.com>
 <1375134326.72175.YahooMailNeo@web140603.mail.bf1.yahoo.com>
 <CAMUu0w9K9CSYNCoRTp7xQidOYbFSzuM_tUm9MgPz_dFWwpUd-Q@mail.gmail.com>
 <1375158649.95452.YahooMailNeo@web140605.mail.bf1.yahoo.com>
 <CALte62zMCzHz9cuPHf5w5ptk8QkscGNbYfgca8z7n-Tk0=5vcg@mail.gmail.com>
 <CAPcDmSsoRH_6-jNw-cFOko128tNHcFqLYF==uioiedFe0+PnYA@mail.gmail.com>
 <E3238AF0-E9F8-44EB-8989-45F9FBDF1331@gmail.com>
From: Jesse Yates <jesse.k.yates@gmail.com>
Date: Mon, 29 Jul 2013 23:03:54 -0700
Message-ID: 
 <CAB5sDN+-FsZZifkbfiL0uvR-x8u67m=AS5f2Q1iaQDqa16mWrg@mail.gmail.com>
Subject: Re: Resolved JIRAs
To: dev@hbase.apache.org
Content-Type: multipart/alternative; boundary=047d7b343204e5534404e2b460d5

--047d7b343204e5534404e2b460d5
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

+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.george@gmail.com> wrote=
:

> +1 for #3
>
> On Jul 30, 2013, at 7:00, Nicolas Liochon <nkeywal@gmail.com> wrote:
>
> > +1 for #3 as well
> > Le 30 juil. 2013 06:44, "Ted Yu" <yuzhihong@gmail.com> a =E9crit :
> >
> >> I would lean toward #3.
> >>
> >> Cheers
> >>
> >> On Mon, Jul 29, 2013 at 9:30 PM, lars hofhansl <larsh@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 chang=
es
> >>>
> >>> 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=F6ztutar <enis.soz@gmail.com>
> >>> To: "dev@hbase.apache.org" <dev@hbase.apache.org>; lars hofhansl <
> >>> larsh@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 basicall=
y
> >>> 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 <larsh@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 <yuzhihong@gmail.com>
> >>>> To: dev@hbase.apache.org
> >>>> Cc: lars hofhansl <larsh@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 <apurtell@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 sur=
e
> >> it
> >>> got
> >>>>> committed there or (re)testing. That could be fine, I have no stron=
g
> >>>>> 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 <larsh@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 shou=
ld
> >>>>>> require a new jira.
> >>>>>>
> >>>>>> -- Lars
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> ----- Original Message -----
> >>>>>> From: Andrew Purtell <apurtell@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.george@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 i=
s
> >>>>> 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. - Pie=
t
> >>> Hein
> >>>>>> (via Tom White)
> >>>>>
> >>>>>
> >>>>> --
> >>>>> Best regards,
> >>>>>
> >>>>>   - Andy
> >>>>>
> >>>>> Problems worthy of attack prove their worth by hitting back. - Piet
> >> Hein
> >>>>> (via Tom White)
> >>
>

--047d7b343204e5534404e2b460d5--