Dear all,
0.20.204.0 will hopefully finish the release process soon, and it is time to
start talking about 205.  As Owen mentioned,
I would like to volunteer as the Release Manager for 0.20.2xx, if that is
acceptable to the community.  I would also like
to suggest some process changes.

By continuing to provide sustaining releases of 0.20-security, the community
helps production users until later versions (v22
and v23) reach stability.  At the same time, we certainly do not wish
0.20-security to be viewed as a "trunk"; it is important
that all patches go in trunk first, and only patches of manageable risk and
high value to production users, should go into
the sustaining releases.

The goal of the following is to assure adequate community participation in
the release process, rather than just a bunch of
Jiras followed by last-minute debate in a Vote thread :-)

It seems that the default assumption has been that any patch committed to
0.20-security would go into the next sustaining
release.  In theory, contributors and committers have the opportunity to
comment in the Jiras if they disagreed.  However,
in practice most people don't follow Jiras for patches other than trunk, and
the number of such patches can add up.

So, to start discussion for the 205 release, I propose the following:

1. Let us look at the list of patches applied to 0.20-security so far, since
204 (see attached document).

2. Contributors and production users who want the various patches should
speak up for them, providing information such as
    - Jira number and title
    - Value to production users
    - Risk and Testability

3. If there are other patches desired in 205 that have not yet been
committed to 0.20-security, potential contributors should
also speak up, providing the same information, and opening new Jiras if
necessary.

Hopefully over the coming week or so we can share all the inputs, and people
will have time to review them and comment.

After the 205 release, I hope we can discuss potential content for 206 in
advance.  Perhaps we can also circulate some
improvements to the Sustaining Release process currently documented in the
wiki.

Thoughts and feedback welcome,
thanks,
--Matt

> At the same time, we certainly do not wish 0.20-security to be viewed as a "trunk"; it is important
that all patches go in trunk first, and only patches of manageable risk and high value to production users, should go into
the sustaining releases.

Matt,

With all due respect, I have heard from "several of your associates", about features for making hbase work with the 0.20.2xx. That sounds to me that 0.20-security to be trunk.

Can you clarify how that is going to work ?

Basically, what are your criteria for "manageable risk and high value to production users" ?

In particular, I would like to know why the insistence on 0.20.2xx being the default branch to check-in these "innovations", instead of trunk.
 *   Milind

---
Milind Bhandarkar
Greenplum Labs, EMC
(Disclaimer: Opinions expressed in this email are those of the author, and do not necessarily represent the views of any organization, past or present, the author might be affiliated with.)

Hi Milind,

I'm really happy to see 0.23 moving along.  This seems like pretty clear evidence that 0.20.xxx is not going to be a new trunk.  However, the time between cutting a new release and being able to run production applications on it can be very long.  0.23 and any alternative such as 0.22 will take a long time to get to the level of quality and stability that is in 0.20.xxx today.  Trunk is looking very healthy to me.  Having a good sustaining program on 0.20.xxx is intended to compliment mainline dev, not replace it.  Describing fixing flush/sync as innovation seems like a stretch.  The patch sets we are considering merging have been in use for more than a year.

There is a large constituency that would like to see HBASE work well now.  I'm hoping to see that happen on 0.20.xxx.  I think this is the best place to invest effort.  You are welcome to work with the community members investing in 0.20.xxx or on an alternative.  There is room in the community for both efforts IMO.

Thanks,

E14
On Aug 24, 2011, at 12:05 AM, <[EMAIL PROTECTED]> wrote:

