You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hbase.apache.org by Elliott Clark <ec...@apache.org> on 2013/02/08 00:15:41 UTC

0.94 Backports.

Lately there have been a lot of issues being committed to trunk and
also back-ported to 0.94 (I've done it myself too).  Since we're so far
into 0.94's release cycle should we think about not allowing minor features
and code clean ups to be back-ported ?

Re: 0.94 Backports.

Posted by lars hofhansl <la...@apache.org>.
+1 only after there is a stable 0.96 release.

Until such time 0.94 is the current stable release and minor backports and improvements should be OK.
Just my $0.02.

-- Lars



________________________________
 From: Jimmy Xiang <jx...@cloudera.com>
To: dev@hbase.apache.org 
Sent: Thursday, February 7, 2013 3:22 PM
Subject: Re: 0.94 Backports.
 
+1 after 0.96 branch is cut.

On Thu, Feb 7, 2013 at 3:15 PM, Elliott Clark <ec...@apache.org> wrote:

> Lately there have been a lot of issues being committed to trunk and
> also back-ported to 0.94 (I've done it myself too).  Since we're so far
> into 0.94's release cycle should we think about not allowing minor features
> and code clean ups to be back-ported ?
>

Re: 0.94 Backports.

Posted by Jimmy Xiang <jx...@cloudera.com>.
+1 after 0.96 branch is cut.

On Thu, Feb 7, 2013 at 3:15 PM, Elliott Clark <ec...@apache.org> wrote:

> Lately there have been a lot of issues being committed to trunk and
> also back-ported to 0.94 (I've done it myself too).  Since we're so far
> into 0.94's release cycle should we think about not allowing minor features
> and code clean ups to be back-ported ?
>

Re: 0.94 Backports.

Posted by Ted Yu <yu...@gmail.com>.
I already did that :-)

On Mon, Feb 11, 2013 at 4:38 PM, lars hofhansl <la...@apache.org> wrote:

> Commented on the jira... I'll revert.
>
>
>
> ________________________________
>  From: Jonathan Hsieh <jo...@cloudera.com>
> To: dev@hbase.apache.org
> Sent: Monday, February 11, 2013 4:24 PM
> Subject: Re: 0.94 Backports.
>
> Hey guys, I saw HBASE-7814 [1] -- a backport committed to 0.94 that
> makes HBase 0.94 now require Hadoop 1.0 (instead of the older
> hadoops).  This was supposed to be a new requirement for hbase 0.96.0.
> [2]
>
> Are we ok with making the next 0.94 upgrade incompatible?   (And if we
> are we need to release note this kind of stuff).
>
> Jon.
>
> [1] https://issues.apache.org/jira/browse/HBASE-7814
>
> [2]
> http://mail-archives.apache.org/mod_mbox/hbase-dev/201210.mbox/%3CCADcMMgHtqx73JztE4schY04iqs9NPZP3u84HM2SM7iCL6r80mQ@mail.gmail.com%3E
>
>
> On Fri, Feb 8, 2013 at 11:56 AM, Enis Söztutar <en...@gmail.com> wrote:
> > The backporting situation for 0.94 is an exception it seems, because of
> the
> > fact that 96 is so late. But until 96 comes out, we can keep up the
> current
> > approach. It has worked mostly for the time being.
> >
> > Enis
> >
> >
> > On Thu, Feb 7, 2013 at 5:20 PM, Andrew Purtell <ap...@apache.org>
> wrote:
> >
> >> That said, let's make sure every backport has meaningful justification
> >> (determined by consensus).
> >>
> >>
> >> On Thu, Feb 7, 2013 at 5:19 PM, Andrew Purtell <ap...@apache.org>
> >> wrote:
> >>
> >> > -1 until we have an actual stable 0.96 release.
> >> >
> >> >
> >> > On Thu, Feb 7, 2013 at 3:15 PM, Elliott Clark <ec...@apache.org>
> wrote:
> >> >
> >> >> Lately there have been a lot of issues being committed to trunk and
> >> >> also back-ported to 0.94 (I've done it myself too).  Since we're so
> far
> >> >> into 0.94's release cycle should we think about not allowing minor
> >> >> features
> >> >> and code clean ups to be back-ported ?
> >> >
> >> >
> >>
> >> --
> >> Best regards,
> >>
> >>    - Andy
> >>
> >> Problems worthy of attack prove their worth by hitting back. - Piet Hein
> >> (via Tom White)
> >>
>
>
>
> --
> // Jonathan Hsieh (shay)
> // Software Engineer, Cloudera
> // jon@cloudera.com
>

Re: 0.94 Backports.

Posted by Jonathan Hsieh <jo...@cloudera.com>.
Thanks guys.

Jon.

On Mon, Feb 11, 2013 at 4:38 PM, lars hofhansl <la...@apache.org> wrote:
> Commented on the jira... I'll revert.
>
>
>
> ________________________________
>  From: Jonathan Hsieh <jo...@cloudera.com>
> To: dev@hbase.apache.org
> Sent: Monday, February 11, 2013 4:24 PM
> Subject: Re: 0.94 Backports.
>
> Hey guys, I saw HBASE-7814 [1] -- a backport committed to 0.94 that
> makes HBase 0.94 now require Hadoop 1.0 (instead of the older
> hadoops).  This was supposed to be a new requirement for hbase 0.96.0.
> [2]
>
> Are we ok with making the next 0.94 upgrade incompatible?   (And if we
> are we need to release note this kind of stuff).
>
> Jon.
>
> [1] https://issues.apache.org/jira/browse/HBASE-7814
>
> [2] http://mail-archives.apache.org/mod_mbox/hbase-dev/201210.mbox/%3CCADcMMgHtqx73JztE4schY04iqs9NPZP3u84HM2SM7iCL6r80mQ@mail.gmail.com%3E
>
>
> On Fri, Feb 8, 2013 at 11:56 AM, Enis Söztutar <en...@gmail.com> wrote:
>> The backporting situation for 0.94 is an exception it seems, because of the
>> fact that 96 is so late. But until 96 comes out, we can keep up the current
>> approach. It has worked mostly for the time being.
>>
>> Enis
>>
>>
>> On Thu, Feb 7, 2013 at 5:20 PM, Andrew Purtell <ap...@apache.org> wrote:
>>
>>> That said, let's make sure every backport has meaningful justification
>>> (determined by consensus).
>>>
>>>
>>> On Thu, Feb 7, 2013 at 5:19 PM, Andrew Purtell <ap...@apache.org>
>>> wrote:
>>>
>>> > -1 until we have an actual stable 0.96 release.
>>> >
>>> >
>>> > On Thu, Feb 7, 2013 at 3:15 PM, Elliott Clark <ec...@apache.org> wrote:
>>> >
>>> >> Lately there have been a lot of issues being committed to trunk and
>>> >> also back-ported to 0.94 (I've done it myself too).  Since we're so far
>>> >> into 0.94's release cycle should we think about not allowing minor
>>> >> features
>>> >> and code clean ups to be back-ported ?
>>> >
>>> >
>>>
>>> --
>>> Best regards,
>>>
>>>    - Andy
>>>
>>> Problems worthy of attack prove their worth by hitting back. - Piet Hein
>>> (via Tom White)
>>>
>
>
>
> --
> // Jonathan Hsieh (shay)
> // Software Engineer, Cloudera
> // jon@cloudera.com



-- 
// Jonathan Hsieh (shay)
// Software Engineer, Cloudera
// jon@cloudera.com

Re: 0.94 Backports.

Posted by lars hofhansl <la...@apache.org>.
Commented on the jira... I'll revert.



________________________________
 From: Jonathan Hsieh <jo...@cloudera.com>
To: dev@hbase.apache.org 
Sent: Monday, February 11, 2013 4:24 PM
Subject: Re: 0.94 Backports.
 
Hey guys, I saw HBASE-7814 [1] -- a backport committed to 0.94 that
makes HBase 0.94 now require Hadoop 1.0 (instead of the older
hadoops).  This was supposed to be a new requirement for hbase 0.96.0.
[2]

Are we ok with making the next 0.94 upgrade incompatible?   (And if we
are we need to release note this kind of stuff).

Jon.

[1] https://issues.apache.org/jira/browse/HBASE-7814

[2] http://mail-archives.apache.org/mod_mbox/hbase-dev/201210.mbox/%3CCADcMMgHtqx73JztE4schY04iqs9NPZP3u84HM2SM7iCL6r80mQ@mail.gmail.com%3E


On Fri, Feb 8, 2013 at 11:56 AM, Enis Söztutar <en...@gmail.com> wrote:
> The backporting situation for 0.94 is an exception it seems, because of the
> fact that 96 is so late. But until 96 comes out, we can keep up the current
> approach. It has worked mostly for the time being.
>
> Enis
>
>
> On Thu, Feb 7, 2013 at 5:20 PM, Andrew Purtell <ap...@apache.org> wrote:
>
>> That said, let's make sure every backport has meaningful justification
>> (determined by consensus).
>>
>>
>> On Thu, Feb 7, 2013 at 5:19 PM, Andrew Purtell <ap...@apache.org>
>> wrote:
>>
>> > -1 until we have an actual stable 0.96 release.
>> >
>> >
>> > On Thu, Feb 7, 2013 at 3:15 PM, Elliott Clark <ec...@apache.org> wrote:
>> >
>> >> Lately there have been a lot of issues being committed to trunk and
>> >> also back-ported to 0.94 (I've done it myself too).  Since we're so far
>> >> into 0.94's release cycle should we think about not allowing minor
>> >> features
>> >> and code clean ups to be back-ported ?
>> >
>> >
>>
>> --
>> Best regards,
>>
>>    - Andy
>>
>> Problems worthy of attack prove their worth by hitting back. - Piet Hein
>> (via Tom White)
>>



-- 
// Jonathan Hsieh (shay)
// Software Engineer, Cloudera
// jon@cloudera.com

Re: 0.94 Backports.

Posted by Andrew Purtell <ap...@apache.org>.
I'm aware of the comment history and timeline Ted. This is a general
request to consider being a little more deliberate. I don't care about
litigating what may or may not happened on this issue, but I think you can
allow me to register my concern. Thank you.


On Mon, Feb 11, 2013 at 7:27 PM, Ted Yu <yu...@gmail.com> wrote:

> If you look at the comments in HBASE-7814, Lars' comment was logged at the
> same time as my notice of reversion:
>
>
> https://issues.apache.org/jira/browse/HBASE-7814?focusedCommentId=13576253&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13576253
>
> FYI
>
> On Mon, Feb 11, 2013 at 7:20 PM, Andrew Purtell <ap...@apache.org>
> wrote:
>
> > I'm also concerned that the revert happened here while discussion was
> > ongoing. Given the latest comments on the issue, this could have been
> > handled by a new issue that replaces the offending code with reflection.
> I
> > don't care about the revert per se but would ask we avoid making changes
> > out from under a discussion until the matter is resolved with consensus.
> We
> > will have cleaner revision history and less churn overall as a result. I
> > know many of us have to-do lists of HBase JIRAs to retire, but there is
> no
> > need to be hasty. Because we are all busy, unnecessary commit speed makes
> > it more likely mistakes like this will slip by review in the first place
> > too.
> >
> > For your consideration.
> >
> >
> > On Mon, Feb 11, 2013 at 5:40 PM, Ted <yu...@gmail.com> wrote:
> >
> > > No.
> > > The release was cut before the revert.
> > >
> > > On Feb 11, 2013, at 5:35 PM, Enis Söztutar <en...@gmail.com> wrote:
> > >
> > > > I was going to +1 the release, with the following checks I did:
> > > > - Checked md5 sums
> > > > - Checked gpg signature (gpg --verify )
> > > > - Checked included documentation book.html, etc.
> > > > - Running unit tests (passed on unsecure, secure)
> > > > - Started in local mode, run LoadTestTool
> > > > - integration tests (not working fully properly, but expected since
> > > > HBASE-7521 is not in yet)
> > > >
> > > > I guess this means that the release candidate has sunk, right?
> > > > Enis
> > > >
> > > >
> > > >
> > > > On Mon, Feb 11, 2013 at 4:59 PM, Stack <st...@duboce.net> wrote:
> > > >
> > > >> Good catch Jon.
> > > >>
> > > >> We need to be vigilant here all.
> > > >>
> > > >> Incompatibilities cost users and those following behind us as they
> > burn
> > > >> cycles doing gymnastics trying to get over the incompatibility -- if
> > it
> > > is
> > > >> possible to get over the incompatibility at all.  They make us look
> > bad.
> > > >> Worse, usually the incompatibility is found months later after we
> have
> > > all
> > > >> moved on and have long forgot what it was we committed (and even
> why)
> > so
> > > >> all the more reason to be on the look out at commit time.
> > > >>
> > > >> St.Ack
> > > >>
> > > >>
> > > >> On Mon, Feb 11, 2013 at 4:48 PM, Jonathan Hsieh <jo...@cloudera.com>
> > > wrote:
> > > >>
> > > >>> Apache Hat: What a particular vendor chooses to puts in its
> releases
> > > >>> shouldn't affect an Apache release and especially if we are
> breaking
> > > >>> the
> > > >>> project's versioning / compatibility rules.
> > > >>>
> > > >>> Jon.
> > > >>>
> > > >>> On Mon, Feb 11, 2013 at 4:32 PM, Ted Yu <yu...@gmail.com>
> wrote:
> > > >>>> I downloaded hadoop-0.20.2+737 from Cloudera website.
> > > >>>>
> > > >>>> I found getShortUserName() in UserGroupInformation
> > > >>>>
> > > >>>> Haven't checked other 0.20.x source code yet.
> > > >>>>
> > > >>>> FYI
> > > >>>>
> > > >>>> On Mon, Feb 11, 2013 at 4:24 PM, Jonathan Hsieh <jon@cloudera.com
> >
> > > >>> wrote:
> > > >>>>
> > > >>>>> Hey guys, I saw HBASE-7814 [1] -- a backport committed to 0.94
> that
> > > >>>>> makes HBase 0.94 now require Hadoop 1.0 (instead of the older
> > > >>>>> hadoops).  This was supposed to be a new requirement for hbase
> > > 0.96.0.
> > > >>>>> [2]
> > > >>>>>
> > > >>>>> Are we ok with making the next 0.94 upgrade incompatible?   (And
> if
> > > we
> > > >>>>> are we need to release note this kind of stuff).
> > > >>>>>
> > > >>>>> Jon.
> > > >>>>>
> > > >>>>> [1] https://issues.apache.org/jira/browse/HBASE-7814
> > > >>>>>
> > > >>>>> [2]
> > > >>
> > >
> >
> http://mail-archives.apache.org/mod_mbox/hbase-dev/201210.mbox/%3CCADcMMgHtqx73JztE4schY04iqs9NPZP3u84HM2SM7iCL6r80mQ@mail.gmail.com%3E
> > > >>>>>
> > > >>>>>
> > > >>>>> On Fri, Feb 8, 2013 at 11:56 AM, Enis Söztutar <
> enis.soz@gmail.com
> > >
> > > >>> wrote:
> > > >>>>>> The backporting situation for 0.94 is an exception it seems,
> > because
> > > >>> of
> > > >>>>> the
> > > >>>>>> fact that 96 is so late. But until 96 comes out, we can keep up
> > the
> > > >>>>> current
> > > >>>>>> approach. It has worked mostly for the time being.
> > > >>>>>>
> > > >>>>>> Enis
> > > >>>>>>
> > > >>>>>>
> > > >>>>>> On Thu, Feb 7, 2013 at 5:20 PM, Andrew Purtell <
> > apurtell@apache.org
> > > >>>
> > > >>>>> wrote:
> > > >>>>>>
> > > >>>>>>> That said, let's make sure every backport has meaningful
> > > >>> justification
> > > >>>>>>> (determined by consensus).
> > > >>>>>>>
> > > >>>>>>>
> > > >>>>>>> On Thu, Feb 7, 2013 at 5:19 PM, Andrew Purtell <
> > > >> apurtell@apache.org>
> > > >>>>>>> wrote:
> > > >>>>>>>
> > > >>>>>>>> -1 until we have an actual stable 0.96 release.
> > > >>>>>>>>
> > > >>>>>>>>
> > > >>>>>>>> On Thu, Feb 7, 2013 at 3:15 PM, Elliott Clark <
> > eclark@apache.org
> > > >>>
> > > >>>>> wrote:
> > > >>>>>>>>
> > > >>>>>>>>> Lately there have been a lot of issues being committed to
> trunk
> > > >>> and
> > > >>>>>>>>> also back-ported to 0.94 (I've done it myself too).  Since
> > we're
> > > >>> so
> > > >>>>> far
> > > >>>>>>>>> into 0.94's release cycle should we think about not allowing
> > > >> minor
> > > >>>>>>>>> features
> > > >>>>>>>>> and code clean ups to be back-ported ?
> > > >>>>>>>
> > > >>>>>>> --
> > > >>>>>>> Best regards,
> > > >>>>>>>
> > > >>>>>>>   - Andy
> > > >>>>>>>
> > > >>>>>>> Problems worthy of attack prove their worth by hitting back. -
> > Piet
> > > >>> Hein
> > > >>>>>>> (via Tom White)
> > > >>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>> --
> > > >>>>> // Jonathan Hsieh (shay)
> > > >>>>> // Software Engineer, Cloudera
> > > >>>>> // jon@cloudera.com
> > > >>>
> > > >>>
> > > >>>
> > > >>> --
> > > >>> // Jonathan Hsieh (shay)
> > > >>> // Software Engineer, Cloudera
> > > >>> // jon@cloudera.com
> > > >>
> > >
> >
> >
> >
> > --
> > 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)

Re: 0.94 Backports.

Posted by Ted Yu <yu...@gmail.com>.
If you look at the comments in HBASE-7814, Lars' comment was logged at the
same time as my notice of reversion:

https://issues.apache.org/jira/browse/HBASE-7814?focusedCommentId=13576253&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13576253

FYI

On Mon, Feb 11, 2013 at 7:20 PM, Andrew Purtell <ap...@apache.org> wrote:

> I'm also concerned that the revert happened here while discussion was
> ongoing. Given the latest comments on the issue, this could have been
> handled by a new issue that replaces the offending code with reflection. I
> don't care about the revert per se but would ask we avoid making changes
> out from under a discussion until the matter is resolved with consensus. We
> will have cleaner revision history and less churn overall as a result. I
> know many of us have to-do lists of HBase JIRAs to retire, but there is no
> need to be hasty. Because we are all busy, unnecessary commit speed makes
> it more likely mistakes like this will slip by review in the first place
> too.
>
> For your consideration.
>
>
> On Mon, Feb 11, 2013 at 5:40 PM, Ted <yu...@gmail.com> wrote:
>
> > No.
> > The release was cut before the revert.
> >
> > On Feb 11, 2013, at 5:35 PM, Enis Söztutar <en...@gmail.com> wrote:
> >
> > > I was going to +1 the release, with the following checks I did:
> > > - Checked md5 sums
> > > - Checked gpg signature (gpg --verify )
> > > - Checked included documentation book.html, etc.
> > > - Running unit tests (passed on unsecure, secure)
> > > - Started in local mode, run LoadTestTool
> > > - integration tests (not working fully properly, but expected since
> > > HBASE-7521 is not in yet)
> > >
> > > I guess this means that the release candidate has sunk, right?
> > > Enis
> > >
> > >
> > >
> > > On Mon, Feb 11, 2013 at 4:59 PM, Stack <st...@duboce.net> wrote:
> > >
> > >> Good catch Jon.
> > >>
> > >> We need to be vigilant here all.
> > >>
> > >> Incompatibilities cost users and those following behind us as they
> burn
> > >> cycles doing gymnastics trying to get over the incompatibility -- if
> it
> > is
> > >> possible to get over the incompatibility at all.  They make us look
> bad.
> > >> Worse, usually the incompatibility is found months later after we have
> > all
> > >> moved on and have long forgot what it was we committed (and even why)
> so
> > >> all the more reason to be on the look out at commit time.
> > >>
> > >> St.Ack
> > >>
> > >>
> > >> On Mon, Feb 11, 2013 at 4:48 PM, Jonathan Hsieh <jo...@cloudera.com>
> > wrote:
> > >>
> > >>> Apache Hat: What a particular vendor chooses to puts in its releases
> > >>> shouldn't affect an Apache release and especially if we are breaking
> > >>> the
> > >>> project's versioning / compatibility rules.
> > >>>
> > >>> Jon.
> > >>>
> > >>> On Mon, Feb 11, 2013 at 4:32 PM, Ted Yu <yu...@gmail.com> wrote:
> > >>>> I downloaded hadoop-0.20.2+737 from Cloudera website.
> > >>>>
> > >>>> I found getShortUserName() in UserGroupInformation
> > >>>>
> > >>>> Haven't checked other 0.20.x source code yet.
> > >>>>
> > >>>> FYI
> > >>>>
> > >>>> On Mon, Feb 11, 2013 at 4:24 PM, Jonathan Hsieh <jo...@cloudera.com>
> > >>> wrote:
> > >>>>
> > >>>>> Hey guys, I saw HBASE-7814 [1] -- a backport committed to 0.94 that
> > >>>>> makes HBase 0.94 now require Hadoop 1.0 (instead of the older
> > >>>>> hadoops).  This was supposed to be a new requirement for hbase
> > 0.96.0.
> > >>>>> [2]
> > >>>>>
> > >>>>> Are we ok with making the next 0.94 upgrade incompatible?   (And if
> > we
> > >>>>> are we need to release note this kind of stuff).
> > >>>>>
> > >>>>> Jon.
> > >>>>>
> > >>>>> [1] https://issues.apache.org/jira/browse/HBASE-7814
> > >>>>>
> > >>>>> [2]
> > >>
> >
> http://mail-archives.apache.org/mod_mbox/hbase-dev/201210.mbox/%3CCADcMMgHtqx73JztE4schY04iqs9NPZP3u84HM2SM7iCL6r80mQ@mail.gmail.com%3E
> > >>>>>
> > >>>>>
> > >>>>> On Fri, Feb 8, 2013 at 11:56 AM, Enis Söztutar <enis.soz@gmail.com
> >
> > >>> wrote:
> > >>>>>> The backporting situation for 0.94 is an exception it seems,
> because
> > >>> of
> > >>>>> the
> > >>>>>> fact that 96 is so late. But until 96 comes out, we can keep up
> the
> > >>>>> current
> > >>>>>> approach. It has worked mostly for the time being.
> > >>>>>>
> > >>>>>> Enis
> > >>>>>>
> > >>>>>>
> > >>>>>> On Thu, Feb 7, 2013 at 5:20 PM, Andrew Purtell <
> apurtell@apache.org
> > >>>
> > >>>>> wrote:
> > >>>>>>
> > >>>>>>> That said, let's make sure every backport has meaningful
> > >>> justification
> > >>>>>>> (determined by consensus).
> > >>>>>>>
> > >>>>>>>
> > >>>>>>> On Thu, Feb 7, 2013 at 5:19 PM, Andrew Purtell <
> > >> apurtell@apache.org>
> > >>>>>>> wrote:
> > >>>>>>>
> > >>>>>>>> -1 until we have an actual stable 0.96 release.
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>> On Thu, Feb 7, 2013 at 3:15 PM, Elliott Clark <
> eclark@apache.org
> > >>>
> > >>>>> wrote:
> > >>>>>>>>
> > >>>>>>>>> Lately there have been a lot of issues being committed to trunk
> > >>> and
> > >>>>>>>>> also back-ported to 0.94 (I've done it myself too).  Since
> we're
> > >>> so
> > >>>>> far
> > >>>>>>>>> into 0.94's release cycle should we think about not allowing
> > >> minor
> > >>>>>>>>> features
> > >>>>>>>>> and code clean ups to be back-ported ?
> > >>>>>>>
> > >>>>>>> --
> > >>>>>>> Best regards,
> > >>>>>>>
> > >>>>>>>   - Andy
> > >>>>>>>
> > >>>>>>> Problems worthy of attack prove their worth by hitting back. -
> Piet
> > >>> Hein
> > >>>>>>> (via Tom White)
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>> --
> > >>>>> // Jonathan Hsieh (shay)
> > >>>>> // Software Engineer, Cloudera
> > >>>>> // jon@cloudera.com
> > >>>
> > >>>
> > >>>
> > >>> --
> > >>> // Jonathan Hsieh (shay)
> > >>> // Software Engineer, Cloudera
> > >>> // jon@cloudera.com
> > >>
> >
>
>
>
> --
> Best regards,
>
>    - Andy
>
> Problems worthy of attack prove their worth by hitting back. - Piet Hein
> (via Tom White)
>

Re: 0.94 Backports.

Posted by lars hofhansl <la...@apache.org>.
If Ted hadn't reverted I would have done about 5 minutes later :)
Doesn't mean that was the right thing to do and you're right of course, we have to be deliberate.

On the other hand in a sense a revert *reduces* the commit speed.
We'll regroup and find a way via reflection, until then personally I prefer to leave the code in a releasable state, to minimize surprises.

-- Lars



----- Original Message -----
From: Andrew Purtell <ap...@apache.org>
To: "dev@hbase.apache.org" <de...@hbase.apache.org>
Cc: 
Sent: Monday, February 11, 2013 7:20 PM
Subject: Re: 0.94 Backports.

I'm also concerned that the revert happened here while discussion was
ongoing. Given the latest comments on the issue, this could have been
handled by a new issue that replaces the offending code with reflection. I
don't care about the revert per se but would ask we avoid making changes
out from under a discussion until the matter is resolved with consensus. We
will have cleaner revision history and less churn overall as a result. I
know many of us have to-do lists of HBase JIRAs to retire, but there is no
need to be hasty. Because we are all busy, unnecessary commit speed makes
it more likely mistakes like this will slip by review in the first place
too.

For your consideration.


On Mon, Feb 11, 2013 at 5:40 PM, Ted <yu...@gmail.com> wrote:

> No.
> The release was cut before the revert.
>
> On Feb 11, 2013, at 5:35 PM, Enis Söztutar <en...@gmail.com> wrote:
>
> > I was going to +1 the release, with the following checks I did:
> > - Checked md5 sums
> > - Checked gpg signature (gpg --verify )
> > - Checked included documentation book.html, etc.
> > - Running unit tests (passed on unsecure, secure)
> > - Started in local mode, run LoadTestTool
> > - integration tests (not working fully properly, but expected since
> > HBASE-7521 is not in yet)
> >
> > I guess this means that the release candidate has sunk, right?
> > Enis
> >
> >
> >
> > On Mon, Feb 11, 2013 at 4:59 PM, Stack <st...@duboce.net> wrote:
> >
> >> Good catch Jon.
> >>
> >> We need to be vigilant here all.
> >>
> >> Incompatibilities cost users and those following behind us as they burn
> >> cycles doing gymnastics trying to get over the incompatibility -- if it
> is
> >> possible to get over the incompatibility at all.  They make us look bad.
> >> Worse, usually the incompatibility is found months later after we have
> all
> >> moved on and have long forgot what it was we committed (and even why) so
> >> all the more reason to be on the look out at commit time.
> >>
> >> St.Ack
> >>
> >>
> >> On Mon, Feb 11, 2013 at 4:48 PM, Jonathan Hsieh <jo...@cloudera.com>
> wrote:
> >>
> >>> Apache Hat: What a particular vendor chooses to puts in its releases
> >>> shouldn't affect an Apache release and especially if we are breaking
> >>> the
> >>> project's versioning / compatibility rules.
> >>>
> >>> Jon.
> >>>
> >>> On Mon, Feb 11, 2013 at 4:32 PM, Ted Yu <yu...@gmail.com> wrote:
> >>>> I downloaded hadoop-0.20.2+737 from Cloudera website.
> >>>>
> >>>> I found getShortUserName() in UserGroupInformation
> >>>>
> >>>> Haven't checked other 0.20.x source code yet.
> >>>>
> >>>> FYI
> >>>>
> >>>> On Mon, Feb 11, 2013 at 4:24 PM, Jonathan Hsieh <jo...@cloudera.com>
> >>> wrote:
> >>>>
> >>>>> Hey guys, I saw HBASE-7814 [1] -- a backport committed to 0.94 that
> >>>>> makes HBase 0.94 now require Hadoop 1.0 (instead of the older
> >>>>> hadoops).  This was supposed to be a new requirement for hbase
> 0.96.0.
> >>>>> [2]
> >>>>>
> >>>>> Are we ok with making the next 0.94 upgrade incompatible?   (And if
> we
> >>>>> are we need to release note this kind of stuff).
> >>>>>
> >>>>> Jon.
> >>>>>
> >>>>> [1] https://issues.apache.org/jira/browse/HBASE-7814
> >>>>>
> >>>>> [2]
> >>
> http://mail-archives.apache.org/mod_mbox/hbase-dev/201210.mbox/%3CCADcMMgHtqx73JztE4schY04iqs9NPZP3u84HM2SM7iCL6r80mQ@mail.gmail.com%3E
> >>>>>
> >>>>>
> >>>>> On Fri, Feb 8, 2013 at 11:56 AM, Enis Söztutar <en...@gmail.com>
> >>> wrote:
> >>>>>> The backporting situation for 0.94 is an exception it seems, because
> >>> of
> >>>>> the
> >>>>>> fact that 96 is so late. But until 96 comes out, we can keep up the
> >>>>> current
> >>>>>> approach. It has worked mostly for the time being.
> >>>>>>
> >>>>>> Enis
> >>>>>>
> >>>>>>
> >>>>>> On Thu, Feb 7, 2013 at 5:20 PM, Andrew Purtell <apurtell@apache.org
> >>>
> >>>>> wrote:
> >>>>>>
> >>>>>>> That said, let's make sure every backport has meaningful
> >>> justification
> >>>>>>> (determined by consensus).
> >>>>>>>
> >>>>>>>
> >>>>>>> On Thu, Feb 7, 2013 at 5:19 PM, Andrew Purtell <
> >> apurtell@apache.org>
> >>>>>>> wrote:
> >>>>>>>
> >>>>>>>> -1 until we have an actual stable 0.96 release.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> On Thu, Feb 7, 2013 at 3:15 PM, Elliott Clark <eclark@apache.org
> >>>
> >>>>> wrote:
> >>>>>>>>
> >>>>>>>>> Lately there have been a lot of issues being committed to trunk
> >>> and
> >>>>>>>>> also back-ported to 0.94 (I've done it myself too).  Since we're
> >>> so
> >>>>> far
> >>>>>>>>> into 0.94's release cycle should we think about not allowing
> >> minor
> >>>>>>>>> features
> >>>>>>>>> and code clean ups to be back-ported ?
> >>>>>>>
> >>>>>>> --
> >>>>>>> Best regards,
> >>>>>>>
> >>>>>>>   - Andy
> >>>>>>>
> >>>>>>> Problems worthy of attack prove their worth by hitting back. - Piet
> >>> Hein
> >>>>>>> (via Tom White)
> >>>>>
> >>>>>
> >>>>>
> >>>>> --
> >>>>> // Jonathan Hsieh (shay)
> >>>>> // Software Engineer, Cloudera
> >>>>> // jon@cloudera.com
> >>>
> >>>
> >>>
> >>> --
> >>> // Jonathan Hsieh (shay)
> >>> // Software Engineer, Cloudera
> >>> // jon@cloudera.com
> >>
>



-- 
Best regards,

   - Andy

Problems worthy of attack prove their worth by hitting back. - Piet Hein
(via Tom White)


Re: 0.94 Backports.

Posted by Andrew Purtell <ap...@apache.org>.
No that's not the point either, but never mind, either I'm not being clear,
or it's only me.


On Mon, Feb 11, 2013 at 7:45 PM, Jonathan Hsieh <jo...@cloudera.com> wrote:

> Sorry if I misinterpreted.  If it was commit speed is the concern I
> generally agree -- but this patch had a +1 from one of the owners
> (jimmy) so committing it wasn't unreasonable.  I think the bigger
> point is that we need to be more vigilant about compatibility,
> especially with late point releases.
>
> Jon.
>
> On Mon, Feb 11, 2013 at 7:36 PM, Andrew Purtell <ap...@apache.org>
> wrote:
> > I didn't say the revert is not reasonable.
> >
> >
> >
> > On Mon, Feb 11, 2013 at 7:32 PM, Jonathan Hsieh <jo...@cloudera.com>
> wrote:
> >
> >> Andrew,
> >>
> >> I agree if a new patch under discussion and a commit was made -- bad
> >> form to commit.
> >>
> >> However, a revert within 24 hours seems reasonable, especially if done
> >> by the original committer.   A revert is done to undo harm (failed
> >> build, massive test failures, or serious bug found with nontrivial
> >> effort to repair).
> >>
> >> Personally, I'd rather have a bad commit, a revert and then a single
> >> clean commit (even if this last one came a few days later) instead of
> >> a bad commit, and then a series of addendums that come a few days
> >> later.
> >>
> >> Jon.
> >>
> >> On Mon, Feb 11, 2013 at 7:20 PM, Andrew Purtell <ap...@apache.org>
> >> wrote:
> >> > I'm also concerned that the revert happened here while discussion was
> >> > ongoing. Given the latest comments on the issue, this could have been
> >> > handled by a new issue that replaces the offending code with
> reflection.
> >> I
> >> > don't care about the revert per se but would ask we avoid making
> changes
> >> > out from under a discussion until the matter is resolved with
> consensus.
> >> We
> >> > will have cleaner revision history and less churn overall as a
> result. I
> >> > know many of us have to-do lists of HBase JIRAs to retire, but there
> is
> >> no
> >> > need to be hasty. Because we are all busy, unnecessary commit speed
> makes
> >> > it more likely mistakes like this will slip by review in the first
> place
> >> > too.
> >> >
> >> > For your consideration.
> >> >
> >> >
> >> > On Mon, Feb 11, 2013 at 5:40 PM, Ted <yu...@gmail.com> wrote:
> >> >
> >> >> No.
> >> >> The release was cut before the revert.
> >> >>
> >> >> On Feb 11, 2013, at 5:35 PM, Enis Söztutar <en...@gmail.com>
> wrote:
> >> >>
> >> >> > I was going to +1 the release, with the following checks I did:
> >> >> > - Checked md5 sums
> >> >> > - Checked gpg signature (gpg --verify )
> >> >> > - Checked included documentation book.html, etc.
> >> >> > - Running unit tests (passed on unsecure, secure)
> >> >> > - Started in local mode, run LoadTestTool
> >> >> > - integration tests (not working fully properly, but expected since
> >> >> > HBASE-7521 is not in yet)
> >> >> >
> >> >> > I guess this means that the release candidate has sunk, right?
> >> >> > Enis
> >> >> >
> >> >> >
> >> >> >
> >> >> > On Mon, Feb 11, 2013 at 4:59 PM, Stack <st...@duboce.net> wrote:
> >> >> >
> >> >> >> Good catch Jon.
> >> >> >>
> >> >> >> We need to be vigilant here all.
> >> >> >>
> >> >> >> Incompatibilities cost users and those following behind us as they
> >> burn
> >> >> >> cycles doing gymnastics trying to get over the incompatibility --
> if
> >> it
> >> >> is
> >> >> >> possible to get over the incompatibility at all.  They make us
> look
> >> bad.
> >> >> >> Worse, usually the incompatibility is found months later after we
> >> have
> >> >> all
> >> >> >> moved on and have long forgot what it was we committed (and even
> >> why) so
> >> >> >> all the more reason to be on the look out at commit time.
> >> >> >>
> >> >> >> St.Ack
> >> >> >>
> >> >> >>
> >> >> >> On Mon, Feb 11, 2013 at 4:48 PM, Jonathan Hsieh <jon@cloudera.com
> >
> >> >> wrote:
> >> >> >>
> >> >> >>> Apache Hat: What a particular vendor chooses to puts in its
> releases
> >> >> >>> shouldn't affect an Apache release and especially if we are
> breaking
> >> >> >>> the
> >> >> >>> project's versioning / compatibility rules.
> >> >> >>>
> >> >> >>> Jon.
> >> >> >>>
> >> >> >>> On Mon, Feb 11, 2013 at 4:32 PM, Ted Yu <yu...@gmail.com>
> >> wrote:
> >> >> >>>> I downloaded hadoop-0.20.2+737 from Cloudera website.
> >> >> >>>>
> >> >> >>>> I found getShortUserName() in UserGroupInformation
> >> >> >>>>
> >> >> >>>> Haven't checked other 0.20.x source code yet.
> >> >> >>>>
> >> >> >>>> FYI
> >> >> >>>>
> >> >> >>>> On Mon, Feb 11, 2013 at 4:24 PM, Jonathan Hsieh <
> jon@cloudera.com>
> >> >> >>> wrote:
> >> >> >>>>
> >> >> >>>>> Hey guys, I saw HBASE-7814 [1] -- a backport committed to 0.94
> >> that
> >> >> >>>>> makes HBase 0.94 now require Hadoop 1.0 (instead of the older
> >> >> >>>>> hadoops).  This was supposed to be a new requirement for hbase
> >> >> 0.96.0.
> >> >> >>>>> [2]
> >> >> >>>>>
> >> >> >>>>> Are we ok with making the next 0.94 upgrade incompatible?
> (And
> >> if
> >> >> we
> >> >> >>>>> are we need to release note this kind of stuff).
> >> >> >>>>>
> >> >> >>>>> Jon.
> >> >> >>>>>
> >> >> >>>>> [1] https://issues.apache.org/jira/browse/HBASE-7814
> >> >> >>>>>
> >> >> >>>>> [2]
> >> >> >>
> >> >>
> >>
> http://mail-archives.apache.org/mod_mbox/hbase-dev/201210.mbox/%3CCADcMMgHtqx73JztE4schY04iqs9NPZP3u84HM2SM7iCL6r80mQ@mail.gmail.com%3E
> >> >> >>>>>
> >> >> >>>>>
> >> >> >>>>> On Fri, Feb 8, 2013 at 11:56 AM, Enis Söztutar <
> >> enis.soz@gmail.com>
> >> >> >>> wrote:
> >> >> >>>>>> The backporting situation for 0.94 is an exception it seems,
> >> because
> >> >> >>> of
> >> >> >>>>> the
> >> >> >>>>>> fact that 96 is so late. But until 96 comes out, we can keep
> up
> >> the
> >> >> >>>>> current
> >> >> >>>>>> approach. It has worked mostly for the time being.
> >> >> >>>>>>
> >> >> >>>>>> Enis
> >> >> >>>>>>
> >> >> >>>>>>
> >> >> >>>>>> On Thu, Feb 7, 2013 at 5:20 PM, Andrew Purtell <
> >> apurtell@apache.org
> >> >> >>>
> >> >> >>>>> wrote:
> >> >> >>>>>>
> >> >> >>>>>>> That said, let's make sure every backport has meaningful
> >> >> >>> justification
> >> >> >>>>>>> (determined by consensus).
> >> >> >>>>>>>
> >> >> >>>>>>>
> >> >> >>>>>>> On Thu, Feb 7, 2013 at 5:19 PM, Andrew Purtell <
> >> >> >> apurtell@apache.org>
> >> >> >>>>>>> wrote:
> >> >> >>>>>>>
> >> >> >>>>>>>> -1 until we have an actual stable 0.96 release.
> >> >> >>>>>>>>
> >> >> >>>>>>>>
> >> >> >>>>>>>> On Thu, Feb 7, 2013 at 3:15 PM, Elliott Clark <
> >> eclark@apache.org
> >> >> >>>
> >> >> >>>>> wrote:
> >> >> >>>>>>>>
> >> >> >>>>>>>>> Lately there have been a lot of issues being committed to
> >> trunk
> >> >> >>> and
> >> >> >>>>>>>>> also back-ported to 0.94 (I've done it myself too).  Since
> >> we're
> >> >> >>> so
> >> >> >>>>> far
> >> >> >>>>>>>>> into 0.94's release cycle should we think about not
> allowing
> >> >> >> minor
> >> >> >>>>>>>>> features
> >> >> >>>>>>>>> and code clean ups to be back-ported ?
> >> >> >>>>>>>
> >> >> >>>>>>> --
> >> >> >>>>>>> Best regards,
> >> >> >>>>>>>
> >> >> >>>>>>>   - Andy
> >> >> >>>>>>>
> >> >> >>>>>>> Problems worthy of attack prove their worth by hitting back.
> -
> >> Piet
> >> >> >>> Hein
> >> >> >>>>>>> (via Tom White)
> >> >> >>>>>
> >> >> >>>>>
> >> >> >>>>>
> >> >> >>>>> --
> >> >> >>>>> // Jonathan Hsieh (shay)
> >> >> >>>>> // Software Engineer, Cloudera
> >> >> >>>>> // jon@cloudera.com
> >> >> >>>
> >> >> >>>
> >> >> >>>
> >> >> >>> --
> >> >> >>> // Jonathan Hsieh (shay)
> >> >> >>> // Software Engineer, Cloudera
> >> >> >>> // jon@cloudera.com
> >> >> >>
> >> >>
> >> >
> >> >
> >> >
> >> > --
> >> > Best regards,
> >> >
> >> >    - Andy
> >> >
> >> > Problems worthy of attack prove their worth by hitting back. - Piet
> Hein
> >> > (via Tom White)
> >>
> >>
> >>
> >> --
> >> // Jonathan Hsieh (shay)
> >> // Software Engineer, Cloudera
> >> // jon@cloudera.com
> >>
> >
> >
> >
> > --
> > Best regards,
> >
> >    - Andy
> >
> > Problems worthy of attack prove their worth by hitting back. - Piet Hein
> > (via Tom White)
>
>
>
> --
> // Jonathan Hsieh (shay)
> // Software Engineer, Cloudera
> // jon@cloudera.com
>



-- 
Best regards,

   - Andy

Problems worthy of attack prove their worth by hitting back. - Piet Hein
(via Tom White)

Re: 0.94 Backports.

Posted by Jonathan Hsieh <jo...@cloudera.com>.
Sorry if I misinterpreted.  If it was commit speed is the concern I
generally agree -- but this patch had a +1 from one of the owners
(jimmy) so committing it wasn't unreasonable.  I think the bigger
point is that we need to be more vigilant about compatibility,
especially with late point releases.

Jon.

On Mon, Feb 11, 2013 at 7:36 PM, Andrew Purtell <ap...@apache.org> wrote:
> I didn't say the revert is not reasonable.
>
>
>
> On Mon, Feb 11, 2013 at 7:32 PM, Jonathan Hsieh <jo...@cloudera.com> wrote:
>
>> Andrew,
>>
>> I agree if a new patch under discussion and a commit was made -- bad
>> form to commit.
>>
>> However, a revert within 24 hours seems reasonable, especially if done
>> by the original committer.   A revert is done to undo harm (failed
>> build, massive test failures, or serious bug found with nontrivial
>> effort to repair).
>>
>> Personally, I'd rather have a bad commit, a revert and then a single
>> clean commit (even if this last one came a few days later) instead of
>> a bad commit, and then a series of addendums that come a few days
>> later.
>>
>> Jon.
>>
>> On Mon, Feb 11, 2013 at 7:20 PM, Andrew Purtell <ap...@apache.org>
>> wrote:
>> > I'm also concerned that the revert happened here while discussion was
>> > ongoing. Given the latest comments on the issue, this could have been
>> > handled by a new issue that replaces the offending code with reflection.
>> I
>> > don't care about the revert per se but would ask we avoid making changes
>> > out from under a discussion until the matter is resolved with consensus.
>> We
>> > will have cleaner revision history and less churn overall as a result. I
>> > know many of us have to-do lists of HBase JIRAs to retire, but there is
>> no
>> > need to be hasty. Because we are all busy, unnecessary commit speed makes
>> > it more likely mistakes like this will slip by review in the first place
>> > too.
>> >
>> > For your consideration.
>> >
>> >
>> > On Mon, Feb 11, 2013 at 5:40 PM, Ted <yu...@gmail.com> wrote:
>> >
>> >> No.
>> >> The release was cut before the revert.
>> >>
>> >> On Feb 11, 2013, at 5:35 PM, Enis Söztutar <en...@gmail.com> wrote:
>> >>
>> >> > I was going to +1 the release, with the following checks I did:
>> >> > - Checked md5 sums
>> >> > - Checked gpg signature (gpg --verify )
>> >> > - Checked included documentation book.html, etc.
>> >> > - Running unit tests (passed on unsecure, secure)
>> >> > - Started in local mode, run LoadTestTool
>> >> > - integration tests (not working fully properly, but expected since
>> >> > HBASE-7521 is not in yet)
>> >> >
>> >> > I guess this means that the release candidate has sunk, right?
>> >> > Enis
>> >> >
>> >> >
>> >> >
>> >> > On Mon, Feb 11, 2013 at 4:59 PM, Stack <st...@duboce.net> wrote:
>> >> >
>> >> >> Good catch Jon.
>> >> >>
>> >> >> We need to be vigilant here all.
>> >> >>
>> >> >> Incompatibilities cost users and those following behind us as they
>> burn
>> >> >> cycles doing gymnastics trying to get over the incompatibility -- if
>> it
>> >> is
>> >> >> possible to get over the incompatibility at all.  They make us look
>> bad.
>> >> >> Worse, usually the incompatibility is found months later after we
>> have
>> >> all
>> >> >> moved on and have long forgot what it was we committed (and even
>> why) so
>> >> >> all the more reason to be on the look out at commit time.
>> >> >>
>> >> >> St.Ack
>> >> >>
>> >> >>
>> >> >> On Mon, Feb 11, 2013 at 4:48 PM, Jonathan Hsieh <jo...@cloudera.com>
>> >> wrote:
>> >> >>
>> >> >>> Apache Hat: What a particular vendor chooses to puts in its releases
>> >> >>> shouldn't affect an Apache release and especially if we are breaking
>> >> >>> the
>> >> >>> project's versioning / compatibility rules.
>> >> >>>
>> >> >>> Jon.
>> >> >>>
>> >> >>> On Mon, Feb 11, 2013 at 4:32 PM, Ted Yu <yu...@gmail.com>
>> wrote:
>> >> >>>> I downloaded hadoop-0.20.2+737 from Cloudera website.
>> >> >>>>
>> >> >>>> I found getShortUserName() in UserGroupInformation
>> >> >>>>
>> >> >>>> Haven't checked other 0.20.x source code yet.
>> >> >>>>
>> >> >>>> FYI
>> >> >>>>
>> >> >>>> On Mon, Feb 11, 2013 at 4:24 PM, Jonathan Hsieh <jo...@cloudera.com>
>> >> >>> wrote:
>> >> >>>>
>> >> >>>>> Hey guys, I saw HBASE-7814 [1] -- a backport committed to 0.94
>> that
>> >> >>>>> makes HBase 0.94 now require Hadoop 1.0 (instead of the older
>> >> >>>>> hadoops).  This was supposed to be a new requirement for hbase
>> >> 0.96.0.
>> >> >>>>> [2]
>> >> >>>>>
>> >> >>>>> Are we ok with making the next 0.94 upgrade incompatible?   (And
>> if
>> >> we
>> >> >>>>> are we need to release note this kind of stuff).
>> >> >>>>>
>> >> >>>>> Jon.
>> >> >>>>>
>> >> >>>>> [1] https://issues.apache.org/jira/browse/HBASE-7814
>> >> >>>>>
>> >> >>>>> [2]
>> >> >>
>> >>
>> http://mail-archives.apache.org/mod_mbox/hbase-dev/201210.mbox/%3CCADcMMgHtqx73JztE4schY04iqs9NPZP3u84HM2SM7iCL6r80mQ@mail.gmail.com%3E
>> >> >>>>>
>> >> >>>>>
>> >> >>>>> On Fri, Feb 8, 2013 at 11:56 AM, Enis Söztutar <
>> enis.soz@gmail.com>
>> >> >>> wrote:
>> >> >>>>>> The backporting situation for 0.94 is an exception it seems,
>> because
>> >> >>> of
>> >> >>>>> the
>> >> >>>>>> fact that 96 is so late. But until 96 comes out, we can keep up
>> the
>> >> >>>>> current
>> >> >>>>>> approach. It has worked mostly for the time being.
>> >> >>>>>>
>> >> >>>>>> Enis
>> >> >>>>>>
>> >> >>>>>>
>> >> >>>>>> On Thu, Feb 7, 2013 at 5:20 PM, Andrew Purtell <
>> apurtell@apache.org
>> >> >>>
>> >> >>>>> wrote:
>> >> >>>>>>
>> >> >>>>>>> That said, let's make sure every backport has meaningful
>> >> >>> justification
>> >> >>>>>>> (determined by consensus).
>> >> >>>>>>>
>> >> >>>>>>>
>> >> >>>>>>> On Thu, Feb 7, 2013 at 5:19 PM, Andrew Purtell <
>> >> >> apurtell@apache.org>
>> >> >>>>>>> wrote:
>> >> >>>>>>>
>> >> >>>>>>>> -1 until we have an actual stable 0.96 release.
>> >> >>>>>>>>
>> >> >>>>>>>>
>> >> >>>>>>>> On Thu, Feb 7, 2013 at 3:15 PM, Elliott Clark <
>> eclark@apache.org
>> >> >>>
>> >> >>>>> wrote:
>> >> >>>>>>>>
>> >> >>>>>>>>> Lately there have been a lot of issues being committed to
>> trunk
>> >> >>> and
>> >> >>>>>>>>> also back-ported to 0.94 (I've done it myself too).  Since
>> we're
>> >> >>> so
>> >> >>>>> far
>> >> >>>>>>>>> into 0.94's release cycle should we think about not allowing
>> >> >> minor
>> >> >>>>>>>>> features
>> >> >>>>>>>>> and code clean ups to be back-ported ?
>> >> >>>>>>>
>> >> >>>>>>> --
>> >> >>>>>>> Best regards,
>> >> >>>>>>>
>> >> >>>>>>>   - Andy
>> >> >>>>>>>
>> >> >>>>>>> Problems worthy of attack prove their worth by hitting back. -
>> Piet
>> >> >>> Hein
>> >> >>>>>>> (via Tom White)
>> >> >>>>>
>> >> >>>>>
>> >> >>>>>
>> >> >>>>> --
>> >> >>>>> // Jonathan Hsieh (shay)
>> >> >>>>> // Software Engineer, Cloudera
>> >> >>>>> // jon@cloudera.com
>> >> >>>
>> >> >>>
>> >> >>>
>> >> >>> --
>> >> >>> // Jonathan Hsieh (shay)
>> >> >>> // Software Engineer, Cloudera
>> >> >>> // jon@cloudera.com
>> >> >>
>> >>
>> >
>> >
>> >
>> > --
>> > Best regards,
>> >
>> >    - Andy
>> >
>> > Problems worthy of attack prove their worth by hitting back. - Piet Hein
>> > (via Tom White)
>>
>>
>>
>> --
>> // Jonathan Hsieh (shay)
>> // Software Engineer, Cloudera
>> // jon@cloudera.com
>>
>
>
>
> --
> Best regards,
>
>    - Andy
>
> Problems worthy of attack prove their worth by hitting back. - Piet Hein
> (via Tom White)



-- 
// Jonathan Hsieh (shay)
// Software Engineer, Cloudera
// jon@cloudera.com

Re: 0.94 Backports.

Posted by Andrew Purtell <ap...@apache.org>.
I didn't say the revert is not reasonable.



On Mon, Feb 11, 2013 at 7:32 PM, Jonathan Hsieh <jo...@cloudera.com> wrote:

> Andrew,
>
> I agree if a new patch under discussion and a commit was made -- bad
> form to commit.
>
> However, a revert within 24 hours seems reasonable, especially if done
> by the original committer.   A revert is done to undo harm (failed
> build, massive test failures, or serious bug found with nontrivial
> effort to repair).
>
> Personally, I'd rather have a bad commit, a revert and then a single
> clean commit (even if this last one came a few days later) instead of
> a bad commit, and then a series of addendums that come a few days
> later.
>
> Jon.
>
> On Mon, Feb 11, 2013 at 7:20 PM, Andrew Purtell <ap...@apache.org>
> wrote:
> > I'm also concerned that the revert happened here while discussion was
> > ongoing. Given the latest comments on the issue, this could have been
> > handled by a new issue that replaces the offending code with reflection.
> I
> > don't care about the revert per se but would ask we avoid making changes
> > out from under a discussion until the matter is resolved with consensus.
> We
> > will have cleaner revision history and less churn overall as a result. I
> > know many of us have to-do lists of HBase JIRAs to retire, but there is
> no
> > need to be hasty. Because we are all busy, unnecessary commit speed makes
> > it more likely mistakes like this will slip by review in the first place
> > too.
> >
> > For your consideration.
> >
> >
> > On Mon, Feb 11, 2013 at 5:40 PM, Ted <yu...@gmail.com> wrote:
> >
> >> No.
> >> The release was cut before the revert.
> >>
> >> On Feb 11, 2013, at 5:35 PM, Enis Söztutar <en...@gmail.com> wrote:
> >>
> >> > I was going to +1 the release, with the following checks I did:
> >> > - Checked md5 sums
> >> > - Checked gpg signature (gpg --verify )
> >> > - Checked included documentation book.html, etc.
> >> > - Running unit tests (passed on unsecure, secure)
> >> > - Started in local mode, run LoadTestTool
> >> > - integration tests (not working fully properly, but expected since
> >> > HBASE-7521 is not in yet)
> >> >
> >> > I guess this means that the release candidate has sunk, right?
> >> > Enis
> >> >
> >> >
> >> >
> >> > On Mon, Feb 11, 2013 at 4:59 PM, Stack <st...@duboce.net> wrote:
> >> >
> >> >> Good catch Jon.
> >> >>
> >> >> We need to be vigilant here all.
> >> >>
> >> >> Incompatibilities cost users and those following behind us as they
> burn
> >> >> cycles doing gymnastics trying to get over the incompatibility -- if
> it
> >> is
> >> >> possible to get over the incompatibility at all.  They make us look
> bad.
> >> >> Worse, usually the incompatibility is found months later after we
> have
> >> all
> >> >> moved on and have long forgot what it was we committed (and even
> why) so
> >> >> all the more reason to be on the look out at commit time.
> >> >>
> >> >> St.Ack
> >> >>
> >> >>
> >> >> On Mon, Feb 11, 2013 at 4:48 PM, Jonathan Hsieh <jo...@cloudera.com>
> >> wrote:
> >> >>
> >> >>> Apache Hat: What a particular vendor chooses to puts in its releases
> >> >>> shouldn't affect an Apache release and especially if we are breaking
> >> >>> the
> >> >>> project's versioning / compatibility rules.
> >> >>>
> >> >>> Jon.
> >> >>>
> >> >>> On Mon, Feb 11, 2013 at 4:32 PM, Ted Yu <yu...@gmail.com>
> wrote:
> >> >>>> I downloaded hadoop-0.20.2+737 from Cloudera website.
> >> >>>>
> >> >>>> I found getShortUserName() in UserGroupInformation
> >> >>>>
> >> >>>> Haven't checked other 0.20.x source code yet.
> >> >>>>
> >> >>>> FYI
> >> >>>>
> >> >>>> On Mon, Feb 11, 2013 at 4:24 PM, Jonathan Hsieh <jo...@cloudera.com>
> >> >>> wrote:
> >> >>>>
> >> >>>>> Hey guys, I saw HBASE-7814 [1] -- a backport committed to 0.94
> that
> >> >>>>> makes HBase 0.94 now require Hadoop 1.0 (instead of the older
> >> >>>>> hadoops).  This was supposed to be a new requirement for hbase
> >> 0.96.0.
> >> >>>>> [2]
> >> >>>>>
> >> >>>>> Are we ok with making the next 0.94 upgrade incompatible?   (And
> if
> >> we
> >> >>>>> are we need to release note this kind of stuff).
> >> >>>>>
> >> >>>>> Jon.
> >> >>>>>
> >> >>>>> [1] https://issues.apache.org/jira/browse/HBASE-7814
> >> >>>>>
> >> >>>>> [2]
> >> >>
> >>
> http://mail-archives.apache.org/mod_mbox/hbase-dev/201210.mbox/%3CCADcMMgHtqx73JztE4schY04iqs9NPZP3u84HM2SM7iCL6r80mQ@mail.gmail.com%3E
> >> >>>>>
> >> >>>>>
> >> >>>>> On Fri, Feb 8, 2013 at 11:56 AM, Enis Söztutar <
> enis.soz@gmail.com>
> >> >>> wrote:
> >> >>>>>> The backporting situation for 0.94 is an exception it seems,
> because
> >> >>> of
> >> >>>>> the
> >> >>>>>> fact that 96 is so late. But until 96 comes out, we can keep up
> the
> >> >>>>> current
> >> >>>>>> approach. It has worked mostly for the time being.
> >> >>>>>>
> >> >>>>>> Enis
> >> >>>>>>
> >> >>>>>>
> >> >>>>>> On Thu, Feb 7, 2013 at 5:20 PM, Andrew Purtell <
> apurtell@apache.org
> >> >>>
> >> >>>>> wrote:
> >> >>>>>>
> >> >>>>>>> That said, let's make sure every backport has meaningful
> >> >>> justification
> >> >>>>>>> (determined by consensus).
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>> On Thu, Feb 7, 2013 at 5:19 PM, Andrew Purtell <
> >> >> apurtell@apache.org>
> >> >>>>>>> wrote:
> >> >>>>>>>
> >> >>>>>>>> -1 until we have an actual stable 0.96 release.
> >> >>>>>>>>
> >> >>>>>>>>
> >> >>>>>>>> On Thu, Feb 7, 2013 at 3:15 PM, Elliott Clark <
> eclark@apache.org
> >> >>>
> >> >>>>> wrote:
> >> >>>>>>>>
> >> >>>>>>>>> Lately there have been a lot of issues being committed to
> trunk
> >> >>> and
> >> >>>>>>>>> also back-ported to 0.94 (I've done it myself too).  Since
> we're
> >> >>> so
> >> >>>>> far
> >> >>>>>>>>> into 0.94's release cycle should we think about not allowing
> >> >> minor
> >> >>>>>>>>> features
> >> >>>>>>>>> and code clean ups to be back-ported ?
> >> >>>>>>>
> >> >>>>>>> --
> >> >>>>>>> Best regards,
> >> >>>>>>>
> >> >>>>>>>   - Andy
> >> >>>>>>>
> >> >>>>>>> Problems worthy of attack prove their worth by hitting back. -
> Piet
> >> >>> Hein
> >> >>>>>>> (via Tom White)
> >> >>>>>
> >> >>>>>
> >> >>>>>
> >> >>>>> --
> >> >>>>> // Jonathan Hsieh (shay)
> >> >>>>> // Software Engineer, Cloudera
> >> >>>>> // jon@cloudera.com
> >> >>>
> >> >>>
> >> >>>
> >> >>> --
> >> >>> // Jonathan Hsieh (shay)
> >> >>> // Software Engineer, Cloudera
> >> >>> // jon@cloudera.com
> >> >>
> >>
> >
> >
> >
> > --
> > Best regards,
> >
> >    - Andy
> >
> > Problems worthy of attack prove their worth by hitting back. - Piet Hein
> > (via Tom White)
>
>
>
> --
> // Jonathan Hsieh (shay)
> // Software Engineer, Cloudera
> // jon@cloudera.com
>



-- 
Best regards,

   - Andy

Problems worthy of attack prove their worth by hitting back. - Piet Hein
(via Tom White)

Re: 0.94 Backports.

Posted by Jonathan Hsieh <jo...@cloudera.com>.
Andrew,

I agree if a new patch under discussion and a commit was made -- bad
form to commit.

However, a revert within 24 hours seems reasonable, especially if done
by the original committer.   A revert is done to undo harm (failed
build, massive test failures, or serious bug found with nontrivial
effort to repair).

Personally, I'd rather have a bad commit, a revert and then a single
clean commit (even if this last one came a few days later) instead of
a bad commit, and then a series of addendums that come a few days
later.

Jon.

On Mon, Feb 11, 2013 at 7:20 PM, Andrew Purtell <ap...@apache.org> wrote:
> I'm also concerned that the revert happened here while discussion was
> ongoing. Given the latest comments on the issue, this could have been
> handled by a new issue that replaces the offending code with reflection. I
> don't care about the revert per se but would ask we avoid making changes
> out from under a discussion until the matter is resolved with consensus. We
> will have cleaner revision history and less churn overall as a result. I
> know many of us have to-do lists of HBase JIRAs to retire, but there is no
> need to be hasty. Because we are all busy, unnecessary commit speed makes
> it more likely mistakes like this will slip by review in the first place
> too.
>
> For your consideration.
>
>
> On Mon, Feb 11, 2013 at 5:40 PM, Ted <yu...@gmail.com> wrote:
>
>> No.
>> The release was cut before the revert.
>>
>> On Feb 11, 2013, at 5:35 PM, Enis Söztutar <en...@gmail.com> wrote:
>>
>> > I was going to +1 the release, with the following checks I did:
>> > - Checked md5 sums
>> > - Checked gpg signature (gpg --verify )
>> > - Checked included documentation book.html, etc.
>> > - Running unit tests (passed on unsecure, secure)
>> > - Started in local mode, run LoadTestTool
>> > - integration tests (not working fully properly, but expected since
>> > HBASE-7521 is not in yet)
>> >
>> > I guess this means that the release candidate has sunk, right?
>> > Enis
>> >
>> >
>> >
>> > On Mon, Feb 11, 2013 at 4:59 PM, Stack <st...@duboce.net> wrote:
>> >
>> >> Good catch Jon.
>> >>
>> >> We need to be vigilant here all.
>> >>
>> >> Incompatibilities cost users and those following behind us as they burn
>> >> cycles doing gymnastics trying to get over the incompatibility -- if it
>> is
>> >> possible to get over the incompatibility at all.  They make us look bad.
>> >> Worse, usually the incompatibility is found months later after we have
>> all
>> >> moved on and have long forgot what it was we committed (and even why) so
>> >> all the more reason to be on the look out at commit time.
>> >>
>> >> St.Ack
>> >>
>> >>
>> >> On Mon, Feb 11, 2013 at 4:48 PM, Jonathan Hsieh <jo...@cloudera.com>
>> wrote:
>> >>
>> >>> Apache Hat: What a particular vendor chooses to puts in its releases
>> >>> shouldn't affect an Apache release and especially if we are breaking
>> >>> the
>> >>> project's versioning / compatibility rules.
>> >>>
>> >>> Jon.
>> >>>
>> >>> On Mon, Feb 11, 2013 at 4:32 PM, Ted Yu <yu...@gmail.com> wrote:
>> >>>> I downloaded hadoop-0.20.2+737 from Cloudera website.
>> >>>>
>> >>>> I found getShortUserName() in UserGroupInformation
>> >>>>
>> >>>> Haven't checked other 0.20.x source code yet.
>> >>>>
>> >>>> FYI
>> >>>>
>> >>>> On Mon, Feb 11, 2013 at 4:24 PM, Jonathan Hsieh <jo...@cloudera.com>
>> >>> wrote:
>> >>>>
>> >>>>> Hey guys, I saw HBASE-7814 [1] -- a backport committed to 0.94 that
>> >>>>> makes HBase 0.94 now require Hadoop 1.0 (instead of the older
>> >>>>> hadoops).  This was supposed to be a new requirement for hbase
>> 0.96.0.
>> >>>>> [2]
>> >>>>>
>> >>>>> Are we ok with making the next 0.94 upgrade incompatible?   (And if
>> we
>> >>>>> are we need to release note this kind of stuff).
>> >>>>>
>> >>>>> Jon.
>> >>>>>
>> >>>>> [1] https://issues.apache.org/jira/browse/HBASE-7814
>> >>>>>
>> >>>>> [2]
>> >>
>> http://mail-archives.apache.org/mod_mbox/hbase-dev/201210.mbox/%3CCADcMMgHtqx73JztE4schY04iqs9NPZP3u84HM2SM7iCL6r80mQ@mail.gmail.com%3E
>> >>>>>
>> >>>>>
>> >>>>> On Fri, Feb 8, 2013 at 11:56 AM, Enis Söztutar <en...@gmail.com>
>> >>> wrote:
>> >>>>>> The backporting situation for 0.94 is an exception it seems, because
>> >>> of
>> >>>>> the
>> >>>>>> fact that 96 is so late. But until 96 comes out, we can keep up the
>> >>>>> current
>> >>>>>> approach. It has worked mostly for the time being.
>> >>>>>>
>> >>>>>> Enis
>> >>>>>>
>> >>>>>>
>> >>>>>> On Thu, Feb 7, 2013 at 5:20 PM, Andrew Purtell <apurtell@apache.org
>> >>>
>> >>>>> wrote:
>> >>>>>>
>> >>>>>>> That said, let's make sure every backport has meaningful
>> >>> justification
>> >>>>>>> (determined by consensus).
>> >>>>>>>
>> >>>>>>>
>> >>>>>>> On Thu, Feb 7, 2013 at 5:19 PM, Andrew Purtell <
>> >> apurtell@apache.org>
>> >>>>>>> wrote:
>> >>>>>>>
>> >>>>>>>> -1 until we have an actual stable 0.96 release.
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>>> On Thu, Feb 7, 2013 at 3:15 PM, Elliott Clark <eclark@apache.org
>> >>>
>> >>>>> wrote:
>> >>>>>>>>
>> >>>>>>>>> Lately there have been a lot of issues being committed to trunk
>> >>> and
>> >>>>>>>>> also back-ported to 0.94 (I've done it myself too).  Since we're
>> >>> so
>> >>>>> far
>> >>>>>>>>> into 0.94's release cycle should we think about not allowing
>> >> minor
>> >>>>>>>>> features
>> >>>>>>>>> and code clean ups to be back-ported ?
>> >>>>>>>
>> >>>>>>> --
>> >>>>>>> Best regards,
>> >>>>>>>
>> >>>>>>>   - Andy
>> >>>>>>>
>> >>>>>>> Problems worthy of attack prove their worth by hitting back. - Piet
>> >>> Hein
>> >>>>>>> (via Tom White)
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>> --
>> >>>>> // Jonathan Hsieh (shay)
>> >>>>> // Software Engineer, Cloudera
>> >>>>> // jon@cloudera.com
>> >>>
>> >>>
>> >>>
>> >>> --
>> >>> // Jonathan Hsieh (shay)
>> >>> // Software Engineer, Cloudera
>> >>> // jon@cloudera.com
>> >>
>>
>
>
>
> --
> Best regards,
>
>    - Andy
>
> Problems worthy of attack prove their worth by hitting back. - Piet Hein
> (via Tom White)



-- 
// Jonathan Hsieh (shay)
// Software Engineer, Cloudera
// jon@cloudera.com

Re: 0.94 Backports.

Posted by Andrew Purtell <ap...@apache.org>.
I'm also concerned that the revert happened here while discussion was
ongoing. Given the latest comments on the issue, this could have been
handled by a new issue that replaces the offending code with reflection. I
don't care about the revert per se but would ask we avoid making changes
out from under a discussion until the matter is resolved with consensus. We
will have cleaner revision history and less churn overall as a result. I
know many of us have to-do lists of HBase JIRAs to retire, but there is no
need to be hasty. Because we are all busy, unnecessary commit speed makes
it more likely mistakes like this will slip by review in the first place
too.

For your consideration.


On Mon, Feb 11, 2013 at 5:40 PM, Ted <yu...@gmail.com> wrote:

> No.
> The release was cut before the revert.
>
> On Feb 11, 2013, at 5:35 PM, Enis Söztutar <en...@gmail.com> wrote:
>
> > I was going to +1 the release, with the following checks I did:
> > - Checked md5 sums
> > - Checked gpg signature (gpg --verify )
> > - Checked included documentation book.html, etc.
> > - Running unit tests (passed on unsecure, secure)
> > - Started in local mode, run LoadTestTool
> > - integration tests (not working fully properly, but expected since
> > HBASE-7521 is not in yet)
> >
> > I guess this means that the release candidate has sunk, right?
> > Enis
> >
> >
> >
> > On Mon, Feb 11, 2013 at 4:59 PM, Stack <st...@duboce.net> wrote:
> >
> >> Good catch Jon.
> >>
> >> We need to be vigilant here all.
> >>
> >> Incompatibilities cost users and those following behind us as they burn
> >> cycles doing gymnastics trying to get over the incompatibility -- if it
> is
> >> possible to get over the incompatibility at all.  They make us look bad.
> >> Worse, usually the incompatibility is found months later after we have
> all
> >> moved on and have long forgot what it was we committed (and even why) so
> >> all the more reason to be on the look out at commit time.
> >>
> >> St.Ack
> >>
> >>
> >> On Mon, Feb 11, 2013 at 4:48 PM, Jonathan Hsieh <jo...@cloudera.com>
> wrote:
> >>
> >>> Apache Hat: What a particular vendor chooses to puts in its releases
> >>> shouldn't affect an Apache release and especially if we are breaking
> >>> the
> >>> project's versioning / compatibility rules.
> >>>
> >>> Jon.
> >>>
> >>> On Mon, Feb 11, 2013 at 4:32 PM, Ted Yu <yu...@gmail.com> wrote:
> >>>> I downloaded hadoop-0.20.2+737 from Cloudera website.
> >>>>
> >>>> I found getShortUserName() in UserGroupInformation
> >>>>
> >>>> Haven't checked other 0.20.x source code yet.
> >>>>
> >>>> FYI
> >>>>
> >>>> On Mon, Feb 11, 2013 at 4:24 PM, Jonathan Hsieh <jo...@cloudera.com>
> >>> wrote:
> >>>>
> >>>>> Hey guys, I saw HBASE-7814 [1] -- a backport committed to 0.94 that
> >>>>> makes HBase 0.94 now require Hadoop 1.0 (instead of the older
> >>>>> hadoops).  This was supposed to be a new requirement for hbase
> 0.96.0.
> >>>>> [2]
> >>>>>
> >>>>> Are we ok with making the next 0.94 upgrade incompatible?   (And if
> we
> >>>>> are we need to release note this kind of stuff).
> >>>>>
> >>>>> Jon.
> >>>>>
> >>>>> [1] https://issues.apache.org/jira/browse/HBASE-7814
> >>>>>
> >>>>> [2]
> >>
> http://mail-archives.apache.org/mod_mbox/hbase-dev/201210.mbox/%3CCADcMMgHtqx73JztE4schY04iqs9NPZP3u84HM2SM7iCL6r80mQ@mail.gmail.com%3E
> >>>>>
> >>>>>
> >>>>> On Fri, Feb 8, 2013 at 11:56 AM, Enis Söztutar <en...@gmail.com>
> >>> wrote:
> >>>>>> The backporting situation for 0.94 is an exception it seems, because
> >>> of
> >>>>> the
> >>>>>> fact that 96 is so late. But until 96 comes out, we can keep up the
> >>>>> current
> >>>>>> approach. It has worked mostly for the time being.
> >>>>>>
> >>>>>> Enis
> >>>>>>
> >>>>>>
> >>>>>> On Thu, Feb 7, 2013 at 5:20 PM, Andrew Purtell <apurtell@apache.org
> >>>
> >>>>> wrote:
> >>>>>>
> >>>>>>> That said, let's make sure every backport has meaningful
> >>> justification
> >>>>>>> (determined by consensus).
> >>>>>>>
> >>>>>>>
> >>>>>>> On Thu, Feb 7, 2013 at 5:19 PM, Andrew Purtell <
> >> apurtell@apache.org>
> >>>>>>> wrote:
> >>>>>>>
> >>>>>>>> -1 until we have an actual stable 0.96 release.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> On Thu, Feb 7, 2013 at 3:15 PM, Elliott Clark <eclark@apache.org
> >>>
> >>>>> wrote:
> >>>>>>>>
> >>>>>>>>> Lately there have been a lot of issues being committed to trunk
> >>> and
> >>>>>>>>> also back-ported to 0.94 (I've done it myself too).  Since we're
> >>> so
> >>>>> far
> >>>>>>>>> into 0.94's release cycle should we think about not allowing
> >> minor
> >>>>>>>>> features
> >>>>>>>>> and code clean ups to be back-ported ?
> >>>>>>>
> >>>>>>> --
> >>>>>>> Best regards,
> >>>>>>>
> >>>>>>>   - Andy
> >>>>>>>
> >>>>>>> Problems worthy of attack prove their worth by hitting back. - Piet
> >>> Hein
> >>>>>>> (via Tom White)
> >>>>>
> >>>>>
> >>>>>
> >>>>> --
> >>>>> // Jonathan Hsieh (shay)
> >>>>> // Software Engineer, Cloudera
> >>>>> // jon@cloudera.com
> >>>
> >>>
> >>>
> >>> --
> >>> // Jonathan Hsieh (shay)
> >>> // Software Engineer, Cloudera
> >>> // jon@cloudera.com
> >>
>



-- 
Best regards,

   - Andy

Problems worthy of attack prove their worth by hitting back. - Piet Hein
(via Tom White)

Re: 0.94 Backports.

Posted by Ted <yu...@gmail.com>.
No. 
The release was cut before the revert. 

On Feb 11, 2013, at 5:35 PM, Enis Söztutar <en...@gmail.com> wrote:

> I was going to +1 the release, with the following checks I did:
> - Checked md5 sums
> - Checked gpg signature (gpg --verify )
> - Checked included documentation book.html, etc.
> - Running unit tests (passed on unsecure, secure)
> - Started in local mode, run LoadTestTool
> - integration tests (not working fully properly, but expected since
> HBASE-7521 is not in yet)
> 
> I guess this means that the release candidate has sunk, right?
> Enis
> 
> 
> 
> On Mon, Feb 11, 2013 at 4:59 PM, Stack <st...@duboce.net> wrote:
> 
>> Good catch Jon.
>> 
>> We need to be vigilant here all.
>> 
>> Incompatibilities cost users and those following behind us as they burn
>> cycles doing gymnastics trying to get over the incompatibility -- if it is
>> possible to get over the incompatibility at all.  They make us look bad.
>> Worse, usually the incompatibility is found months later after we have all
>> moved on and have long forgot what it was we committed (and even why) so
>> all the more reason to be on the look out at commit time.
>> 
>> St.Ack
>> 
>> 
>> On Mon, Feb 11, 2013 at 4:48 PM, Jonathan Hsieh <jo...@cloudera.com> wrote:
>> 
>>> Apache Hat: What a particular vendor chooses to puts in its releases
>>> shouldn't affect an Apache release and especially if we are breaking
>>> the
>>> project's versioning / compatibility rules.
>>> 
>>> Jon.
>>> 
>>> On Mon, Feb 11, 2013 at 4:32 PM, Ted Yu <yu...@gmail.com> wrote:
>>>> I downloaded hadoop-0.20.2+737 from Cloudera website.
>>>> 
>>>> I found getShortUserName() in UserGroupInformation
>>>> 
>>>> Haven't checked other 0.20.x source code yet.
>>>> 
>>>> FYI
>>>> 
>>>> On Mon, Feb 11, 2013 at 4:24 PM, Jonathan Hsieh <jo...@cloudera.com>
>>> wrote:
>>>> 
>>>>> Hey guys, I saw HBASE-7814 [1] -- a backport committed to 0.94 that
>>>>> makes HBase 0.94 now require Hadoop 1.0 (instead of the older
>>>>> hadoops).  This was supposed to be a new requirement for hbase 0.96.0.
>>>>> [2]
>>>>> 
>>>>> Are we ok with making the next 0.94 upgrade incompatible?   (And if we
>>>>> are we need to release note this kind of stuff).
>>>>> 
>>>>> Jon.
>>>>> 
>>>>> [1] https://issues.apache.org/jira/browse/HBASE-7814
>>>>> 
>>>>> [2]
>> http://mail-archives.apache.org/mod_mbox/hbase-dev/201210.mbox/%3CCADcMMgHtqx73JztE4schY04iqs9NPZP3u84HM2SM7iCL6r80mQ@mail.gmail.com%3E
>>>>> 
>>>>> 
>>>>> On Fri, Feb 8, 2013 at 11:56 AM, Enis Söztutar <en...@gmail.com>
>>> wrote:
>>>>>> The backporting situation for 0.94 is an exception it seems, because
>>> of
>>>>> the
>>>>>> fact that 96 is so late. But until 96 comes out, we can keep up the
>>>>> current
>>>>>> approach. It has worked mostly for the time being.
>>>>>> 
>>>>>> Enis
>>>>>> 
>>>>>> 
>>>>>> On Thu, Feb 7, 2013 at 5:20 PM, Andrew Purtell <apurtell@apache.org
>>> 
>>>>> wrote:
>>>>>> 
>>>>>>> That said, let's make sure every backport has meaningful
>>> justification
>>>>>>> (determined by consensus).
>>>>>>> 
>>>>>>> 
>>>>>>> On Thu, Feb 7, 2013 at 5:19 PM, Andrew Purtell <
>> apurtell@apache.org>
>>>>>>> wrote:
>>>>>>> 
>>>>>>>> -1 until we have an actual stable 0.96 release.
>>>>>>>> 
>>>>>>>> 
>>>>>>>> On Thu, Feb 7, 2013 at 3:15 PM, Elliott Clark <eclark@apache.org
>>> 
>>>>> wrote:
>>>>>>>> 
>>>>>>>>> Lately there have been a lot of issues being committed to trunk
>>> and
>>>>>>>>> also back-ported to 0.94 (I've done it myself too).  Since we're
>>> so
>>>>> far
>>>>>>>>> into 0.94's release cycle should we think about not allowing
>> minor
>>>>>>>>> features
>>>>>>>>> and code clean ups to be back-ported ?
>>>>>>> 
>>>>>>> --
>>>>>>> Best regards,
>>>>>>> 
>>>>>>>   - Andy
>>>>>>> 
>>>>>>> Problems worthy of attack prove their worth by hitting back. - Piet
>>> Hein
>>>>>>> (via Tom White)
>>>>> 
>>>>> 
>>>>> 
>>>>> --
>>>>> // Jonathan Hsieh (shay)
>>>>> // Software Engineer, Cloudera
>>>>> // jon@cloudera.com
>>> 
>>> 
>>> 
>>> --
>>> // Jonathan Hsieh (shay)
>>> // Software Engineer, Cloudera
>>> // jon@cloudera.com
>> 

Re: 0.94 Backports.

Posted by Enis Söztutar <en...@gmail.com>.
I was going to +1 the release, with the following checks I did:
 - Checked md5 sums
 - Checked gpg signature (gpg --verify )
 - Checked included documentation book.html, etc.
 - Running unit tests (passed on unsecure, secure)
 - Started in local mode, run LoadTestTool
 - integration tests (not working fully properly, but expected since
HBASE-7521 is not in yet)

I guess this means that the release candidate has sunk, right?
Enis



On Mon, Feb 11, 2013 at 4:59 PM, Stack <st...@duboce.net> wrote:

> Good catch Jon.
>
> We need to be vigilant here all.
>
> Incompatibilities cost users and those following behind us as they burn
> cycles doing gymnastics trying to get over the incompatibility -- if it is
> possible to get over the incompatibility at all.  They make us look bad.
>  Worse, usually the incompatibility is found months later after we have all
> moved on and have long forgot what it was we committed (and even why) so
> all the more reason to be on the look out at commit time.
>
> St.Ack
>
>
> On Mon, Feb 11, 2013 at 4:48 PM, Jonathan Hsieh <jo...@cloudera.com> wrote:
>
> > Apache Hat: What a particular vendor chooses to puts in its releases
> > shouldn't affect an Apache release and especially if we are breaking
> > the
> > project's versioning / compatibility rules.
> >
> > Jon.
> >
> > On Mon, Feb 11, 2013 at 4:32 PM, Ted Yu <yu...@gmail.com> wrote:
> > > I downloaded hadoop-0.20.2+737 from Cloudera website.
> > >
> > > I found getShortUserName() in UserGroupInformation
> > >
> > > Haven't checked other 0.20.x source code yet.
> > >
> > > FYI
> > >
> > > On Mon, Feb 11, 2013 at 4:24 PM, Jonathan Hsieh <jo...@cloudera.com>
> > wrote:
> > >
> > >> Hey guys, I saw HBASE-7814 [1] -- a backport committed to 0.94 that
> > >> makes HBase 0.94 now require Hadoop 1.0 (instead of the older
> > >> hadoops).  This was supposed to be a new requirement for hbase 0.96.0.
> > >> [2]
> > >>
> > >> Are we ok with making the next 0.94 upgrade incompatible?   (And if we
> > >> are we need to release note this kind of stuff).
> > >>
> > >> Jon.
> > >>
> > >> [1] https://issues.apache.org/jira/browse/HBASE-7814
> > >>
> > >> [2]
> > >>
> >
> http://mail-archives.apache.org/mod_mbox/hbase-dev/201210.mbox/%3CCADcMMgHtqx73JztE4schY04iqs9NPZP3u84HM2SM7iCL6r80mQ@mail.gmail.com%3E
> > >>
> > >>
> > >> On Fri, Feb 8, 2013 at 11:56 AM, Enis Söztutar <en...@gmail.com>
> > wrote:
> > >> > The backporting situation for 0.94 is an exception it seems, because
> > of
> > >> the
> > >> > fact that 96 is so late. But until 96 comes out, we can keep up the
> > >> current
> > >> > approach. It has worked mostly for the time being.
> > >> >
> > >> > Enis
> > >> >
> > >> >
> > >> > On Thu, Feb 7, 2013 at 5:20 PM, Andrew Purtell <apurtell@apache.org
> >
> > >> wrote:
> > >> >
> > >> >> That said, let's make sure every backport has meaningful
> > justification
> > >> >> (determined by consensus).
> > >> >>
> > >> >>
> > >> >> On Thu, Feb 7, 2013 at 5:19 PM, Andrew Purtell <
> apurtell@apache.org>
> > >> >> wrote:
> > >> >>
> > >> >> > -1 until we have an actual stable 0.96 release.
> > >> >> >
> > >> >> >
> > >> >> > On Thu, Feb 7, 2013 at 3:15 PM, Elliott Clark <eclark@apache.org
> >
> > >> wrote:
> > >> >> >
> > >> >> >> Lately there have been a lot of issues being committed to trunk
> > and
> > >> >> >> also back-ported to 0.94 (I've done it myself too).  Since we're
> > so
> > >> far
> > >> >> >> into 0.94's release cycle should we think about not allowing
> minor
> > >> >> >> features
> > >> >> >> and code clean ups to be back-ported ?
> > >> >> >
> > >> >> >
> > >> >>
> > >> >> --
> > >> >> Best regards,
> > >> >>
> > >> >>    - Andy
> > >> >>
> > >> >> Problems worthy of attack prove their worth by hitting back. - Piet
> > Hein
> > >> >> (via Tom White)
> > >> >>
> > >>
> > >>
> > >>
> > >> --
> > >> // Jonathan Hsieh (shay)
> > >> // Software Engineer, Cloudera
> > >> // jon@cloudera.com
> > >>
> >
> >
> >
> > --
> > // Jonathan Hsieh (shay)
> > // Software Engineer, Cloudera
> > // jon@cloudera.com
> >
>

Re: 0.94 Backports.

Posted by Stack <st...@duboce.net>.
Good catch Jon.

We need to be vigilant here all.

Incompatibilities cost users and those following behind us as they burn
cycles doing gymnastics trying to get over the incompatibility -- if it is
possible to get over the incompatibility at all.  They make us look bad.
 Worse, usually the incompatibility is found months later after we have all
moved on and have long forgot what it was we committed (and even why) so
all the more reason to be on the look out at commit time.

St.Ack


On Mon, Feb 11, 2013 at 4:48 PM, Jonathan Hsieh <jo...@cloudera.com> wrote:

> Apache Hat: What a particular vendor chooses to puts in its releases
> shouldn't affect an Apache release and especially if we are breaking
> the
> project's versioning / compatibility rules.
>
> Jon.
>
> On Mon, Feb 11, 2013 at 4:32 PM, Ted Yu <yu...@gmail.com> wrote:
> > I downloaded hadoop-0.20.2+737 from Cloudera website.
> >
> > I found getShortUserName() in UserGroupInformation
> >
> > Haven't checked other 0.20.x source code yet.
> >
> > FYI
> >
> > On Mon, Feb 11, 2013 at 4:24 PM, Jonathan Hsieh <jo...@cloudera.com>
> wrote:
> >
> >> Hey guys, I saw HBASE-7814 [1] -- a backport committed to 0.94 that
> >> makes HBase 0.94 now require Hadoop 1.0 (instead of the older
> >> hadoops).  This was supposed to be a new requirement for hbase 0.96.0.
> >> [2]
> >>
> >> Are we ok with making the next 0.94 upgrade incompatible?   (And if we
> >> are we need to release note this kind of stuff).
> >>
> >> Jon.
> >>
> >> [1] https://issues.apache.org/jira/browse/HBASE-7814
> >>
> >> [2]
> >>
> http://mail-archives.apache.org/mod_mbox/hbase-dev/201210.mbox/%3CCADcMMgHtqx73JztE4schY04iqs9NPZP3u84HM2SM7iCL6r80mQ@mail.gmail.com%3E
> >>
> >>
> >> On Fri, Feb 8, 2013 at 11:56 AM, Enis Söztutar <en...@gmail.com>
> wrote:
> >> > The backporting situation for 0.94 is an exception it seems, because
> of
> >> the
> >> > fact that 96 is so late. But until 96 comes out, we can keep up the
> >> current
> >> > approach. It has worked mostly for the time being.
> >> >
> >> > Enis
> >> >
> >> >
> >> > On Thu, Feb 7, 2013 at 5:20 PM, Andrew Purtell <ap...@apache.org>
> >> wrote:
> >> >
> >> >> That said, let's make sure every backport has meaningful
> justification
> >> >> (determined by consensus).
> >> >>
> >> >>
> >> >> On Thu, Feb 7, 2013 at 5:19 PM, Andrew Purtell <ap...@apache.org>
> >> >> wrote:
> >> >>
> >> >> > -1 until we have an actual stable 0.96 release.
> >> >> >
> >> >> >
> >> >> > On Thu, Feb 7, 2013 at 3:15 PM, Elliott Clark <ec...@apache.org>
> >> wrote:
> >> >> >
> >> >> >> Lately there have been a lot of issues being committed to trunk
> and
> >> >> >> also back-ported to 0.94 (I've done it myself too).  Since we're
> so
> >> far
> >> >> >> into 0.94's release cycle should we think about not allowing minor
> >> >> >> features
> >> >> >> and code clean ups to be back-ported ?
> >> >> >
> >> >> >
> >> >>
> >> >> --
> >> >> Best regards,
> >> >>
> >> >>    - Andy
> >> >>
> >> >> Problems worthy of attack prove their worth by hitting back. - Piet
> Hein
> >> >> (via Tom White)
> >> >>
> >>
> >>
> >>
> >> --
> >> // Jonathan Hsieh (shay)
> >> // Software Engineer, Cloudera
> >> // jon@cloudera.com
> >>
>
>
>
> --
> // Jonathan Hsieh (shay)
> // Software Engineer, Cloudera
> // jon@cloudera.com
>

Re: 0.94 Backports.

Posted by Jonathan Hsieh <jo...@cloudera.com>.
Apache Hat: What a particular vendor chooses to puts in its releases
shouldn't affect an Apache release and especially if we are breaking
the
project's versioning / compatibility rules.

Jon.

On Mon, Feb 11, 2013 at 4:32 PM, Ted Yu <yu...@gmail.com> wrote:
> I downloaded hadoop-0.20.2+737 from Cloudera website.
>
> I found getShortUserName() in UserGroupInformation
>
> Haven't checked other 0.20.x source code yet.
>
> FYI
>
> On Mon, Feb 11, 2013 at 4:24 PM, Jonathan Hsieh <jo...@cloudera.com> wrote:
>
>> Hey guys, I saw HBASE-7814 [1] -- a backport committed to 0.94 that
>> makes HBase 0.94 now require Hadoop 1.0 (instead of the older
>> hadoops).  This was supposed to be a new requirement for hbase 0.96.0.
>> [2]
>>
>> Are we ok with making the next 0.94 upgrade incompatible?   (And if we
>> are we need to release note this kind of stuff).
>>
>> Jon.
>>
>> [1] https://issues.apache.org/jira/browse/HBASE-7814
>>
>> [2]
>> http://mail-archives.apache.org/mod_mbox/hbase-dev/201210.mbox/%3CCADcMMgHtqx73JztE4schY04iqs9NPZP3u84HM2SM7iCL6r80mQ@mail.gmail.com%3E
>>
>>
>> On Fri, Feb 8, 2013 at 11:56 AM, Enis Söztutar <en...@gmail.com> wrote:
>> > The backporting situation for 0.94 is an exception it seems, because of
>> the
>> > fact that 96 is so late. But until 96 comes out, we can keep up the
>> current
>> > approach. It has worked mostly for the time being.
>> >
>> > Enis
>> >
>> >
>> > On Thu, Feb 7, 2013 at 5:20 PM, Andrew Purtell <ap...@apache.org>
>> wrote:
>> >
>> >> That said, let's make sure every backport has meaningful justification
>> >> (determined by consensus).
>> >>
>> >>
>> >> On Thu, Feb 7, 2013 at 5:19 PM, Andrew Purtell <ap...@apache.org>
>> >> wrote:
>> >>
>> >> > -1 until we have an actual stable 0.96 release.
>> >> >
>> >> >
>> >> > On Thu, Feb 7, 2013 at 3:15 PM, Elliott Clark <ec...@apache.org>
>> wrote:
>> >> >
>> >> >> Lately there have been a lot of issues being committed to trunk and
>> >> >> also back-ported to 0.94 (I've done it myself too).  Since we're so
>> far
>> >> >> into 0.94's release cycle should we think about not allowing minor
>> >> >> features
>> >> >> and code clean ups to be back-ported ?
>> >> >
>> >> >
>> >>
>> >> --
>> >> Best regards,
>> >>
>> >>    - Andy
>> >>
>> >> Problems worthy of attack prove their worth by hitting back. - Piet Hein
>> >> (via Tom White)
>> >>
>>
>>
>>
>> --
>> // Jonathan Hsieh (shay)
>> // Software Engineer, Cloudera
>> // jon@cloudera.com
>>



-- 
// Jonathan Hsieh (shay)
// Software Engineer, Cloudera
// jon@cloudera.com

Re: 0.94 Backports.

Posted by Ted Yu <yu...@gmail.com>.
I downloaded hadoop-0.20.2+737 from Cloudera website.

I found getShortUserName() in UserGroupInformation

Haven't checked other 0.20.x source code yet.

FYI

On Mon, Feb 11, 2013 at 4:24 PM, Jonathan Hsieh <jo...@cloudera.com> wrote:

> Hey guys, I saw HBASE-7814 [1] -- a backport committed to 0.94 that
> makes HBase 0.94 now require Hadoop 1.0 (instead of the older
> hadoops).  This was supposed to be a new requirement for hbase 0.96.0.
> [2]
>
> Are we ok with making the next 0.94 upgrade incompatible?   (And if we
> are we need to release note this kind of stuff).
>
> Jon.
>
> [1] https://issues.apache.org/jira/browse/HBASE-7814
>
> [2]
> http://mail-archives.apache.org/mod_mbox/hbase-dev/201210.mbox/%3CCADcMMgHtqx73JztE4schY04iqs9NPZP3u84HM2SM7iCL6r80mQ@mail.gmail.com%3E
>
>
> On Fri, Feb 8, 2013 at 11:56 AM, Enis Söztutar <en...@gmail.com> wrote:
> > The backporting situation for 0.94 is an exception it seems, because of
> the
> > fact that 96 is so late. But until 96 comes out, we can keep up the
> current
> > approach. It has worked mostly for the time being.
> >
> > Enis
> >
> >
> > On Thu, Feb 7, 2013 at 5:20 PM, Andrew Purtell <ap...@apache.org>
> wrote:
> >
> >> That said, let's make sure every backport has meaningful justification
> >> (determined by consensus).
> >>
> >>
> >> On Thu, Feb 7, 2013 at 5:19 PM, Andrew Purtell <ap...@apache.org>
> >> wrote:
> >>
> >> > -1 until we have an actual stable 0.96 release.
> >> >
> >> >
> >> > On Thu, Feb 7, 2013 at 3:15 PM, Elliott Clark <ec...@apache.org>
> wrote:
> >> >
> >> >> Lately there have been a lot of issues being committed to trunk and
> >> >> also back-ported to 0.94 (I've done it myself too).  Since we're so
> far
> >> >> into 0.94's release cycle should we think about not allowing minor
> >> >> features
> >> >> and code clean ups to be back-ported ?
> >> >
> >> >
> >>
> >> --
> >> Best regards,
> >>
> >>    - Andy
> >>
> >> Problems worthy of attack prove their worth by hitting back. - Piet Hein
> >> (via Tom White)
> >>
>
>
>
> --
> // Jonathan Hsieh (shay)
> // Software Engineer, Cloudera
> // jon@cloudera.com
>

Re: 0.94 Backports.

Posted by Jonathan Hsieh <jo...@cloudera.com>.
Hey guys, I saw HBASE-7814 [1] -- a backport committed to 0.94 that
makes HBase 0.94 now require Hadoop 1.0 (instead of the older
hadoops).  This was supposed to be a new requirement for hbase 0.96.0.
[2]

Are we ok with making the next 0.94 upgrade incompatible?   (And if we
are we need to release note this kind of stuff).

Jon.

[1] https://issues.apache.org/jira/browse/HBASE-7814

[2] http://mail-archives.apache.org/mod_mbox/hbase-dev/201210.mbox/%3CCADcMMgHtqx73JztE4schY04iqs9NPZP3u84HM2SM7iCL6r80mQ@mail.gmail.com%3E


On Fri, Feb 8, 2013 at 11:56 AM, Enis Söztutar <en...@gmail.com> wrote:
> The backporting situation for 0.94 is an exception it seems, because of the
> fact that 96 is so late. But until 96 comes out, we can keep up the current
> approach. It has worked mostly for the time being.
>
> Enis
>
>
> On Thu, Feb 7, 2013 at 5:20 PM, Andrew Purtell <ap...@apache.org> wrote:
>
>> That said, let's make sure every backport has meaningful justification
>> (determined by consensus).
>>
>>
>> On Thu, Feb 7, 2013 at 5:19 PM, Andrew Purtell <ap...@apache.org>
>> wrote:
>>
>> > -1 until we have an actual stable 0.96 release.
>> >
>> >
>> > On Thu, Feb 7, 2013 at 3:15 PM, Elliott Clark <ec...@apache.org> wrote:
>> >
>> >> Lately there have been a lot of issues being committed to trunk and
>> >> also back-ported to 0.94 (I've done it myself too).  Since we're so far
>> >> into 0.94's release cycle should we think about not allowing minor
>> >> features
>> >> and code clean ups to be back-ported ?
>> >
>> >
>>
>> --
>> Best regards,
>>
>>    - Andy
>>
>> Problems worthy of attack prove their worth by hitting back. - Piet Hein
>> (via Tom White)
>>



-- 
// Jonathan Hsieh (shay)
// Software Engineer, Cloudera
// jon@cloudera.com

Re: 0.94 Backports.

Posted by Enis Söztutar <en...@gmail.com>.
The backporting situation for 0.94 is an exception it seems, because of the
fact that 96 is so late. But until 96 comes out, we can keep up the current
approach. It has worked mostly for the time being.

Enis


On Thu, Feb 7, 2013 at 5:20 PM, Andrew Purtell <ap...@apache.org> wrote:

> That said, let's make sure every backport has meaningful justification
> (determined by consensus).
>
>
> On Thu, Feb 7, 2013 at 5:19 PM, Andrew Purtell <ap...@apache.org>
> wrote:
>
> > -1 until we have an actual stable 0.96 release.
> >
> >
> > On Thu, Feb 7, 2013 at 3:15 PM, Elliott Clark <ec...@apache.org> wrote:
> >
> >> Lately there have been a lot of issues being committed to trunk and
> >> also back-ported to 0.94 (I've done it myself too).  Since we're so far
> >> into 0.94's release cycle should we think about not allowing minor
> >> features
> >> and code clean ups to be back-ported ?
> >
> >
>
> --
> Best regards,
>
>    - Andy
>
> Problems worthy of attack prove their worth by hitting back. - Piet Hein
> (via Tom White)
>

Re: 0.94 Backports.

Posted by Andrew Purtell <ap...@apache.org>.
That said, let's make sure every backport has meaningful justification
(determined by consensus).


On Thu, Feb 7, 2013 at 5:19 PM, Andrew Purtell <ap...@apache.org> wrote:

> -1 until we have an actual stable 0.96 release.
>
>
> On Thu, Feb 7, 2013 at 3:15 PM, Elliott Clark <ec...@apache.org> wrote:
>
>> Lately there have been a lot of issues being committed to trunk and
>> also back-ported to 0.94 (I've done it myself too).  Since we're so far
>> into 0.94's release cycle should we think about not allowing minor
>> features
>> and code clean ups to be back-ported ?
>
>

-- 
Best regards,

   - Andy

Problems worthy of attack prove their worth by hitting back. - Piet Hein
(via Tom White)

Re: 0.94 Backports.

Posted by Andrew Purtell <ap...@apache.org>.
-1 until we have an actual stable 0.96 release.


On Thu, Feb 7, 2013 at 3:15 PM, Elliott Clark <ec...@apache.org> wrote:

> Lately there have been a lot of issues being committed to trunk and
> also back-ported to 0.94 (I've done it myself too).  Since we're so far
> into 0.94's release cycle should we think about not allowing minor features
> and code clean ups to be back-ported ?
>



-- 
Best regards,

   - Andy

Problems worthy of attack prove their worth by hitting back. - Piet Hein
(via Tom White)