You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hbase.apache.org by Phil Yang <ya...@apache.org> on 2017/03/09 08:34:08 UTC
A suggestion for releasing major versions faster (Was: NOTICE: Nice
testimony on benefits of the offheap read-path work now up on our blog)
Nice article! Thanks for the authors.
An off-the-topic suggestion to dev list:
Now we commit some big and new features to master branch only, which will
be included in a new major version, for example, 2.0. However, a major
version is not upgraded very quickly, 1.0.0 was released two years ago and
we still don't release 2.0.0. HBASE-11425 is resolved more than one year
ago. In the worst case, if we make some work done and commit to master
branch just after cutting a new major release branch, the feature will be
released two years later or even longer. It is no need and no benefits to
wait so long. Bugs of the new feature in dev branches only are hardly to be
found, and committers may not be familiar with a feature which is committed
two years ago...
So my suggestion is cutting branch-x faster and have some fixed period, for
example, six month or one year?
Thanks,
Phil
2017-03-09 14:24 GMT+08:00 Stack <st...@duboce.net>:
> See writeup on how work done by your Yu Li, Sun Yu, Anoop Sam John, and
> Ramkrishna S Vasudevan improved throughput at scale on Singles Day 2016 @
> Alibaba.
>
> Read all about it at https://blogs.apache.org/hbase/
>
> Yours,
> St.Ack
>
Re: A suggestion for releasing major versions faster (Was: NOTICE:
Nice testimony on benefits of the offheap read-path work now up on our blog)
Posted by "张铎 (Duo Zhang)" <pa...@gmail.com>.
Yeah we have put too much things into the 2.0 release. And I believe there
is a release schedule for 2.0 in the mailing-list?
2017-03-09 16:34 GMT+08:00 Phil Yang <ya...@apache.org>:
> Nice article! Thanks for the authors.
>
> An off-the-topic suggestion to dev list:
>
> Now we commit some big and new features to master branch only, which will
> be included in a new major version, for example, 2.0. However, a major
> version is not upgraded very quickly, 1.0.0 was released two years ago and
> we still don't release 2.0.0. HBASE-11425 is resolved more than one year
> ago. In the worst case, if we make some work done and commit to master
> branch just after cutting a new major release branch, the feature will be
> released two years later or even longer. It is no need and no benefits to
> wait so long. Bugs of the new feature in dev branches only are hardly to be
> found, and committers may not be familiar with a feature which is committed
> two years ago...
>
> So my suggestion is cutting branch-x faster and have some fixed period, for
> example, six month or one year?
>
> Thanks,
> Phil
>
>
> 2017-03-09 14:24 GMT+08:00 Stack <st...@duboce.net>:
>
> > See writeup on how work done by your Yu Li, Sun Yu, Anoop Sam John, and
> > Ramkrishna S Vasudevan improved throughput at scale on Singles Day 2016 @
> > Alibaba.
> >
> > Read all about it at https://blogs.apache.org/hbase/
> >
> > Yours,
> > St.Ack
> >
>
Re: A suggestion for releasing major versions faster (Was: NOTICE:
Nice testimony on benefits of the offheap read-path work now up on our blog)
Posted by "张铎 (Duo Zhang)" <pa...@gmail.com>.
Let's just cut branch-2 ASAP and set a deadline for the partially-completed
features?
2017-03-10 9:29 GMT+08:00 Mikhail Antonov <an...@apache.org>:
> >>"The only way forward for saving 2.0 at this point is to *make the branch
> and spin the RC."
>
> big +1 to that.
>
> I do also think that talking about planning in the context of open-source
> community development is a bit hard - there's no planning but what people
> do. If we release regularly, however, we would naturally be picking
> important things (features, fixes, optimizations), because things that were
> planned but not completed up to some usable checkpoint state were, by the
> very definition, not truly important enough in the grand schema of things.
> From the perspective, releasing regularly is more important than preparing
> a list of must-have things and waiting to cross the last work item out
> before the release can be made.
>
> That does pose a problem of partially-completed features. Two viable ways
> to deal with them that I see are a) use feature branches more and b) don't
> release off master (or, commit new code to some 'unstable' branch first,
> then pull to master).
>
> Thoughts?
>
> -Mikhail
>
> On Thu, Mar 9, 2017 at 1:57 PM, Andrew Purtell <ap...@apache.org>
> wrote:
>
> > > For 2.0 release or future major release, what we need is planning -
> THEME
> > >
> > (what is the biggest excitement for the release) and MUST-HAVE FEATURES.
> > >
> > All must-have features should have an owner and some estimate of
> completing
> > >
> > time.
> >
> > With all due respect, this is just talk. Appeals to planning and "must
> > have" features has an import that decays proportionally to the time since
> > the last time we had some words about it. 2.0 keeps slipping, slipping,
> > slipping. The PMC needs to come to terms with the actual amount of
> > development bandwidth we have available and set a cut point. Make it
> > happen, "do-ocracy" style.
> >
> >
> >
> > On Thu, Mar 9, 2017 at 1:52 PM, Andrew Purtell <ap...@apache.org>
> > wrote:
> >
> > > Oh, I don't know. I may never be comfortable with a backport of MOB
> into
> > > branch-1, but a branch-2 including it would be fine.
> > >
> > > And my point is not that making a branch-2 out of branch-1 is
> desirable,
> > > simply that it could be the most practical way forward if we are stuck
> on
> > > master with too much unfinished work that cannot be reverted in order
> to
> > > make a production ready release.
> > >
> > >
> > > On Thu, Mar 9, 2017 at 1:12 PM, Stephen Jiang <syuanjiangdev@gmail.com
> >
> > > wrote:
> > >
> > >> I don't see a point to have branch-2 from branch-1. For
> customer/users,
> > >> we
> > >> always can have a 1.x release to give them all the features they want
> > from
> > >> branch-1.
> > >>
> > >> My understand is that one of the difference of major release and minor
> > >> release is that major release could break some backward compatibility.
> > If
> > >> any features that in master, but not in branch-1, as long as not
> > breaking
> > >> backward compatible, the owner of the feature always can back-port to
> > >> branch-1 if they desire. Today we don't have voting process to block
> > >> that.
> > >>
> > >> For 2.0 release or future major release, what we need is planning -
> > THEME
> > >> (what is the biggest excitement for the release) and MUST-HAVE
> FEATURES.
> > >> All must-have features should have an owner and some estimate of
> > >> completing
> > >> time. Once the consensus is reached, then next step is execution -
> the
> > >> release time would be based on progress of these must-have features.
> > >>
> > >> Thanks
> > >> Stephen
> > >>
> > >> On Thu, Mar 9, 2017 at 11:53 AM, Ashu Pachauri <as...@gmail.com>
> > >> wrote:
> > >>
> > >> > In my opinion, a major release is based on two simultaneous
> decisions:
> > >> >
> > >> > 1. Is it time; may be a year is a good time frame? (It's useless
> > >> > accumulating too much code that is not battle tested and then expect
> > >> people
> > >> > to deploy it to production without experiencing a plethora of
> issues.)
> > >> >
> > >> > 2. Is there at least one "major feature" that is complete ?
> > >> >
> > >> > I think if we can answer yes to both these questions at any point in
> > >> time,
> > >> > it's a good idea to cut the RC and ask people to start testing it.
> > >> >
> > >> > the only way forward for saving 2.0 at this point is to *make the
> > branch
> > >> > and
> > >> > > spin the RC
> > >> >
> > >> > +1
> > >> >
> > >> >
> > >> > On Thu, Mar 9, 2017 at 11:25 AM, Andrew Purtell <
> apurtell@apache.org>
> > >> > wrote:
> > >> >
> > >> > > The only way forward for saving 2.0 at this point is to *make the
> > >> branch
> > >> > > and spin the RC. *Just do it. Kick out by revert what obviously
> > isn't
> > >> > > ready. Solicit help in getting partially finished things into
> > working
> > >> > > state. Kick them out too if the help does not arrive.
> > >> > >
> > >> > > Maybe too much is in a half done state and the scale of effort for
> > >> those
> > >> > > reverts is too high. Fine. Renumber master as 3.0, and make a
> > branch-2
> > >> > from
> > >> > > branch-1 and backport a select number of things from master into
> the
> > >> new
> > >> > > branch-2. Then release. I do a variation of this for the $dayjob
> so
> > >> would
> > >> > > be your man to turn to for driving this if that's the way forward.
> > >> > >
> > >> > > I know it's easy to recommend the labor of others. Depending on
> what
> > >> we
> > >> > are
> > >> > > going to do I can talk to work about freeing up time to help.
> > >> > >
> > >> > >
> > >> > > On Thu, Mar 9, 2017 at 11:18 AM, Stack <st...@duboce.net> wrote:
> > >> > >
> > >> > > > On Thu, Mar 9, 2017 at 12:34 AM, Phil Yang <
> > yangzhe1991@apache.org>
> > >> > > wrote:
> > >> > > > >
> > >> > > > >
> > >> > > > > So my suggestion is cutting branch-x faster and have some
> fixed
> > >> > period,
> > >> > > > for
> > >> > > > > example, six month or one year?
> > >> > > > >
> > >> > > >
> > >> > > >
> > >> > > > You are right Phil.
> > >> > > >
> > >> > > > The Release Managers for the minor releases have been doing a
> good
> > >> job
> > >> > > > keeping up a decent release cadence but we have an abysmal track
> > >> record
> > >> > > > when it comes to pushing out majors. First we were afraid to
> > commit
> > >> --
> > >> > > > witness how long it took us to get to a 1.0 -- and then pushing
> > out
> > >> the
> > >> > > 1.0
> > >> > > > took a monster effort. 2.0 looks to be a repeat of the errors of
> > >> 1.0.
> > >> > My
> > >> > > > sense is that 2.0 is beyond saving at this stage.
> > >> > > >
> > >> > > > Can we do 3.0 different? As per your suggestion?
> > >> > > >
> > >> > > > St.Ack
> > >> > > >
> > >> > >
> > >> > >
> > >> > >
> > >> > > --
> > >> > > Best regards,
> > >> > >
> > >> > > - Andy
> > >> > >
> > >> > > If you are given a choice, you believe you have acted freely. -
> > >> Raymond
> > >> > > Teller (via Peter Watts)
> > >> > >
> > >> >
> > >> >
> > >> >
> > >> > --
> > >> > Thanks and Regards,
> > >> > Ashu Pachauri
> > >> >
> > >>
> > >
> > >
> > >
> > > --
> > > Best regards,
> > >
> > > - Andy
> > >
> > > If you are given a choice, you believe you have acted freely. - Raymond
> > > Teller (via Peter Watts)
> > >
> >
> >
> >
> > --
> > Best regards,
> >
> > - Andy
> >
> > If you are given a choice, you believe you have acted freely. - Raymond
> > Teller (via Peter Watts)
> >
>
Re: A suggestion for releasing major versions faster (Was: NOTICE:
Nice testimony on benefits of the offheap read-path work now up on our blog)
Posted by Phil Yang <ya...@apache.org>.
> To rephrase myself - I think we shouldn't be taking stance that
> MajorBranchX can't be released until features f1, f2, f2,...fN are all
completed.
Agree, we should not be blocked by any feature.
Some new features don't conflict with current codes, I think we can just
commit to branches and
add a how-to-enable document into HBaseBook/ReleaseNote or enable it by
default, when it is ready.
For the issues that may break the branch to can-not-release state, I think
we should never get them in and open a feature branch,
merge them when they are all ready.
Thanks,
Phil
2017-03-10 9:41 GMT+08:00 Mikhail Antonov <ol...@gmail.com>:
> To rephrase myself - I think we shouldn't be taking stance that
> MajorBranchX can't be released until features f1, f2, f2,...fN are all
> completed.
>
> That's just not going to fly. There will always be features suddenly way
> more complicated than they appeared, features that don't have enough
> manpower behind them, features that are found to be less important then
> they were thought to be.
>
> Instead we probably should say "branch-2 is being cut; (or, in kernel
> parlance, here's merge window dates) whatever didn't make their way into it
> will have a chance to go to branch-2.1, branch-2.2, branch-3".
>
>
>
> On Thu, Mar 9, 2017 at 5:29 PM, Mikhail Antonov <an...@apache.org>
> wrote:
>
> > >>"The only way forward for saving 2.0 at this point is to *make the
> > branch
> > and spin the RC."
> >
> > big +1 to that.
> >
> > I do also think that talking about planning in the context of open-source
> > community development is a bit hard - there's no planning but what people
> > do. If we release regularly, however, we would naturally be picking
> > important things (features, fixes, optimizations), because things that
> were
> > planned but not completed up to some usable checkpoint state were, by the
> > very definition, not truly important enough in the grand schema of
> things.
> > From the perspective, releasing regularly is more important than
> preparing
> > a list of must-have things and waiting to cross the last work item out
> > before the release can be made.
> >
> > That does pose a problem of partially-completed features. Two viable ways
> > to deal with them that I see are a) use feature branches more and b)
> don't
> > release off master (or, commit new code to some 'unstable' branch first,
> > then pull to master).
> >
> > Thoughts?
> >
> > -Mikhail
> >
> > On Thu, Mar 9, 2017 at 1:57 PM, Andrew Purtell <ap...@apache.org>
> > wrote:
> >
> >> > For 2.0 release or future major release, what we need is planning -
> >> THEME
> >> >
> >> (what is the biggest excitement for the release) and MUST-HAVE FEATURES.
> >> >
> >> All must-have features should have an owner and some estimate of
> >> completing
> >> >
> >> time.
> >>
> >> With all due respect, this is just talk. Appeals to planning and "must
> >> have" features has an import that decays proportionally to the time
> since
> >> the last time we had some words about it. 2.0 keeps slipping, slipping,
> >> slipping. The PMC needs to come to terms with the actual amount of
> >> development bandwidth we have available and set a cut point. Make it
> >> happen, "do-ocracy" style.
> >>
> >>
> >>
> >> On Thu, Mar 9, 2017 at 1:52 PM, Andrew Purtell <ap...@apache.org>
> >> wrote:
> >>
> >> > Oh, I don't know. I may never be comfortable with a backport of MOB
> into
> >> > branch-1, but a branch-2 including it would be fine.
> >> >
> >> > And my point is not that making a branch-2 out of branch-1 is
> desirable,
> >> > simply that it could be the most practical way forward if we are stuck
> >> on
> >> > master with too much unfinished work that cannot be reverted in order
> to
> >> > make a production ready release.
> >> >
> >> >
> >> > On Thu, Mar 9, 2017 at 1:12 PM, Stephen Jiang <
> syuanjiangdev@gmail.com>
> >> > wrote:
> >> >
> >> >> I don't see a point to have branch-2 from branch-1. For
> >> customer/users,
> >> >> we
> >> >> always can have a 1.x release to give them all the features they want
> >> from
> >> >> branch-1.
> >> >>
> >> >> My understand is that one of the difference of major release and
> minor
> >> >> release is that major release could break some backward
> >> compatibility. If
> >> >> any features that in master, but not in branch-1, as long as not
> >> breaking
> >> >> backward compatible, the owner of the feature always can back-port to
> >> >> branch-1 if they desire. Today we don't have voting process to block
> >> >> that.
> >> >>
> >> >> For 2.0 release or future major release, what we need is planning -
> >> THEME
> >> >> (what is the biggest excitement for the release) and MUST-HAVE
> >> FEATURES.
> >> >> All must-have features should have an owner and some estimate of
> >> >> completing
> >> >> time. Once the consensus is reached, then next step is execution -
> the
> >> >> release time would be based on progress of these must-have features.
> >> >>
> >> >> Thanks
> >> >> Stephen
> >> >>
> >> >> On Thu, Mar 9, 2017 at 11:53 AM, Ashu Pachauri <ashu210890@gmail.com
> >
> >> >> wrote:
> >> >>
> >> >> > In my opinion, a major release is based on two simultaneous
> >> decisions:
> >> >> >
> >> >> > 1. Is it time; may be a year is a good time frame? (It's useless
> >> >> > accumulating too much code that is not battle tested and then
> expect
> >> >> people
> >> >> > to deploy it to production without experiencing a plethora of
> >> issues.)
> >> >> >
> >> >> > 2. Is there at least one "major feature" that is complete ?
> >> >> >
> >> >> > I think if we can answer yes to both these questions at any point
> in
> >> >> time,
> >> >> > it's a good idea to cut the RC and ask people to start testing it.
> >> >> >
> >> >> > the only way forward for saving 2.0 at this point is to *make the
> >> branch
> >> >> > and
> >> >> > > spin the RC
> >> >> >
> >> >> > +1
> >> >> >
> >> >> >
> >> >> > On Thu, Mar 9, 2017 at 11:25 AM, Andrew Purtell <
> apurtell@apache.org
> >> >
> >> >> > wrote:
> >> >> >
> >> >> > > The only way forward for saving 2.0 at this point is to *make the
> >> >> branch
> >> >> > > and spin the RC. *Just do it. Kick out by revert what obviously
> >> isn't
> >> >> > > ready. Solicit help in getting partially finished things into
> >> working
> >> >> > > state. Kick them out too if the help does not arrive.
> >> >> > >
> >> >> > > Maybe too much is in a half done state and the scale of effort
> for
> >> >> those
> >> >> > > reverts is too high. Fine. Renumber master as 3.0, and make a
> >> branch-2
> >> >> > from
> >> >> > > branch-1 and backport a select number of things from master into
> >> the
> >> >> new
> >> >> > > branch-2. Then release. I do a variation of this for the $dayjob
> so
> >> >> would
> >> >> > > be your man to turn to for driving this if that's the way
> forward.
> >> >> > >
> >> >> > > I know it's easy to recommend the labor of others. Depending on
> >> what
> >> >> we
> >> >> > are
> >> >> > > going to do I can talk to work about freeing up time to help.
> >> >> > >
> >> >> > >
> >> >> > > On Thu, Mar 9, 2017 at 11:18 AM, Stack <st...@duboce.net> wrote:
> >> >> > >
> >> >> > > > On Thu, Mar 9, 2017 at 12:34 AM, Phil Yang <
> >> yangzhe1991@apache.org>
> >> >> > > wrote:
> >> >> > > > >
> >> >> > > > >
> >> >> > > > > So my suggestion is cutting branch-x faster and have some
> fixed
> >> >> > period,
> >> >> > > > for
> >> >> > > > > example, six month or one year?
> >> >> > > > >
> >> >> > > >
> >> >> > > >
> >> >> > > > You are right Phil.
> >> >> > > >
> >> >> > > > The Release Managers for the minor releases have been doing a
> >> good
> >> >> job
> >> >> > > > keeping up a decent release cadence but we have an abysmal
> track
> >> >> record
> >> >> > > > when it comes to pushing out majors. First we were afraid to
> >> commit
> >> >> --
> >> >> > > > witness how long it took us to get to a 1.0 -- and then pushing
> >> out
> >> >> the
> >> >> > > 1.0
> >> >> > > > took a monster effort. 2.0 looks to be a repeat of the errors
> of
> >> >> 1.0.
> >> >> > My
> >> >> > > > sense is that 2.0 is beyond saving at this stage.
> >> >> > > >
> >> >> > > > Can we do 3.0 different? As per your suggestion?
> >> >> > > >
> >> >> > > > St.Ack
> >> >> > > >
> >> >> > >
> >> >> > >
> >> >> > >
> >> >> > > --
> >> >> > > Best regards,
> >> >> > >
> >> >> > > - Andy
> >> >> > >
> >> >> > > If you are given a choice, you believe you have acted freely. -
> >> >> Raymond
> >> >> > > Teller (via Peter Watts)
> >> >> > >
> >> >> >
> >> >> >
> >> >> >
> >> >> > --
> >> >> > Thanks and Regards,
> >> >> > Ashu Pachauri
> >> >> >
> >> >>
> >> >
> >> >
> >> >
> >> > --
> >> > Best regards,
> >> >
> >> > - Andy
> >> >
> >> > If you are given a choice, you believe you have acted freely. -
> Raymond
> >> > Teller (via Peter Watts)
> >> >
> >>
> >>
> >>
> >> --
> >> Best regards,
> >>
> >> - Andy
> >>
> >> If you are given a choice, you believe you have acted freely. - Raymond
> >> Teller (via Peter Watts)
> >>
> >
> >
>
>
> --
> Thanks,
> Michael Antonov
>
Re: A suggestion for releasing major versions faster (Was: NOTICE:
Nice testimony on benefits of the offheap read-path work now up on our blog)
Posted by Mikhail Antonov <ol...@gmail.com>.
To rephrase myself - I think we shouldn't be taking stance that
MajorBranchX can't be released until features f1, f2, f2,...fN are all
completed.
That's just not going to fly. There will always be features suddenly way
more complicated than they appeared, features that don't have enough
manpower behind them, features that are found to be less important then
they were thought to be.
Instead we probably should say "branch-2 is being cut; (or, in kernel
parlance, here's merge window dates) whatever didn't make their way into it
will have a chance to go to branch-2.1, branch-2.2, branch-3".
On Thu, Mar 9, 2017 at 5:29 PM, Mikhail Antonov <an...@apache.org> wrote:
> >>"The only way forward for saving 2.0 at this point is to *make the
> branch
> and spin the RC."
>
> big +1 to that.
>
> I do also think that talking about planning in the context of open-source
> community development is a bit hard - there's no planning but what people
> do. If we release regularly, however, we would naturally be picking
> important things (features, fixes, optimizations), because things that were
> planned but not completed up to some usable checkpoint state were, by the
> very definition, not truly important enough in the grand schema of things.
> From the perspective, releasing regularly is more important than preparing
> a list of must-have things and waiting to cross the last work item out
> before the release can be made.
>
> That does pose a problem of partially-completed features. Two viable ways
> to deal with them that I see are a) use feature branches more and b) don't
> release off master (or, commit new code to some 'unstable' branch first,
> then pull to master).
>
> Thoughts?
>
> -Mikhail
>
> On Thu, Mar 9, 2017 at 1:57 PM, Andrew Purtell <ap...@apache.org>
> wrote:
>
>> > For 2.0 release or future major release, what we need is planning -
>> THEME
>> >
>> (what is the biggest excitement for the release) and MUST-HAVE FEATURES.
>> >
>> All must-have features should have an owner and some estimate of
>> completing
>> >
>> time.
>>
>> With all due respect, this is just talk. Appeals to planning and "must
>> have" features has an import that decays proportionally to the time since
>> the last time we had some words about it. 2.0 keeps slipping, slipping,
>> slipping. The PMC needs to come to terms with the actual amount of
>> development bandwidth we have available and set a cut point. Make it
>> happen, "do-ocracy" style.
>>
>>
>>
>> On Thu, Mar 9, 2017 at 1:52 PM, Andrew Purtell <ap...@apache.org>
>> wrote:
>>
>> > Oh, I don't know. I may never be comfortable with a backport of MOB into
>> > branch-1, but a branch-2 including it would be fine.
>> >
>> > And my point is not that making a branch-2 out of branch-1 is desirable,
>> > simply that it could be the most practical way forward if we are stuck
>> on
>> > master with too much unfinished work that cannot be reverted in order to
>> > make a production ready release.
>> >
>> >
>> > On Thu, Mar 9, 2017 at 1:12 PM, Stephen Jiang <sy...@gmail.com>
>> > wrote:
>> >
>> >> I don't see a point to have branch-2 from branch-1. For
>> customer/users,
>> >> we
>> >> always can have a 1.x release to give them all the features they want
>> from
>> >> branch-1.
>> >>
>> >> My understand is that one of the difference of major release and minor
>> >> release is that major release could break some backward
>> compatibility. If
>> >> any features that in master, but not in branch-1, as long as not
>> breaking
>> >> backward compatible, the owner of the feature always can back-port to
>> >> branch-1 if they desire. Today we don't have voting process to block
>> >> that.
>> >>
>> >> For 2.0 release or future major release, what we need is planning -
>> THEME
>> >> (what is the biggest excitement for the release) and MUST-HAVE
>> FEATURES.
>> >> All must-have features should have an owner and some estimate of
>> >> completing
>> >> time. Once the consensus is reached, then next step is execution - the
>> >> release time would be based on progress of these must-have features.
>> >>
>> >> Thanks
>> >> Stephen
>> >>
>> >> On Thu, Mar 9, 2017 at 11:53 AM, Ashu Pachauri <as...@gmail.com>
>> >> wrote:
>> >>
>> >> > In my opinion, a major release is based on two simultaneous
>> decisions:
>> >> >
>> >> > 1. Is it time; may be a year is a good time frame? (It's useless
>> >> > accumulating too much code that is not battle tested and then expect
>> >> people
>> >> > to deploy it to production without experiencing a plethora of
>> issues.)
>> >> >
>> >> > 2. Is there at least one "major feature" that is complete ?
>> >> >
>> >> > I think if we can answer yes to both these questions at any point in
>> >> time,
>> >> > it's a good idea to cut the RC and ask people to start testing it.
>> >> >
>> >> > the only way forward for saving 2.0 at this point is to *make the
>> branch
>> >> > and
>> >> > > spin the RC
>> >> >
>> >> > +1
>> >> >
>> >> >
>> >> > On Thu, Mar 9, 2017 at 11:25 AM, Andrew Purtell <apurtell@apache.org
>> >
>> >> > wrote:
>> >> >
>> >> > > The only way forward for saving 2.0 at this point is to *make the
>> >> branch
>> >> > > and spin the RC. *Just do it. Kick out by revert what obviously
>> isn't
>> >> > > ready. Solicit help in getting partially finished things into
>> working
>> >> > > state. Kick them out too if the help does not arrive.
>> >> > >
>> >> > > Maybe too much is in a half done state and the scale of effort for
>> >> those
>> >> > > reverts is too high. Fine. Renumber master as 3.0, and make a
>> branch-2
>> >> > from
>> >> > > branch-1 and backport a select number of things from master into
>> the
>> >> new
>> >> > > branch-2. Then release. I do a variation of this for the $dayjob so
>> >> would
>> >> > > be your man to turn to for driving this if that's the way forward.
>> >> > >
>> >> > > I know it's easy to recommend the labor of others. Depending on
>> what
>> >> we
>> >> > are
>> >> > > going to do I can talk to work about freeing up time to help.
>> >> > >
>> >> > >
>> >> > > On Thu, Mar 9, 2017 at 11:18 AM, Stack <st...@duboce.net> wrote:
>> >> > >
>> >> > > > On Thu, Mar 9, 2017 at 12:34 AM, Phil Yang <
>> yangzhe1991@apache.org>
>> >> > > wrote:
>> >> > > > >
>> >> > > > >
>> >> > > > > So my suggestion is cutting branch-x faster and have some fixed
>> >> > period,
>> >> > > > for
>> >> > > > > example, six month or one year?
>> >> > > > >
>> >> > > >
>> >> > > >
>> >> > > > You are right Phil.
>> >> > > >
>> >> > > > The Release Managers for the minor releases have been doing a
>> good
>> >> job
>> >> > > > keeping up a decent release cadence but we have an abysmal track
>> >> record
>> >> > > > when it comes to pushing out majors. First we were afraid to
>> commit
>> >> --
>> >> > > > witness how long it took us to get to a 1.0 -- and then pushing
>> out
>> >> the
>> >> > > 1.0
>> >> > > > took a monster effort. 2.0 looks to be a repeat of the errors of
>> >> 1.0.
>> >> > My
>> >> > > > sense is that 2.0 is beyond saving at this stage.
>> >> > > >
>> >> > > > Can we do 3.0 different? As per your suggestion?
>> >> > > >
>> >> > > > St.Ack
>> >> > > >
>> >> > >
>> >> > >
>> >> > >
>> >> > > --
>> >> > > Best regards,
>> >> > >
>> >> > > - Andy
>> >> > >
>> >> > > If you are given a choice, you believe you have acted freely. -
>> >> Raymond
>> >> > > Teller (via Peter Watts)
>> >> > >
>> >> >
>> >> >
>> >> >
>> >> > --
>> >> > Thanks and Regards,
>> >> > Ashu Pachauri
>> >> >
>> >>
>> >
>> >
>> >
>> > --
>> > Best regards,
>> >
>> > - Andy
>> >
>> > If you are given a choice, you believe you have acted freely. - Raymond
>> > Teller (via Peter Watts)
>> >
>>
>>
>>
>> --
>> Best regards,
>>
>> - Andy
>>
>> If you are given a choice, you believe you have acted freely. - Raymond
>> Teller (via Peter Watts)
>>
>
>
--
Thanks,
Michael Antonov
Re: A suggestion for releasing major versions faster (Was: NOTICE:
Nice testimony on benefits of the offheap read-path work now up on our blog)
Posted by Mikhail Antonov <an...@apache.org>.
>>"The only way forward for saving 2.0 at this point is to *make the branch
and spin the RC."
big +1 to that.
I do also think that talking about planning in the context of open-source
community development is a bit hard - there's no planning but what people
do. If we release regularly, however, we would naturally be picking
important things (features, fixes, optimizations), because things that were
planned but not completed up to some usable checkpoint state were, by the
very definition, not truly important enough in the grand schema of things.
From the perspective, releasing regularly is more important than preparing
a list of must-have things and waiting to cross the last work item out
before the release can be made.
That does pose a problem of partially-completed features. Two viable ways
to deal with them that I see are a) use feature branches more and b) don't
release off master (or, commit new code to some 'unstable' branch first,
then pull to master).
Thoughts?
-Mikhail
On Thu, Mar 9, 2017 at 1:57 PM, Andrew Purtell <ap...@apache.org> wrote:
> > For 2.0 release or future major release, what we need is planning - THEME
> >
> (what is the biggest excitement for the release) and MUST-HAVE FEATURES.
> >
> All must-have features should have an owner and some estimate of completing
> >
> time.
>
> With all due respect, this is just talk. Appeals to planning and "must
> have" features has an import that decays proportionally to the time since
> the last time we had some words about it. 2.0 keeps slipping, slipping,
> slipping. The PMC needs to come to terms with the actual amount of
> development bandwidth we have available and set a cut point. Make it
> happen, "do-ocracy" style.
>
>
>
> On Thu, Mar 9, 2017 at 1:52 PM, Andrew Purtell <ap...@apache.org>
> wrote:
>
> > Oh, I don't know. I may never be comfortable with a backport of MOB into
> > branch-1, but a branch-2 including it would be fine.
> >
> > And my point is not that making a branch-2 out of branch-1 is desirable,
> > simply that it could be the most practical way forward if we are stuck on
> > master with too much unfinished work that cannot be reverted in order to
> > make a production ready release.
> >
> >
> > On Thu, Mar 9, 2017 at 1:12 PM, Stephen Jiang <sy...@gmail.com>
> > wrote:
> >
> >> I don't see a point to have branch-2 from branch-1. For customer/users,
> >> we
> >> always can have a 1.x release to give them all the features they want
> from
> >> branch-1.
> >>
> >> My understand is that one of the difference of major release and minor
> >> release is that major release could break some backward compatibility.
> If
> >> any features that in master, but not in branch-1, as long as not
> breaking
> >> backward compatible, the owner of the feature always can back-port to
> >> branch-1 if they desire. Today we don't have voting process to block
> >> that.
> >>
> >> For 2.0 release or future major release, what we need is planning -
> THEME
> >> (what is the biggest excitement for the release) and MUST-HAVE FEATURES.
> >> All must-have features should have an owner and some estimate of
> >> completing
> >> time. Once the consensus is reached, then next step is execution - the
> >> release time would be based on progress of these must-have features.
> >>
> >> Thanks
> >> Stephen
> >>
> >> On Thu, Mar 9, 2017 at 11:53 AM, Ashu Pachauri <as...@gmail.com>
> >> wrote:
> >>
> >> > In my opinion, a major release is based on two simultaneous decisions:
> >> >
> >> > 1. Is it time; may be a year is a good time frame? (It's useless
> >> > accumulating too much code that is not battle tested and then expect
> >> people
> >> > to deploy it to production without experiencing a plethora of issues.)
> >> >
> >> > 2. Is there at least one "major feature" that is complete ?
> >> >
> >> > I think if we can answer yes to both these questions at any point in
> >> time,
> >> > it's a good idea to cut the RC and ask people to start testing it.
> >> >
> >> > the only way forward for saving 2.0 at this point is to *make the
> branch
> >> > and
> >> > > spin the RC
> >> >
> >> > +1
> >> >
> >> >
> >> > On Thu, Mar 9, 2017 at 11:25 AM, Andrew Purtell <ap...@apache.org>
> >> > wrote:
> >> >
> >> > > The only way forward for saving 2.0 at this point is to *make the
> >> branch
> >> > > and spin the RC. *Just do it. Kick out by revert what obviously
> isn't
> >> > > ready. Solicit help in getting partially finished things into
> working
> >> > > state. Kick them out too if the help does not arrive.
> >> > >
> >> > > Maybe too much is in a half done state and the scale of effort for
> >> those
> >> > > reverts is too high. Fine. Renumber master as 3.0, and make a
> branch-2
> >> > from
> >> > > branch-1 and backport a select number of things from master into the
> >> new
> >> > > branch-2. Then release. I do a variation of this for the $dayjob so
> >> would
> >> > > be your man to turn to for driving this if that's the way forward.
> >> > >
> >> > > I know it's easy to recommend the labor of others. Depending on what
> >> we
> >> > are
> >> > > going to do I can talk to work about freeing up time to help.
> >> > >
> >> > >
> >> > > On Thu, Mar 9, 2017 at 11:18 AM, Stack <st...@duboce.net> wrote:
> >> > >
> >> > > > On Thu, Mar 9, 2017 at 12:34 AM, Phil Yang <
> yangzhe1991@apache.org>
> >> > > wrote:
> >> > > > >
> >> > > > >
> >> > > > > So my suggestion is cutting branch-x faster and have some fixed
> >> > period,
> >> > > > for
> >> > > > > example, six month or one year?
> >> > > > >
> >> > > >
> >> > > >
> >> > > > You are right Phil.
> >> > > >
> >> > > > The Release Managers for the minor releases have been doing a good
> >> job
> >> > > > keeping up a decent release cadence but we have an abysmal track
> >> record
> >> > > > when it comes to pushing out majors. First we were afraid to
> commit
> >> --
> >> > > > witness how long it took us to get to a 1.0 -- and then pushing
> out
> >> the
> >> > > 1.0
> >> > > > took a monster effort. 2.0 looks to be a repeat of the errors of
> >> 1.0.
> >> > My
> >> > > > sense is that 2.0 is beyond saving at this stage.
> >> > > >
> >> > > > Can we do 3.0 different? As per your suggestion?
> >> > > >
> >> > > > St.Ack
> >> > > >
> >> > >
> >> > >
> >> > >
> >> > > --
> >> > > Best regards,
> >> > >
> >> > > - Andy
> >> > >
> >> > > If you are given a choice, you believe you have acted freely. -
> >> Raymond
> >> > > Teller (via Peter Watts)
> >> > >
> >> >
> >> >
> >> >
> >> > --
> >> > Thanks and Regards,
> >> > Ashu Pachauri
> >> >
> >>
> >
> >
> >
> > --
> > Best regards,
> >
> > - Andy
> >
> > If you are given a choice, you believe you have acted freely. - Raymond
> > Teller (via Peter Watts)
> >
>
>
>
> --
> Best regards,
>
> - Andy
>
> If you are given a choice, you believe you have acted freely. - Raymond
> Teller (via Peter Watts)
>
Re: A suggestion for releasing major versions faster (Was: NOTICE:
Nice testimony on benefits of the offheap read-path work now up on our blog)
Posted by Andrew Purtell <ap...@apache.org>.
> For 2.0 release or future major release, what we need is planning - THEME
>
(what is the biggest excitement for the release) and MUST-HAVE FEATURES.
>
All must-have features should have an owner and some estimate of completing
>
time.
With all due respect, this is just talk. Appeals to planning and "must
have" features has an import that decays proportionally to the time since
the last time we had some words about it. 2.0 keeps slipping, slipping,
slipping. The PMC needs to come to terms with the actual amount of
development bandwidth we have available and set a cut point. Make it
happen, "do-ocracy" style.
On Thu, Mar 9, 2017 at 1:52 PM, Andrew Purtell <ap...@apache.org> wrote:
> Oh, I don't know. I may never be comfortable with a backport of MOB into
> branch-1, but a branch-2 including it would be fine.
>
> And my point is not that making a branch-2 out of branch-1 is desirable,
> simply that it could be the most practical way forward if we are stuck on
> master with too much unfinished work that cannot be reverted in order to
> make a production ready release.
>
>
> On Thu, Mar 9, 2017 at 1:12 PM, Stephen Jiang <sy...@gmail.com>
> wrote:
>
>> I don't see a point to have branch-2 from branch-1. For customer/users,
>> we
>> always can have a 1.x release to give them all the features they want from
>> branch-1.
>>
>> My understand is that one of the difference of major release and minor
>> release is that major release could break some backward compatibility. If
>> any features that in master, but not in branch-1, as long as not breaking
>> backward compatible, the owner of the feature always can back-port to
>> branch-1 if they desire. Today we don't have voting process to block
>> that.
>>
>> For 2.0 release or future major release, what we need is planning - THEME
>> (what is the biggest excitement for the release) and MUST-HAVE FEATURES.
>> All must-have features should have an owner and some estimate of
>> completing
>> time. Once the consensus is reached, then next step is execution - the
>> release time would be based on progress of these must-have features.
>>
>> Thanks
>> Stephen
>>
>> On Thu, Mar 9, 2017 at 11:53 AM, Ashu Pachauri <as...@gmail.com>
>> wrote:
>>
>> > In my opinion, a major release is based on two simultaneous decisions:
>> >
>> > 1. Is it time; may be a year is a good time frame? (It's useless
>> > accumulating too much code that is not battle tested and then expect
>> people
>> > to deploy it to production without experiencing a plethora of issues.)
>> >
>> > 2. Is there at least one "major feature" that is complete ?
>> >
>> > I think if we can answer yes to both these questions at any point in
>> time,
>> > it's a good idea to cut the RC and ask people to start testing it.
>> >
>> > the only way forward for saving 2.0 at this point is to *make the branch
>> > and
>> > > spin the RC
>> >
>> > +1
>> >
>> >
>> > On Thu, Mar 9, 2017 at 11:25 AM, Andrew Purtell <ap...@apache.org>
>> > wrote:
>> >
>> > > The only way forward for saving 2.0 at this point is to *make the
>> branch
>> > > and spin the RC. *Just do it. Kick out by revert what obviously isn't
>> > > ready. Solicit help in getting partially finished things into working
>> > > state. Kick them out too if the help does not arrive.
>> > >
>> > > Maybe too much is in a half done state and the scale of effort for
>> those
>> > > reverts is too high. Fine. Renumber master as 3.0, and make a branch-2
>> > from
>> > > branch-1 and backport a select number of things from master into the
>> new
>> > > branch-2. Then release. I do a variation of this for the $dayjob so
>> would
>> > > be your man to turn to for driving this if that's the way forward.
>> > >
>> > > I know it's easy to recommend the labor of others. Depending on what
>> we
>> > are
>> > > going to do I can talk to work about freeing up time to help.
>> > >
>> > >
>> > > On Thu, Mar 9, 2017 at 11:18 AM, Stack <st...@duboce.net> wrote:
>> > >
>> > > > On Thu, Mar 9, 2017 at 12:34 AM, Phil Yang <ya...@apache.org>
>> > > wrote:
>> > > > >
>> > > > >
>> > > > > So my suggestion is cutting branch-x faster and have some fixed
>> > period,
>> > > > for
>> > > > > example, six month or one year?
>> > > > >
>> > > >
>> > > >
>> > > > You are right Phil.
>> > > >
>> > > > The Release Managers for the minor releases have been doing a good
>> job
>> > > > keeping up a decent release cadence but we have an abysmal track
>> record
>> > > > when it comes to pushing out majors. First we were afraid to commit
>> --
>> > > > witness how long it took us to get to a 1.0 -- and then pushing out
>> the
>> > > 1.0
>> > > > took a monster effort. 2.0 looks to be a repeat of the errors of
>> 1.0.
>> > My
>> > > > sense is that 2.0 is beyond saving at this stage.
>> > > >
>> > > > Can we do 3.0 different? As per your suggestion?
>> > > >
>> > > > St.Ack
>> > > >
>> > >
>> > >
>> > >
>> > > --
>> > > Best regards,
>> > >
>> > > - Andy
>> > >
>> > > If you are given a choice, you believe you have acted freely. -
>> Raymond
>> > > Teller (via Peter Watts)
>> > >
>> >
>> >
>> >
>> > --
>> > Thanks and Regards,
>> > Ashu Pachauri
>> >
>>
>
>
>
> --
> Best regards,
>
> - Andy
>
> If you are given a choice, you believe you have acted freely. - Raymond
> Teller (via Peter Watts)
>
--
Best regards,
- Andy
If you are given a choice, you believe you have acted freely. - Raymond
Teller (via Peter Watts)
Re: A suggestion for releasing major versions faster (Was: NOTICE:
Nice testimony on benefits of the offheap read-path work now up on our blog)
Posted by Andrew Purtell <ap...@apache.org>.
Oh, I don't know. I may never be comfortable with a backport of MOB into
branch-1, but a branch-2 including it would be fine.
And my point is not that making a branch-2 out of branch-1 is desirable,
simply that it could be the most practical way forward if we are stuck on
master with too much unfinished work that cannot be reverted in order to
make a production ready release.
On Thu, Mar 9, 2017 at 1:12 PM, Stephen Jiang <sy...@gmail.com>
wrote:
> I don't see a point to have branch-2 from branch-1. For customer/users, we
> always can have a 1.x release to give them all the features they want from
> branch-1.
>
> My understand is that one of the difference of major release and minor
> release is that major release could break some backward compatibility. If
> any features that in master, but not in branch-1, as long as not breaking
> backward compatible, the owner of the feature always can back-port to
> branch-1 if they desire. Today we don't have voting process to block that.
>
> For 2.0 release or future major release, what we need is planning - THEME
> (what is the biggest excitement for the release) and MUST-HAVE FEATURES.
> All must-have features should have an owner and some estimate of completing
> time. Once the consensus is reached, then next step is execution - the
> release time would be based on progress of these must-have features.
>
> Thanks
> Stephen
>
> On Thu, Mar 9, 2017 at 11:53 AM, Ashu Pachauri <as...@gmail.com>
> wrote:
>
> > In my opinion, a major release is based on two simultaneous decisions:
> >
> > 1. Is it time; may be a year is a good time frame? (It's useless
> > accumulating too much code that is not battle tested and then expect
> people
> > to deploy it to production without experiencing a plethora of issues.)
> >
> > 2. Is there at least one "major feature" that is complete ?
> >
> > I think if we can answer yes to both these questions at any point in
> time,
> > it's a good idea to cut the RC and ask people to start testing it.
> >
> > the only way forward for saving 2.0 at this point is to *make the branch
> > and
> > > spin the RC
> >
> > +1
> >
> >
> > On Thu, Mar 9, 2017 at 11:25 AM, Andrew Purtell <ap...@apache.org>
> > wrote:
> >
> > > The only way forward for saving 2.0 at this point is to *make the
> branch
> > > and spin the RC. *Just do it. Kick out by revert what obviously isn't
> > > ready. Solicit help in getting partially finished things into working
> > > state. Kick them out too if the help does not arrive.
> > >
> > > Maybe too much is in a half done state and the scale of effort for
> those
> > > reverts is too high. Fine. Renumber master as 3.0, and make a branch-2
> > from
> > > branch-1 and backport a select number of things from master into the
> new
> > > branch-2. Then release. I do a variation of this for the $dayjob so
> would
> > > be your man to turn to for driving this if that's the way forward.
> > >
> > > I know it's easy to recommend the labor of others. Depending on what we
> > are
> > > going to do I can talk to work about freeing up time to help.
> > >
> > >
> > > On Thu, Mar 9, 2017 at 11:18 AM, Stack <st...@duboce.net> wrote:
> > >
> > > > On Thu, Mar 9, 2017 at 12:34 AM, Phil Yang <ya...@apache.org>
> > > wrote:
> > > > >
> > > > >
> > > > > So my suggestion is cutting branch-x faster and have some fixed
> > period,
> > > > for
> > > > > example, six month or one year?
> > > > >
> > > >
> > > >
> > > > You are right Phil.
> > > >
> > > > The Release Managers for the minor releases have been doing a good
> job
> > > > keeping up a decent release cadence but we have an abysmal track
> record
> > > > when it comes to pushing out majors. First we were afraid to commit
> --
> > > > witness how long it took us to get to a 1.0 -- and then pushing out
> the
> > > 1.0
> > > > took a monster effort. 2.0 looks to be a repeat of the errors of 1.0.
> > My
> > > > sense is that 2.0 is beyond saving at this stage.
> > > >
> > > > Can we do 3.0 different? As per your suggestion?
> > > >
> > > > St.Ack
> > > >
> > >
> > >
> > >
> > > --
> > > Best regards,
> > >
> > > - Andy
> > >
> > > If you are given a choice, you believe you have acted freely. - Raymond
> > > Teller (via Peter Watts)
> > >
> >
> >
> >
> > --
> > Thanks and Regards,
> > Ashu Pachauri
> >
>
--
Best regards,
- Andy
If you are given a choice, you believe you have acted freely. - Raymond
Teller (via Peter Watts)
Re: A suggestion for releasing major versions faster (Was: NOTICE:
Nice testimony on benefits of the offheap read-path work now up on our blog)
Posted by Stephen Jiang <sy...@gmail.com>.
I don't see a point to have branch-2 from branch-1. For customer/users, we
always can have a 1.x release to give them all the features they want from
branch-1.
My understand is that one of the difference of major release and minor
release is that major release could break some backward compatibility. If
any features that in master, but not in branch-1, as long as not breaking
backward compatible, the owner of the feature always can back-port to
branch-1 if they desire. Today we don't have voting process to block that.
For 2.0 release or future major release, what we need is planning - THEME
(what is the biggest excitement for the release) and MUST-HAVE FEATURES.
All must-have features should have an owner and some estimate of completing
time. Once the consensus is reached, then next step is execution - the
release time would be based on progress of these must-have features.
Thanks
Stephen
On Thu, Mar 9, 2017 at 11:53 AM, Ashu Pachauri <as...@gmail.com> wrote:
> In my opinion, a major release is based on two simultaneous decisions:
>
> 1. Is it time; may be a year is a good time frame? (It's useless
> accumulating too much code that is not battle tested and then expect people
> to deploy it to production without experiencing a plethora of issues.)
>
> 2. Is there at least one "major feature" that is complete ?
>
> I think if we can answer yes to both these questions at any point in time,
> it's a good idea to cut the RC and ask people to start testing it.
>
> the only way forward for saving 2.0 at this point is to *make the branch
> and
> > spin the RC
>
> +1
>
>
> On Thu, Mar 9, 2017 at 11:25 AM, Andrew Purtell <ap...@apache.org>
> wrote:
>
> > The only way forward for saving 2.0 at this point is to *make the branch
> > and spin the RC. *Just do it. Kick out by revert what obviously isn't
> > ready. Solicit help in getting partially finished things into working
> > state. Kick them out too if the help does not arrive.
> >
> > Maybe too much is in a half done state and the scale of effort for those
> > reverts is too high. Fine. Renumber master as 3.0, and make a branch-2
> from
> > branch-1 and backport a select number of things from master into the new
> > branch-2. Then release. I do a variation of this for the $dayjob so would
> > be your man to turn to for driving this if that's the way forward.
> >
> > I know it's easy to recommend the labor of others. Depending on what we
> are
> > going to do I can talk to work about freeing up time to help.
> >
> >
> > On Thu, Mar 9, 2017 at 11:18 AM, Stack <st...@duboce.net> wrote:
> >
> > > On Thu, Mar 9, 2017 at 12:34 AM, Phil Yang <ya...@apache.org>
> > wrote:
> > > >
> > > >
> > > > So my suggestion is cutting branch-x faster and have some fixed
> period,
> > > for
> > > > example, six month or one year?
> > > >
> > >
> > >
> > > You are right Phil.
> > >
> > > The Release Managers for the minor releases have been doing a good job
> > > keeping up a decent release cadence but we have an abysmal track record
> > > when it comes to pushing out majors. First we were afraid to commit --
> > > witness how long it took us to get to a 1.0 -- and then pushing out the
> > 1.0
> > > took a monster effort. 2.0 looks to be a repeat of the errors of 1.0.
> My
> > > sense is that 2.0 is beyond saving at this stage.
> > >
> > > Can we do 3.0 different? As per your suggestion?
> > >
> > > St.Ack
> > >
> >
> >
> >
> > --
> > Best regards,
> >
> > - Andy
> >
> > If you are given a choice, you believe you have acted freely. - Raymond
> > Teller (via Peter Watts)
> >
>
>
>
> --
> Thanks and Regards,
> Ashu Pachauri
>
Re: A suggestion for releasing major versions faster (Was: NOTICE:
Nice testimony on benefits of the offheap read-path work now up on our blog)
Posted by Ashu Pachauri <as...@gmail.com>.
In my opinion, a major release is based on two simultaneous decisions:
1. Is it time; may be a year is a good time frame? (It's useless
accumulating too much code that is not battle tested and then expect people
to deploy it to production without experiencing a plethora of issues.)
2. Is there at least one "major feature" that is complete ?
I think if we can answer yes to both these questions at any point in time,
it's a good idea to cut the RC and ask people to start testing it.
the only way forward for saving 2.0 at this point is to *make the branch and
> spin the RC
+1
On Thu, Mar 9, 2017 at 11:25 AM, Andrew Purtell <ap...@apache.org> wrote:
> The only way forward for saving 2.0 at this point is to *make the branch
> and spin the RC. *Just do it. Kick out by revert what obviously isn't
> ready. Solicit help in getting partially finished things into working
> state. Kick them out too if the help does not arrive.
>
> Maybe too much is in a half done state and the scale of effort for those
> reverts is too high. Fine. Renumber master as 3.0, and make a branch-2 from
> branch-1 and backport a select number of things from master into the new
> branch-2. Then release. I do a variation of this for the $dayjob so would
> be your man to turn to for driving this if that's the way forward.
>
> I know it's easy to recommend the labor of others. Depending on what we are
> going to do I can talk to work about freeing up time to help.
>
>
> On Thu, Mar 9, 2017 at 11:18 AM, Stack <st...@duboce.net> wrote:
>
> > On Thu, Mar 9, 2017 at 12:34 AM, Phil Yang <ya...@apache.org>
> wrote:
> > >
> > >
> > > So my suggestion is cutting branch-x faster and have some fixed period,
> > for
> > > example, six month or one year?
> > >
> >
> >
> > You are right Phil.
> >
> > The Release Managers for the minor releases have been doing a good job
> > keeping up a decent release cadence but we have an abysmal track record
> > when it comes to pushing out majors. First we were afraid to commit --
> > witness how long it took us to get to a 1.0 -- and then pushing out the
> 1.0
> > took a monster effort. 2.0 looks to be a repeat of the errors of 1.0. My
> > sense is that 2.0 is beyond saving at this stage.
> >
> > Can we do 3.0 different? As per your suggestion?
> >
> > St.Ack
> >
>
>
>
> --
> Best regards,
>
> - Andy
>
> If you are given a choice, you believe you have acted freely. - Raymond
> Teller (via Peter Watts)
>
--
Thanks and Regards,
Ashu Pachauri
Re: A suggestion for releasing major versions faster (Was: NOTICE:
Nice testimony on benefits of the offheap read-path work now up on our blog)
Posted by Andrew Purtell <ap...@apache.org>.
The only way forward for saving 2.0 at this point is to *make the branch
and spin the RC. *Just do it. Kick out by revert what obviously isn't
ready. Solicit help in getting partially finished things into working
state. Kick them out too if the help does not arrive.
Maybe too much is in a half done state and the scale of effort for those
reverts is too high. Fine. Renumber master as 3.0, and make a branch-2 from
branch-1 and backport a select number of things from master into the new
branch-2. Then release. I do a variation of this for the $dayjob so would
be your man to turn to for driving this if that's the way forward.
I know it's easy to recommend the labor of others. Depending on what we are
going to do I can talk to work about freeing up time to help.
On Thu, Mar 9, 2017 at 11:18 AM, Stack <st...@duboce.net> wrote:
> On Thu, Mar 9, 2017 at 12:34 AM, Phil Yang <ya...@apache.org> wrote:
> >
> >
> > So my suggestion is cutting branch-x faster and have some fixed period,
> for
> > example, six month or one year?
> >
>
>
> You are right Phil.
>
> The Release Managers for the minor releases have been doing a good job
> keeping up a decent release cadence but we have an abysmal track record
> when it comes to pushing out majors. First we were afraid to commit --
> witness how long it took us to get to a 1.0 -- and then pushing out the 1.0
> took a monster effort. 2.0 looks to be a repeat of the errors of 1.0. My
> sense is that 2.0 is beyond saving at this stage.
>
> Can we do 3.0 different? As per your suggestion?
>
> St.Ack
>
--
Best regards,
- Andy
If you are given a choice, you believe you have acted freely. - Raymond
Teller (via Peter Watts)
Re: A suggestion for releasing major versions faster (Was: NOTICE:
Nice testimony on benefits of the offheap read-path work now up on our blog)
Posted by Stack <st...@duboce.net>.
On Thu, Mar 9, 2017 at 12:34 AM, Phil Yang <ya...@apache.org> wrote:
>
>
> So my suggestion is cutting branch-x faster and have some fixed period, for
> example, six month or one year?
>
You are right Phil.
The Release Managers for the minor releases have been doing a good job
keeping up a decent release cadence but we have an abysmal track record
when it comes to pushing out majors. First we were afraid to commit --
witness how long it took us to get to a 1.0 -- and then pushing out the 1.0
took a monster effort. 2.0 looks to be a repeat of the errors of 1.0. My
sense is that 2.0 is beyond saving at this stage.
Can we do 3.0 different? As per your suggestion?
St.Ack