hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jesse Yates <jesse.k.ya...@gmail.com>
Subject Re: Resolved JIRAs
Date Tue, 30 Jul 2013 06:03:54 GMT
+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 écrit :
> >
> >> 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 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.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 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 <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
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 <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
should
> >>>>>> 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
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)
> >>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message