>> At the same time, we certainly do not wish 0.20-security to be viewed as a "trunk"; it is important
> that all patches go in trunk first, and only patches of manageable risk and high value to production users, should go into
> the sustaining releases.
>
> Matt,
>
> With all due respect, I have heard from "several of your associates", about features for making hbase work with the 0.20.2xx. That sounds to me that 0.20-security to be trunk.
>
> Can you clarify how that is going to work ?
>
> Basically, what are your criteria for "manageable risk and high value to production users" ?
>
> In particular, I would like to know why the insistence on 0.20.2xx being the default branch to check-in these "innovations", instead of trunk.
>
>
> *   Milind
>
> ---
> Milind Bhandarkar
> Greenplum Labs, EMC
> (Disclaimer: Opinions expressed in this email are those of the author, and do not necessarily represent the views of any organization, past or present, the author might be affiliated with.)
>

On Wed, Aug 24, 2011 at 09:32AM, Eric Baldeschwieler wrote:
> Hi Milind,
>
> I'm really happy to see 0.23 moving along.  This seems like pretty clear
> evidence that 0.20.xxx is not going to be a new trunk.  However, the time
> between cutting a new release and being able to run production applications
> on it can be very long.  0.23 and any alternative such as 0.22 will take a
> long time to get to the level of quality and stability that is in 0.20.xxx
> today.  Trunk is looking very healthy to me.  Having a good sustaining

I can bet money that  someone will call it 'a very bad taste' joke in a next
20 minutes, but does it really look healthy with last successful MR trunk
build happened 2 mo 25 days ago?

--
  Take care,
Konstantin (Cos) Boudnik
2CAC 8312 4870 D885 8616  6115 220F 6980 1F27 E622

Disclaimer: Opinions expressed in this email are those of the author, and do
not necessarily represent the views of any company the author might be
affiliated with at the moment of writing.

> program on 0.20.xxx is intended to compliment mainline dev, not replace it.
> Describing fixing flush/sync as innovation seems like a stretch.  The patch
> sets we are considering merging have been in use for more than a year.
>
> There is a large constituency that would like to see HBASE work well now.
> I'm hoping to see that happen on 0.20.xxx.  I think this is the best place
> to invest effort.  You are welcome to work with the community members
> investing in 0.20.xxx or on an alternative.  There is room in the community
> for both efforts IMO.
>
> Thanks,
>
> E14
>
>
> On Aug 24, 2011, at 12:05 AM, <[EMAIL PROTECTED]> wrote:
>
> >> At the same time, we certainly do not wish 0.20-security to be viewed as a "trunk"; it is important
> > that all patches go in trunk first, and only patches of manageable risk and high value to production users, should go into
> > the sustaining releases.
> >
> > Matt,
> >
> > With all due respect, I have heard from "several of your associates", about features for making hbase work with the 0.20.2xx. That sounds to me that 0.20-security to be trunk.
> >
> > Can you clarify how that is going to work ?
> >
> > Basically, what are your criteria for "manageable risk and high value to production users" ?
> >
> > In particular, I would like to know why the insistence on 0.20.2xx being the default branch to check-in these "innovations", instead of trunk.
> >
> >
> > *   Milind
> >
> > ---
> > Milind Bhandarkar
> > Greenplum Labs, EMC
> > (Disclaimer: Opinions expressed in this email are those of the author, and do not necessarily represent the views of any organization, past or present, the author might be affiliated with.)
> >
>

Hi Milind,
Thanks for your response.  If you'll forgive me for reiterating statements
that you've probably heard before, I'll try to
concisely state why the community might consider accepting changes for HBase
compatibility into 0.20.2xx.

It is my understanding that HBase works correctly in trunk (soon to be
branched as v23), with both security and append.
Therefore, making changes in 0.20.2xx to enable HBase to work there, would
not constitute an innovation or new feature
that isn't already in trunk.  Nor is it a new feature relative to 0.20,
since HBase currently works with (and is recommended for
installation with) 0.20-append, which was branched from 0.20.2, and
developed quite a while back.

There are production users of HBase that want to stay with 0.20, since later
releases with security have not yet reached
stability, but also want the security features of 0.20.2xx.  To meet their
needs, it seems reasonable to consider joining
HBase-compatibility features like those of 0.20-append with the
0.20-security branch.  That doesn't seem to be using
0.20-security as a "trunk", although the semantics of that word can of
course be argued.  And it seems to meet the
criterion of high value to production users.

