You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hbase.apache.org by Andrew Purtell <ap...@apache.org> on 2016/07/22 23:21:50 UTC
Feedback from the July 2016 board report
In our last board report we mentioned the several code lines we current
manage and were asked to consider some form of support policy so the
community is able to make informed decisions about which release line to
use.
The first question is: should we have one?
The second question, if the answer to the first is 'yes', is what that
policy should be.
--
Best regards,
- Andy
Problems worthy of attack prove their worth by hitting back. - Piet Hein
(via Tom White)
Re: Feedback from the July 2016 board report
Posted by Andrew Purtell <an...@gmail.com>.
I would like to be proactive about board feedback so I will put up a patch for our site and documentation that describes the status of our active code lines in the terms that Nick suggests below. I would add an entry for 2.0 describing it as "future, unstable".
I would also like to find a service for taking free surveys (or low cost) and advertise a multiple choice survey on dev@ and user@ and Twitter asking users:
- What version of HBase do you currently use? (0.94, 0.98, 1.0, 1.1, 1.2).
- What version of HBase would you consider upgrading to in the next year? (1.1, 1.2, 1.3, 2.0)
This should work for both Apache releases and any derivatives based on a particular minor, and I think we want that usage in aggregate.
> On Jul 22, 2016, at 6:42 PM, Nick Dimiduk <nd...@gmail.com> wrote:
>
> Maybe it's worth spelling out? It will become more obvious once 0.98 is
> retired. I think of them like this:
>
> 0.98.x -- legacy
> 1.x -- current
>
> Within current, we have
>
> 1.0.x -- retired/EOL
> 1.1.x -- maintenance
> 1.2.x -- stable
> 1.3.x -- unstable
>
> In time, 1.1 will also retire/EOL, 1.2 will become maintenance, and so on.
>
>> On Friday, July 22, 2016, Andrew Purtell <ap...@apache.org> wrote:
>>
>> In our last board report we mentioned the several code lines we current
>> manage and were asked to consider some form of support policy so the
>> community is able to make informed decisions about which release line to
>> use.
>>
>> The first question is: should we have one?
>>
>> The second question, if the answer to the first is 'yes', is what that
>> policy should be.
>>
>>
>>
>>
>> --
>> Best regards,
>>
>> - Andy
>>
>> Problems worthy of attack prove their worth by hitting back. - Piet Hein
>> (via Tom White)
>>
Re: Feedback from the July 2016 board report
Posted by Dima Spivak <ds...@cloudera.com>.
+1 to Enis' suggestions of documenting in the ref guide (and then keeping
it up to date). "Which HBase version should I use?" is a frequently-enough
asked question that we should answer it in a central place.
https://hbase.apache.org/book.html#_get_started_with_hbase seems like a
decent enough place to start?
-Dima
On Mon, Jul 25, 2016 at 12:07 PM, Andrew Purtell <an...@gmail.com>
wrote:
> On a closely related topic - the retiring of 0.98 - can I ask for your
> opinions on timeframe to sunsetting? I am happy to continue maintaining it
> for as long as that would be desirable and useful. On the other hand at
> some point it's a legacy we need to move on from. If there's some guidance
> on this let's include it in what we are writing up.
>
>
> > On Jul 25, 2016, at 11:21 AM, Enis Söztutar <en...@apache.org> wrote:
> >
> > +1 to above.
> >
> > This is what I used as a "guide to selecting a release":
> >
> http://www.slideshare.net/enissoz/hbase-state-of-the-union/16?src=clipshare
> >
> > Should we document this in the book somehow? We should put extra effort
> to
> > keep it up to date.
> >
> > Enis
> >
> >> On Fri, Jul 22, 2016 at 6:42 PM, Nick Dimiduk <nd...@gmail.com>
> wrote:
> >>
> >> Maybe it's worth spelling out? It will become more obvious once 0.98 is
> >> retired. I think of them like this:
> >>
> >> 0.98.x -- legacy
> >> 1.x -- current
> >>
> >> Within current, we have
> >>
> >> 1.0.x -- retired/EOL
> >> 1.1.x -- maintenance
> >> 1.2.x -- stable
> >> 1.3.x -- unstable
> >>
> >> In time, 1.1 will also retire/EOL, 1.2 will become maintenance, and so
> on.
> >>
> >>> On Friday, July 22, 2016, Andrew Purtell <ap...@apache.org> wrote:
> >>>
> >>> In our last board report we mentioned the several code lines we current
> >>> manage and were asked to consider some form of support policy so the
> >>> community is able to make informed decisions about which release line
> to
> >>> use.
> >>>
> >>> The first question is: should we have one?
> >>>
> >>> The second question, if the answer to the first is 'yes', is what that
> >>> policy should be.
> >>>
> >>>
> >>>
> >>>
> >>> --
> >>> Best regards,
> >>>
> >>> - Andy
> >>>
> >>> Problems worthy of attack prove their worth by hitting back. - Piet
> Hein
> >>> (via Tom White)
> >>
>
Re: Feedback from the July 2016 board report
Posted by la...@apache.org.
We could do a poll.
In the end it will probably happen organically - like it did with 0.94.
It's not a decision to be made per se - it's open source after all.As long as patches are backported and issues are reported against 0.98 there is a need and, IMHO, we should continue doing releases. If/When that stops users and contributors have lost interest and we can EOL.
With that, looking at 0.98.21 with 44 resolved/closed issues, 22 open/in-progress/patch-available, that looks pretty healthy and in demand to me!(Unless it's all your doing, Andy... Also looks like it's time for an 0.98.21 RC :) )
Of course then there's the question of how much work we - as volunteers - are willing to put into this.
I like the general statement about maintenance, stable, and unstable.
Perhaps that needs to be played by ear to some extent? What if - as an example - we had called the next release not 1.3 but 2.0 and introduced major breaking changes (as much as we allow ourselves per the compatibility guide)? Would we maintain 1.1.x, 1.2.x *and* 2.0.x and 2.1.x, because folks might be stuck a bit longer with 1.x?
-- Lars
From: Andrew Purtell <an...@gmail.com>
To: dev@hbase.apache.org
Sent: Monday, July 25, 2016 12:07 PM
Subject: Re: Feedback from the July 2016 board report
On a closely related topic - the retiring of 0.98 - can I ask for your opinions on timeframe to sunsetting? I am happy to continue maintaining it for as long as that would be desirable and useful. On the other hand at some point it's a legacy we need to move on from. If there's some guidance on this let's include it in what we are writing up.
> On Jul 25, 2016, at 11:21 AM, Enis Söztutar <en...@apache.org> wrote:
>
> +1 to above.
>
> This is what I used as a "guide to selecting a release":
> http://www.slideshare.net/enissoz/hbase-state-of-the-union/16?src=clipshare
>
> Should we document this in the book somehow? We should put extra effort to
> keep it up to date.
>
> Enis
>
>> On Fri, Jul 22, 2016 at 6:42 PM, Nick Dimiduk <nd...@gmail.com> wrote:
>>
>> Maybe it's worth spelling out? It will become more obvious once 0.98 is
>> retired. I think of them like this:
>>
>> 0.98.x -- legacy
>> 1.x -- current
>>
>> Within current, we have
>>
>> 1.0.x -- retired/EOL
>> 1.1.x -- maintenance
>> 1.2.x -- stable
>> 1.3.x -- unstable
>>
>> In time, 1.1 will also retire/EOL, 1.2 will become maintenance, and so on.
>>
>>> On Friday, July 22, 2016, Andrew Purtell <ap...@apache.org> wrote:
>>>
>>> In our last board report we mentioned the several code lines we current
>>> manage and were asked to consider some form of support policy so the
>>> community is able to make informed decisions about which release line to
>>> use.
>>>
>>> The first question is: should we have one?
>>>
>>> The second question, if the answer to the first is 'yes', is what that
>>> policy should be.
>>>
>>>
>>>
>>>
>>> --
>>> Best regards,
>>>
>>> - Andy
>>>
>>> Problems worthy of attack prove their worth by hitting back. - Piet Hein
>>> (via Tom White)
>>
Re: Feedback from the July 2016 board report
Posted by Andrew Purtell <an...@gmail.com>.
On a closely related topic - the retiring of 0.98 - can I ask for your opinions on timeframe to sunsetting? I am happy to continue maintaining it for as long as that would be desirable and useful. On the other hand at some point it's a legacy we need to move on from. If there's some guidance on this let's include it in what we are writing up.
> On Jul 25, 2016, at 11:21 AM, Enis Söztutar <en...@apache.org> wrote:
>
> +1 to above.
>
> This is what I used as a "guide to selecting a release":
> http://www.slideshare.net/enissoz/hbase-state-of-the-union/16?src=clipshare
>
> Should we document this in the book somehow? We should put extra effort to
> keep it up to date.
>
> Enis
>
>> On Fri, Jul 22, 2016 at 6:42 PM, Nick Dimiduk <nd...@gmail.com> wrote:
>>
>> Maybe it's worth spelling out? It will become more obvious once 0.98 is
>> retired. I think of them like this:
>>
>> 0.98.x -- legacy
>> 1.x -- current
>>
>> Within current, we have
>>
>> 1.0.x -- retired/EOL
>> 1.1.x -- maintenance
>> 1.2.x -- stable
>> 1.3.x -- unstable
>>
>> In time, 1.1 will also retire/EOL, 1.2 will become maintenance, and so on.
>>
>>> On Friday, July 22, 2016, Andrew Purtell <ap...@apache.org> wrote:
>>>
>>> In our last board report we mentioned the several code lines we current
>>> manage and were asked to consider some form of support policy so the
>>> community is able to make informed decisions about which release line to
>>> use.
>>>
>>> The first question is: should we have one?
>>>
>>> The second question, if the answer to the first is 'yes', is what that
>>> policy should be.
>>>
>>>
>>>
>>>
>>> --
>>> Best regards,
>>>
>>> - Andy
>>>
>>> Problems worthy of attack prove their worth by hitting back. - Piet Hein
>>> (via Tom White)
>>
Re: Feedback from the July 2016 board report
Posted by Enis Söztutar <en...@apache.org>.
+1 to above.
This is what I used as a "guide to selecting a release":
http://www.slideshare.net/enissoz/hbase-state-of-the-union/16?src=clipshare
Should we document this in the book somehow? We should put extra effort to
keep it up to date.
Enis
On Fri, Jul 22, 2016 at 6:42 PM, Nick Dimiduk <nd...@gmail.com> wrote:
> Maybe it's worth spelling out? It will become more obvious once 0.98 is
> retired. I think of them like this:
>
> 0.98.x -- legacy
> 1.x -- current
>
> Within current, we have
>
> 1.0.x -- retired/EOL
> 1.1.x -- maintenance
> 1.2.x -- stable
> 1.3.x -- unstable
>
> In time, 1.1 will also retire/EOL, 1.2 will become maintenance, and so on.
>
> On Friday, July 22, 2016, Andrew Purtell <ap...@apache.org> wrote:
>
> > In our last board report we mentioned the several code lines we current
> > manage and were asked to consider some form of support policy so the
> > community is able to make informed decisions about which release line to
> > use.
> >
> > The first question is: should we have one?
> >
> > The second question, if the answer to the first is 'yes', is what that
> > policy should be.
> >
> >
> >
> >
> > --
> > Best regards,
> >
> > - Andy
> >
> > Problems worthy of attack prove their worth by hitting back. - Piet Hein
> > (via Tom White)
> >
>
Re: Feedback from the July 2016 board report
Posted by Nick Dimiduk <nd...@gmail.com>.
Maybe it's worth spelling out? It will become more obvious once 0.98 is
retired. I think of them like this:
0.98.x -- legacy
1.x -- current
Within current, we have
1.0.x -- retired/EOL
1.1.x -- maintenance
1.2.x -- stable
1.3.x -- unstable
In time, 1.1 will also retire/EOL, 1.2 will become maintenance, and so on.
On Friday, July 22, 2016, Andrew Purtell <ap...@apache.org> wrote:
> In our last board report we mentioned the several code lines we current
> manage and were asked to consider some form of support policy so the
> community is able to make informed decisions about which release line to
> use.
>
> The first question is: should we have one?
>
> The second question, if the answer to the first is 'yes', is what that
> policy should be.
>
>
>
>
> --
> Best regards,
>
> - Andy
>
> Problems worthy of attack prove their worth by hitting back. - Piet Hein
> (via Tom White)
>