hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stack <st...@duboce.net>
Subject Re: Resolved JIRAs
Date Mon, 29 Jul 2013 21:06:17 GMT
I can add whatever is decided here:
http://hbase.apache.org/book.html#decisions

There is already a related 'decision', how to mark versions.

St.Ack


On Mon, Jul 29, 2013 at 1:43 PM, Andrew Purtell <apurtell@apache.org> wrote:

> That was just my take on what it could be going forward, now that you bring
> it up, AFAIK it's been ad hoc and not necessarily that.
>
> On Mon, Jul 29, 2013 at 1:41 PM, Lars George <lars.george@gmail.com>
> wrote:
>
> > Hi Andy,
> >
> > OK, makes sense. Is that something defined somewhere, or more or less
> > common sense, or somehow passed on verbally only?
> >
> > Cheers,
> > Lars
> >
> > On Jul 29, 2013, at 9:19 PM, Andrew Purtell <apurtell@apache.org> wrote:
> >
> > > 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)
>

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