It still has to be asked whether the changes meet the criterion of
manageable risk.  That definitely should be evaluated
after we see the proposed patches.

Does that address your questions?

Regarding the definition of "manageable risk and high value to production
users", I think the community has to decide
that on a case-by-case basis.  Certainly the production users are capable
of expressing their opinions for what they want.
Developers should (and no doubt will) also do so, in the Jiras and in email
threads.

But the most important suggestion in my previous email is that we provide a
forum for such discussions PRE-release,
"up front", rather than only during the release vote.

Best,
--Matt

On Wed, Aug 24, 2011 at 12:05 AM, <[EMAIL PROTECTED]> wrote:

> > At the same time, we certainly do not wish 0.20-security to be viewed as
> a "trunk"; it is important
> that all patches go in trunk first, and only patches of manageable risk and
> high value to production users, should go into
> the sustaining releases.
>
> Matt,
>
> With all due respect, I have heard from "several of your associates", about
> features for making hbase work with the 0.20.2xx. That sounds to me that
> 0.20-security to be trunk.
>
> Can you clarify how that is going to work ?
>
> Basically, what are your criteria for "manageable risk and high value to
> production users" ?
>
> In particular, I would like to know why the insistence on 0.20.2xx being
> the default branch to check-in these "innovations", instead of trunk.
>
>
>  *   Milind
>
> ---
> Milind Bhandarkar
> Greenplum Labs, EMC
> (Disclaimer: Opinions expressed in this email are those of the author, and
> do not necessarily represent the views of any organization, past or present,
> the author might be affiliated with.)
>
>

On Aug 23, 2011, at 5:17 PM, Matt Foley wrote:

> Dear all,
> 0.20.204.0 will hopefully finish the release process soon, and it is time to start talking about 205.  As Owen mentioned,
> I would like to volunteer as the Release Manager for 0.20.2xx, if that is acceptable to the community.  I would also like
> to suggest some process changes.
>
> By continuing to provide sustaining releases of 0.20-security, the community helps production users until later versions (v22
> and v23) reach stability.  At the same time, we certainly do not wish 0.20-security to be viewed as a "trunk"; it is important
> that all patches go in trunk first, and only patches of manageable risk and high value to production users, should go into
> the sustaining releases.
>
> The goal of the following is to assure adequate community participation in the release process, rather than just a bunch of
> Jiras followed by last-minute debate in a Vote thread :-)

Note that the mechanism for encouraging community participation is
very much in the hands of the RM.  So, just do it.  For example,
the file you provided is much like the original STATUS file
that I added to httpd development a long time ago, though I
strongly suggest you commit it to subversion instead of expecting
people to track it in email.  For that matter, I thought Jira has
the ability to track multiple releases already -- why not use the
tracking system directly?

I do feel a need to remind folks: releases are NOT a consensus
decision, but the specific changes allowed within a given release
can be vetoed with a valid technical reason that may be specific
to that release branch (e.g., compatibility concerns are almost
always scoped by version branch).  You should be asking folks to
make any negative opinions known as well, since that is critical
to pruning the tree down to the set of patches that can actually
be placed in front of the group to vote on as a release candidate.

....Roy

Thanks for the prompt response Eric.

I have been traveling, and could reply to you immediately.

How long do you estimate 0.23 (or 0.22) would take to stabilize ? Based on
the past experience of release 0.19, even if it was not deployed at 1000+
node-scale, eventually, it did stabilize, and several small installations
did exist using that release.

With that in mind, and knowing the typical deployment schedules at a large
installation, I would expect 0.23 to be stable for production workloads
next summer. Since that is still 10 months away, do you expect that
sustaining releases on the 0.20.2xx branch to continue until then ?

- milind

On 8/24/11 9:32 AM, "Eric Baldeschwieler" <[EMAIL PROTECTED]> wrote:

>Hi Milind,
>
>I'm really happy to see 0.23 moving along.  This seems like pretty clear
>evidence that 0.20.xxx is not going to be a new trunk.  However, the time
>between cutting a new release and being able to run production
>applications on it can be very long.  0.23 and any alternative such as
>0.22 will take a long time to get to the level of quality and stability
>that is in 0.20.xxx today.  Trunk is looking very healthy to me.  Having
>a good sustaining program on 0.20.xxx is intended to compliment mainline
>dev, not replace it.  Describing fixing flush/sync as innovation seems
>like a stretch.  The patch sets we are considering merging have been in
>use for more than a year.
>
>There is a large constituency that would like to see HBASE work well now.
> I'm hoping to see that happen on 0.20.xxx.  I think this is the best
>place to invest effort.  You are welcome to work with the community
>members investing in 0.20.xxx or on an alternative.  There is room in the
>community for both efforts IMO.
>
>Thanks,
>
>E14
>
>
>On Aug 24, 2011, at 12:05 AM, <[EMAIL PROTECTED]> wrote:
>
>>> At the same time, we certainly do not wish 0.20-security to be viewed
>>>as a "trunk"; it is important
>> that all patches go in trunk first, and only patches of manageable risk
>>and high value to production users, should go into
>> the sustaining releases.
>>
>> Matt,
>>
>> With all due respect, I have heard from "several of your associates",
>>about features for making hbase work with the 0.20.2xx. That sounds to
>>me that 0.20-security to be trunk.
>>
>> Can you clarify how that is going to work ?
>>
>> Basically, what are your criteria for "manageable risk and high value
>>to production users" ?
>>
>> In particular, I would like to know why the insistence on 0.20.2xx
>>being the default branch to check-in these "innovations", instead of
>>trunk.
>>
>>
>> *   Milind
>>
>> ---
>> Milind Bhandarkar
>> Greenplum Labs, EMC
>> (Disclaimer: Opinions expressed in this email are those of the author,
>>and do not necessarily represent the views of any organization, past or
>>present, the author might be affiliated with.)
>>
>
>

>
>
>
>It still has to be asked whether the changes meet the criterion of
>manageable risk.  That definitely should be evaluated
>after we see the proposed patches.

Matt,

As a release manager, it is up to you to decide what the criterion for
inclusion is. And that was what I was asking.

- milind

Hi Milind,

I'd expect to see continued sustaining on the 20 branch until 23 is stable.  Continued bug fixing beyond that if there is need / enthusiasm for such fixes would also seem reasonable. This has certainly been the expect behavior of other released software I've contributed to.

If we want to see apache hadoop widely adopted, it is critical that folks not only volunteer new features, but that someone continue to refine working releases.  I see nothing but upside to this.  If others want to only volunteer new code for trunk or want to work on other releases, that's ok by me.

I don't believe this is a zero sum game.  Any investment I put into 0.20 doesn't block you from putting work into 22 or 23.  We're aligned in the goal of getting 23 and future trunk based releases out.  Asking someone not to do sustaining will not cause them to work faster on other releases, it will just move work out of apache. I don't see how that benefits the community.  If the sustaining work is badly done or does not add value, it can be voted down.

Thanks,

E14

On Aug 25, 2011, at 1:04 PM, <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> wrote:

> Thanks for the prompt response Eric.
>
> I have been traveling, and could reply to you immediately.
>
> How long do you estimate 0.23 (or 0.22) would take to stabilize ? Based on
> the past experience of release 0.19, even if it was not deployed at 1000+
> node-scale, eventually, it did stabilize, and several small installations
> did exist using that release.
>
> With that in mind, and knowing the typical deployment schedules at a large
> installation, I would expect 0.23 to be stable for production workloads
> next summer. Since that is still 10 months away, do you expect that
> sustaining releases on the 0.20.2xx branch to continue until then ?
>
> - milind
>
> On 8/24/11 9:32 AM, "Eric Baldeschwieler" <[EMAIL PROTECTED]> wrote:
>
>> Hi Milind,
>>
>> I'm really happy to see 0.23 moving along.  This seems like pretty clear
>> evidence that 0.20.xxx is not going to be a new trunk.  However, the time
>> between cutting a new release and being able to run production
>> applications on it can be very long.  0.23 and any alternative such as
>> 0.22 will take a long time to get to the level of quality and stability
>> that is in 0.20.xxx today.  Trunk is looking very healthy to me.  Having
>> a good sustaining program on 0.20.xxx is intended to compliment mainline
>> dev, not replace it.  Describing fixing flush/sync as innovation seems
>> like a stretch.  The patch sets we are considering merging have been in
>> use for more than a year.
>>
>> There is a large constituency that would like to see HBASE work well now.
>> I'm hoping to see that happen on 0.20.xxx.  I think this is the best
>> place to invest effort.  You are welcome to work with the community
>> members investing in 0.20.xxx or on an alternative.  There is room in the
>> community for both efforts IMO.
>>
>> Thanks,
>>
>> E14
>>
>>
>> On Aug 24, 2011, at 12:05 AM, <[EMAIL PROTECTED]> wrote:
>>
>>>> At the same time, we certainly do not wish 0.20-security to be viewed
>>>> as a "trunk"; it is important
>>> that all patches go in trunk first, and only patches of manageable risk
>>> and high value to production users, should go into
>>> the sustaining releases.
>>>
>>> Matt,
>>>
>>> With all due respect, I have heard from "several of your associates",
>>> about features for making hbase work with the 0.20.2xx. That sounds to
>>> me that 0.20-security to be trunk.
>>>
>>> Can you clarify how that is going to work ?
>>>
>>> Basically, what are your criteria for "manageable risk and high value
>>> to production users" ?
>>>
>>> In particular, I would like to know why the insistence on 0.20.2xx
>>> being the default branch to check-in these "innovations", instead of
>>> trunk.
>>>
>>>
>>> *   Milind
>>>
>>> ---
>>> Milind Bhandarkar
>>> Greenplum Labs, EMC
>>> (Disclaimer: Opinions expressed in this email are those of the author,

On 31/08/11 07:37, Eric Baldeschwieler wrote:
> Hi Milind,
>
> I'd expect to see continued sustaining on the 20 branch until 23 is stable.  Continued bug fixing beyond that if there is need / enthusiasm for such fixes would also seem reasonable. This has certainly been the expect behavior of other released software I've contributed to.
>
> If we want to see apache hadoop widely adopted, it is critical that folks not only volunteer new features, but that someone continue to refine working releases.  I see nothing but upside to this.  If others want to only volunteer new code for trunk or want to work on other releases, that's ok by me.
>
> I don't believe this is a zero sum game.  Any investment I put into 0.20 doesn't block you from putting work into 22 or 23.  We're aligned in the goal of getting 23 and future trunk based releases out.  Asking someone not to do sustaining will not cause them to work faster on other releases, it will just move work out of apache. I don't see how that benefits the community.  If the sustaining work is badly done or does not add value, it can be voted down.
>
I think
  -all patches should go into trunk then backport to 0.23, 0.22, 0.20.x
if it is deemed important, the criteria for those being things to resolve.

My views

-0.20.x: critical security/stability issues, and critical stack
compatibility issues. Nothing much else.

-0.22 - this isn't discussed, but it's going to be the last pre-MR-279
MR engine. Shouldn't all patches to the mainstream MR engine go in here
first?

-0.23 - subject for discussion. Now that it's into stabilise and ship
it's bug fixes and not features.

Like milind, I worry about time to stabilise for 0.23, but am somewhat
more optimistic than 10+ months, because if there is takeup from some
large hadoop users, stability comes from that use