[DISCUSS] EOL branch-1.3

[Andrew Purtell <ap...@apache.org>]

We haven't had a release from branch-1.3 for a long time and do not appear
to have an active RM for it. Unless a RM for 1.3 steps forward and promises
to make a release in the very near future, I propose we make one more
release of 1.3, from the head of branch-1.3, and then retire the branch. If
this is acceptable I can RM the final 1.3 release.

-- 
Best regards,
Andrew

Words like orphans lost among the crosstalk, meaning torn from truth's
decrepit hands
   - A23, Crosstalk

Re: [DISCUSS] EOL branch-1.3

[Sean Busbey <bu...@apache.org>]

big +1 from me.
On Fri, Dec 7, 2018 at 1:25 PM Andrew Purtell <ap...@apache.org> wrote:
>
> We haven't had a release from branch-1.3 for a long time and do not appear
> to have an active RM for it. Unless a RM for 1.3 steps forward and promises
> to make a release in the very near future, I propose we make one more
> release of 1.3, from the head of branch-1.3, and then retire the branch. If
> this is acceptable I can RM the final 1.3 release.
>
> --
> Best regards,
> Andrew
>
> Words like orphans lost among the crosstalk, meaning torn from truth's
> decrepit hands
>    - A23, Crosstalk

Re: [DISCUSS] EOL branch-1.3

[Sean Busbey <bu...@apache.org>]

big +1 from me.
On Fri, Dec 7, 2018 at 1:25 PM Andrew Purtell <ap...@apache.org> wrote:
>
> We haven't had a release from branch-1.3 for a long time and do not appear
> to have an active RM for it. Unless a RM for 1.3 steps forward and promises
> to make a release in the very near future, I propose we make one more
> release of 1.3, from the head of branch-1.3, and then retire the branch. If
> this is acceptable I can RM the final 1.3 release.
>
> --
> Best regards,
> Andrew
>
> Words like orphans lost among the crosstalk, meaning torn from truth's
> decrepit hands
>    - A23, Crosstalk

Re: [DISCUSS] EOL branch-1.3

[Andrew Purtell <ap...@apache.org>]

My plan is to focus on 1.5 going forward from January of 2019. Hopefully we
EOL 1.4 within 6 months to a year after we start having 1.5 releases. My
advice is to just look at branch-1 for your next upstream target.



On Mon, Dec 17, 2018 at 2:53 PM Francis Christopher Liu <
toffer.liu@gmail.com> wrote:

> Quarterly it is then!
>
> > Any chance of your going to 1.4 Francis so we can let Andrew's effort at
> unhitching 1.3 complete?
> Not right now we have some big high priority tasks that can't really be
> pushed out. Tho we'll start pushing internal patches upstream and see which
> branches they land and decide which is the most viable. It will be much
> easier for us to move to branches that have most of our changes especially
> the big ones tho not a deal breaker but will definitely be easier to get
> buy in.
>
> Thanks,
> Francis
>
>
>
> On Mon, Dec 17, 2018 at 12:58 PM Stack <st...@duboce.net> wrote:
>
> > Quarterly seems fine.
> >
> > Still too many branches though.
> >
> > Any chance of your going to 1.4 Francis so we can let Andrew's effort at
> > unhitching 1.3 complete?
> >
> > Thanks,
> > S
> >
> > On Mon, Dec 17, 2018 at 11:32 AM Andrew Purtell <ap...@apache.org>
> > wrote:
> >
> > > I have been releasing 1.4 semi-monthly (usually, monthly) and Sean has
> > been
> > > releasing 1.2 every quarter. So maybe quarterly releases would be good?
> > > What do others think? What is the minimum release schedule to make it
> > worth
> > > your while for commits/backports to a branch? At least once every half
> > > year? More often?
> > >
> > > On Mon, Dec 17, 2018 at 11:23 AM Francis Christopher Liu <
> > > toffer.liu@gmail.com> wrote:
> > >
> > > > > Given there was no release activity on 1.3 all year may I ask how
> you
> > > are
> > > > using 1.3? Are you consuming upstream changes by cherry pick into an
> > > > internal branch?
> > > > It depends on the urgency of an internal release we either pull in
> all
> > > > changes up to a release, tip or cherry-pick. For the more recent
> > releases
> > > > we've been cherry picking. Tho we intend to pull in all changes
> again.
> > > BTW
> > > > I did release 1.3.2 in March.
> > > >
> > > > >It’s great that you’ve stepped forward to offer ongoing RM activity.
> > We
> > > > will need this commitment and a new pattern of more frequent
> releasing
> > to
> > > > justify keeping the code line alive, I think.
> > > > Let me know what would be an acceptable release cadence and I'll
> carve
> > > out
> > > > time.
> > > >
> > > > >Did you see that I stepped forward to make a release? There is a
> VOTE
> > > > thread now for 1.3.3RC0.  Perhaps we can start there? Would you use
> it?
> > > > Would you +1? Or are there changes in there that are of concern?
> Please
> > > > consider commenting on the VOTE.
> > > > Yes we will use it, my intention is to be as current to branch-1.3 as
> > > > possible. Yes, I intend to vote on the release. I am currently
> running
> > > the
> > > > unit test and going through the release. Apologies for you having to
> > cut
> > > > the release.
> > > >
> > > > Thanks,
> > > > Francis
> > > >
> > > >
> > > >
> > > >
> > > > On Mon, Dec 17, 2018 at 8:48 AM Andrew Purtell <
> > andrew.purtell@gmail.com
> > > >
> > > > wrote:
> > > >
> > > > > It’s been a year since the last release. For what it’s worth I see
> no
> > > > harm
> > > > > in continuing to release 1.3, but you have to consider how
> burdensome
> > > it
> > > > is
> > > > > to have an open code line that bug fixes need to be committed into.
> > > Given
> > > > > there was no release activity on 1.3 all year may I ask how you are
> > > using
> > > > > 1.3? Are you consuming upstream changes by cherry pick into an
> > internal
> > > > > branch? Or are you not consuming any upstream changes at all? If
> the
> > > > > latter, then what’s the point? If the former, it still isn’t great,
> > > > because
> > > > > while changes may be getting out into production somewhere it’s
> only
> > > you
> > > > > who is benefitting. We need releases from branch-1.3 a lot more
> > > > frequently
> > > > > or it’s a bad deal for the community. Committers have to deal with
> > > > > effectively a dead branch. Users get no releases. Given the
> consensus
> > > > > expressed on this thread we don’t want this deal. It’s great that
> > > you’ve
> > > > > stepped forward to offer ongoing RM activity. We will need this
> > > > commitment
> > > > > and a new pattern of more frequent releasing to justify keeping the
> > > code
> > > > > line alive, I think.
> > > > >
> > > > > Did you see that I stepped forward to make a release? There is a
> VOTE
> > > > > thread now for 1.3.3RC0.  Perhaps we can start there? Would you use
> > it?
> > > > > Would you +1? Or are there changes in there that are of concern?
> > Please
> > > > > consider commenting on the VOTE.
> > > > >
> > > > >
> > > > > > On Dec 17, 2018, at 8:31 AM, Francis Christopher Liu <
> > > > > toffer.liu@gmail.com> wrote:
> > > > > >
> > > > > > Hi,
> > > > > >
> > > > > > Apologies a bit late to this discussion. I would still like to
> > > continue
> > > > > > making 1.3 releases. If the concern is having a better cadence of
> > > > > releases
> > > > > > let me know how often the community would like (quarterly, every
> > > other
> > > > > > month, etc) and I'll make sure to carve out time with my
> employer.
> > We
> > > > > will
> > > > > > be on 1.3 for a while. I believe it would be beneficial for the
> > > > community
> > > > > > and my employer for us to be on an active release line, hence my
> > > > > interest.
> > > > > >
> > > > > > Let me know what you guys think?
> > > > > >
> > > > > > Thanks,
> > > > > > Francis
> > > > > >
> > > > > >
> > > > > >> On Mon, Dec 10, 2018 at 6:04 PM Andrew Purtell <
> > apurtell@apache.org
> > > >
> > > > > wrote:
> > > > > >>
> > > > > >> Thank you all for your comments. It looks like we have consensus
> > to
> > > > EOL
> > > > > 1.3
> > > > > >> and RM one final release. I will start working on that release,
> > > 1.3.3,
> > > > > now.
> > > > > >>
> > > > > >>> On Mon, Dec 10, 2018 at 8:50 AM Josh Elser <el...@apache.org>
> > > > wrote:
> > > > > >>>
> > > > > >>> +1
> > > > > >>>
> > > > > >>>> On 12/7/18 2:24 PM, Andrew Purtell wrote:
> > > > > >>>> We haven't had a release from branch-1.3 for a long time and
> do
> > > not
> > > > > >>> appear
> > > > > >>>> to have an active RM for it. Unless a RM for 1.3 steps forward
> > and
> > > > > >>> promises
> > > > > >>>> to make a release in the very near future, I propose we make
> one
> > > > more
> > > > > >>>> release of 1.3, from the head of branch-1.3, and then retire
> the
> > > > > >> branch.
> > > > > >>> If
> > > > > >>>> this is acceptable I can RM the final 1.3 release.
> > > > > >>>>
> > > > > >>>
> > > > > >>
> > > > > >>
> > > > > >> --
> > > > > >> Best regards,
> > > > > >> Andrew
> > > > > >>
> > > > > >> Words like orphans lost among the crosstalk, meaning torn from
> > > truth's
> > > > > >> decrepit hands
> > > > > >>   - A23, Crosstalk
> > > > > >>
> > > > >
> > > >
> > >
> > >
> > > --
> > > Best regards,
> > > Andrew
> > >
> > > Words like orphans lost among the crosstalk, meaning torn from truth's
> > > decrepit hands
> > >    - A23, Crosstalk
> > >
> >
>


-- 
Best regards,
Andrew

Words like orphans lost among the crosstalk, meaning torn from truth's
decrepit hands
   - A23, Crosstalk

Re: [DISCUSS] EOL branch-1.3

[Francis Christopher Liu <to...@gmail.com>]

Quarterly it is then!

> Any chance of your going to 1.4 Francis so we can let Andrew's effort at
unhitching 1.3 complete?
Not right now we have some big high priority tasks that can't really be
pushed out. Tho we'll start pushing internal patches upstream and see which
branches they land and decide which is the most viable. It will be much
easier for us to move to branches that have most of our changes especially
the big ones tho not a deal breaker but will definitely be easier to get
buy in.

Thanks,
Francis



On Mon, Dec 17, 2018 at 12:58 PM Stack <st...@duboce.net> wrote:

> Quarterly seems fine.
>
> Still too many branches though.
>
> Any chance of your going to 1.4 Francis so we can let Andrew's effort at
> unhitching 1.3 complete?
>
> Thanks,
> S
>
> On Mon, Dec 17, 2018 at 11:32 AM Andrew Purtell <ap...@apache.org>
> wrote:
>
> > I have been releasing 1.4 semi-monthly (usually, monthly) and Sean has
> been
> > releasing 1.2 every quarter. So maybe quarterly releases would be good?
> > What do others think? What is the minimum release schedule to make it
> worth
> > your while for commits/backports to a branch? At least once every half
> > year? More often?
> >
> > On Mon, Dec 17, 2018 at 11:23 AM Francis Christopher Liu <
> > toffer.liu@gmail.com> wrote:
> >
> > > > Given there was no release activity on 1.3 all year may I ask how you
> > are
> > > using 1.3? Are you consuming upstream changes by cherry pick into an
> > > internal branch?
> > > It depends on the urgency of an internal release we either pull in all
> > > changes up to a release, tip or cherry-pick. For the more recent
> releases
> > > we've been cherry picking. Tho we intend to pull in all changes again.
> > BTW
> > > I did release 1.3.2 in March.
> > >
> > > >It’s great that you’ve stepped forward to offer ongoing RM activity.
> We
> > > will need this commitment and a new pattern of more frequent releasing
> to
> > > justify keeping the code line alive, I think.
> > > Let me know what would be an acceptable release cadence and I'll carve
> > out
> > > time.
> > >
> > > >Did you see that I stepped forward to make a release? There is a VOTE
> > > thread now for 1.3.3RC0.  Perhaps we can start there? Would you use it?
> > > Would you +1? Or are there changes in there that are of concern? Please
> > > consider commenting on the VOTE.
> > > Yes we will use it, my intention is to be as current to branch-1.3 as
> > > possible. Yes, I intend to vote on the release. I am currently running
> > the
> > > unit test and going through the release. Apologies for you having to
> cut
> > > the release.
> > >
> > > Thanks,
> > > Francis
> > >
> > >
> > >
> > >
> > > On Mon, Dec 17, 2018 at 8:48 AM Andrew Purtell <
> andrew.purtell@gmail.com
> > >
> > > wrote:
> > >
> > > > It’s been a year since the last release. For what it’s worth I see no
> > > harm
> > > > in continuing to release 1.3, but you have to consider how burdensome
> > it
> > > is
> > > > to have an open code line that bug fixes need to be committed into.
> > Given
> > > > there was no release activity on 1.3 all year may I ask how you are
> > using
> > > > 1.3? Are you consuming upstream changes by cherry pick into an
> internal
> > > > branch? Or are you not consuming any upstream changes at all? If the
> > > > latter, then what’s the point? If the former, it still isn’t great,
> > > because
> > > > while changes may be getting out into production somewhere it’s only
> > you
> > > > who is benefitting. We need releases from branch-1.3 a lot more
> > > frequently
> > > > or it’s a bad deal for the community. Committers have to deal with
> > > > effectively a dead branch. Users get no releases. Given the consensus
> > > > expressed on this thread we don’t want this deal. It’s great that
> > you’ve
> > > > stepped forward to offer ongoing RM activity. We will need this
> > > commitment
> > > > and a new pattern of more frequent releasing to justify keeping the
> > code
> > > > line alive, I think.
> > > >
> > > > Did you see that I stepped forward to make a release? There is a VOTE
> > > > thread now for 1.3.3RC0.  Perhaps we can start there? Would you use
> it?
> > > > Would you +1? Or are there changes in there that are of concern?
> Please
> > > > consider commenting on the VOTE.
> > > >
> > > >
> > > > > On Dec 17, 2018, at 8:31 AM, Francis Christopher Liu <
> > > > toffer.liu@gmail.com> wrote:
> > > > >
> > > > > Hi,
> > > > >
> > > > > Apologies a bit late to this discussion. I would still like to
> > continue
> > > > > making 1.3 releases. If the concern is having a better cadence of
> > > > releases
> > > > > let me know how often the community would like (quarterly, every
> > other
> > > > > month, etc) and I'll make sure to carve out time with my employer.
> We
> > > > will
> > > > > be on 1.3 for a while. I believe it would be beneficial for the
> > > community
> > > > > and my employer for us to be on an active release line, hence my
> > > > interest.
> > > > >
> > > > > Let me know what you guys think?
> > > > >
> > > > > Thanks,
> > > > > Francis
> > > > >
> > > > >
> > > > >> On Mon, Dec 10, 2018 at 6:04 PM Andrew Purtell <
> apurtell@apache.org
> > >
> > > > wrote:
> > > > >>
> > > > >> Thank you all for your comments. It looks like we have consensus
> to
> > > EOL
> > > > 1.3
> > > > >> and RM one final release. I will start working on that release,
> > 1.3.3,
> > > > now.
> > > > >>
> > > > >>> On Mon, Dec 10, 2018 at 8:50 AM Josh Elser <el...@apache.org>
> > > wrote:
> > > > >>>
> > > > >>> +1
> > > > >>>
> > > > >>>> On 12/7/18 2:24 PM, Andrew Purtell wrote:
> > > > >>>> We haven't had a release from branch-1.3 for a long time and do
> > not
> > > > >>> appear
> > > > >>>> to have an active RM for it. Unless a RM for 1.3 steps forward
> and
> > > > >>> promises
> > > > >>>> to make a release in the very near future, I propose we make one
> > > more
> > > > >>>> release of 1.3, from the head of branch-1.3, and then retire the
> > > > >> branch.
> > > > >>> If
> > > > >>>> this is acceptable I can RM the final 1.3 release.
> > > > >>>>
> > > > >>>
> > > > >>
> > > > >>
> > > > >> --
> > > > >> Best regards,
> > > > >> Andrew
> > > > >>
> > > > >> Words like orphans lost among the crosstalk, meaning torn from
> > truth's
> > > > >> decrepit hands
> > > > >>   - A23, Crosstalk
> > > > >>
> > > >
> > >
> >
> >
> > --
> > Best regards,
> > Andrew
> >
> > Words like orphans lost among the crosstalk, meaning torn from truth's
> > decrepit hands
> >    - A23, Crosstalk
> >
>

Re: [DISCUSS] EOL branch-1.3

[Stack <st...@duboce.net>]

Quarterly seems fine.

Still too many branches though.

Any chance of your going to 1.4 Francis so we can let Andrew's effort at
unhitching 1.3 complete?

Thanks,
S

On Mon, Dec 17, 2018 at 11:32 AM Andrew Purtell <ap...@apache.org> wrote:

> I have been releasing 1.4 semi-monthly (usually, monthly) and Sean has been
> releasing 1.2 every quarter. So maybe quarterly releases would be good?
> What do others think? What is the minimum release schedule to make it worth
> your while for commits/backports to a branch? At least once every half
> year? More often?
>
> On Mon, Dec 17, 2018 at 11:23 AM Francis Christopher Liu <
> toffer.liu@gmail.com> wrote:
>
> > > Given there was no release activity on 1.3 all year may I ask how you
> are
> > using 1.3? Are you consuming upstream changes by cherry pick into an
> > internal branch?
> > It depends on the urgency of an internal release we either pull in all
> > changes up to a release, tip or cherry-pick. For the more recent releases
> > we've been cherry picking. Tho we intend to pull in all changes again.
> BTW
> > I did release 1.3.2 in March.
> >
> > >It’s great that you’ve stepped forward to offer ongoing RM activity. We
> > will need this commitment and a new pattern of more frequent releasing to
> > justify keeping the code line alive, I think.
> > Let me know what would be an acceptable release cadence and I'll carve
> out
> > time.
> >
> > >Did you see that I stepped forward to make a release? There is a VOTE
> > thread now for 1.3.3RC0.  Perhaps we can start there? Would you use it?
> > Would you +1? Or are there changes in there that are of concern? Please
> > consider commenting on the VOTE.
> > Yes we will use it, my intention is to be as current to branch-1.3 as
> > possible. Yes, I intend to vote on the release. I am currently running
> the
> > unit test and going through the release. Apologies for you having to cut
> > the release.
> >
> > Thanks,
> > Francis
> >
> >
> >
> >
> > On Mon, Dec 17, 2018 at 8:48 AM Andrew Purtell <andrew.purtell@gmail.com
> >
> > wrote:
> >
> > > It’s been a year since the last release. For what it’s worth I see no
> > harm
> > > in continuing to release 1.3, but you have to consider how burdensome
> it
> > is
> > > to have an open code line that bug fixes need to be committed into.
> Given
> > > there was no release activity on 1.3 all year may I ask how you are
> using
> > > 1.3? Are you consuming upstream changes by cherry pick into an internal
> > > branch? Or are you not consuming any upstream changes at all? If the
> > > latter, then what’s the point? If the former, it still isn’t great,
> > because
> > > while changes may be getting out into production somewhere it’s only
> you
> > > who is benefitting. We need releases from branch-1.3 a lot more
> > frequently
> > > or it’s a bad deal for the community. Committers have to deal with
> > > effectively a dead branch. Users get no releases. Given the consensus
> > > expressed on this thread we don’t want this deal. It’s great that
> you’ve
> > > stepped forward to offer ongoing RM activity. We will need this
> > commitment
> > > and a new pattern of more frequent releasing to justify keeping the
> code
> > > line alive, I think.
> > >
> > > Did you see that I stepped forward to make a release? There is a VOTE
> > > thread now for 1.3.3RC0.  Perhaps we can start there? Would you use it?
> > > Would you +1? Or are there changes in there that are of concern? Please
> > > consider commenting on the VOTE.
> > >
> > >
> > > > On Dec 17, 2018, at 8:31 AM, Francis Christopher Liu <
> > > toffer.liu@gmail.com> wrote:
> > > >
> > > > Hi,
> > > >
> > > > Apologies a bit late to this discussion. I would still like to
> continue
> > > > making 1.3 releases. If the concern is having a better cadence of
> > > releases
> > > > let me know how often the community would like (quarterly, every
> other
> > > > month, etc) and I'll make sure to carve out time with my employer. We
> > > will
> > > > be on 1.3 for a while. I believe it would be beneficial for the
> > community
> > > > and my employer for us to be on an active release line, hence my
> > > interest.
> > > >
> > > > Let me know what you guys think?
> > > >
> > > > Thanks,
> > > > Francis
> > > >
> > > >
> > > >> On Mon, Dec 10, 2018 at 6:04 PM Andrew Purtell <apurtell@apache.org
> >
> > > wrote:
> > > >>
> > > >> Thank you all for your comments. It looks like we have consensus to
> > EOL
> > > 1.3
> > > >> and RM one final release. I will start working on that release,
> 1.3.3,
> > > now.
> > > >>
> > > >>> On Mon, Dec 10, 2018 at 8:50 AM Josh Elser <el...@apache.org>
> > wrote:
> > > >>>
> > > >>> +1
> > > >>>
> > > >>>> On 12/7/18 2:24 PM, Andrew Purtell wrote:
> > > >>>> We haven't had a release from branch-1.3 for a long time and do
> not
> > > >>> appear
> > > >>>> to have an active RM for it. Unless a RM for 1.3 steps forward and
> > > >>> promises
> > > >>>> to make a release in the very near future, I propose we make one
> > more
> > > >>>> release of 1.3, from the head of branch-1.3, and then retire the
> > > >> branch.
> > > >>> If
> > > >>>> this is acceptable I can RM the final 1.3 release.
> > > >>>>
> > > >>>
> > > >>
> > > >>
> > > >> --
> > > >> Best regards,
> > > >> Andrew
> > > >>
> > > >> Words like orphans lost among the crosstalk, meaning torn from
> truth's
> > > >> decrepit hands
> > > >>   - A23, Crosstalk
> > > >>
> > >
> >
>
>
> --
> Best regards,
> Andrew
>
> Words like orphans lost among the crosstalk, meaning torn from truth's
> decrepit hands
>    - A23, Crosstalk
>

Re: [DISCUSS] EOL branch-1.3

[OpenInx <op...@gmail.com>]

> As mentioned in a few different
DISCUSS threads, we have too many branches active and committers have
limited bandwidth so stuff gets missed.

Agreed, Some critial bugs , which need to commit to 8 branches now
(branch-1.2/branch-1.3/branch-1.4/branch-1/branch-2/branch-2.1/branch-2.2/master).
The patch applying and validation compilation for all the 8 branches, would
take at least 40+ min,  according to my experience.
I would like to maintain a few active branches (as Purtell says before).
BTW,  the hbase user should be easy to upgrade from branch-1.3 to
branch-1.4 or branch-1.5 ? the cost of upgrading from branch-1.3.9 to
branch-1.3.10
seems be the same as upgrading from branch-1.3 to 1.4/1.5, I think, so why
not try to upgrade 1.4 .

On Tue, Dec 18, 2018 at 9:41 AM Sean Busbey <bu...@apache.org> wrote:

> If I really stop to reflect on it, I'm fine with whatever for the branch. I
> just want to make sure we're proactively setting expectations for
> downstream users.
>
> Granted, 1.3 was never declared the "stable" release line so folks should
> have expected it could die off whenever, but it really sucks to not see
> releases when you've decided to use a release line. All downstreamer users
> shouldn't have to maintain a fork.
>
> I've found in maintaining the 1.2 release line that the RM has to
> proactively review all the commits at least up to the major release line in
> order to make sure things get included. As mentioned in a few different
> DISCUSS threads, we have too many branches active and committers have
> limited bandwidth so stuff gets missed. just doing it as a part of the
> release takes quite some time if one hasn't been keeping an eye out.
>
> FWIW, I agree that effort towards getting your deployment onto a future
> branch-1 release would be better. It'd be nice if that could include
> discussing what it would take for periodic updates to future branch-1 minor
> releases to become your plan instead of e.g. sticking to branch-1.4.z
>
> On Mon, Dec 17, 2018, 18:38 Francis Christopher Liu <toffer.liu@gmail.com
> wrote:
>
> > > How about we have a probationary period where the RM takes care of
> > pulling in changes for branch-1.3 releases? After say a quarter of
> > hitting a monthly cadence we go back to committers proactively
> > including the branch.
> >
> > How about I just release monthly during the probationary period?
> Monitoring
> > and backporting all patches sounds like effort that would be better
> > allocated to open sourcing our internal patches? Or if you want some
> > measure of me/us upstreaming patches (works towards moving to a newer
> > branch). That seems much more beneficial for all?
> >
> >
> >
> > On Mon, Dec 17, 2018 at 3:09 PM Sean Busbey <bu...@apache.org> wrote:
> >
> > > I've worked to get back to monthly because I don't think quarterly is
> > > often enough to be useful. (but take this with a grain of salt since I
> > > am not a user of the branch in question)
> > >
> > > - 1.2.9: 2018-11-27
> > > - 1.2.8: 2018-10-20
> > > - 1.2.7: 2018-09-16
> > >
> > > I'll be starting 1.2.10 soon.
> > >
> > > I'm still happy to have releases from an EOL branch. I just expect
> > > that the RM will handle the backporting process for that branch so
> > > committers don't have to worry about it when accepting contributions.
> > >
> > > How about we have a probationary period where the RM takes care of
> > > pulling in changes for branch-1.3 releases? After say a quarter of
> > > hitting a monthly cadence we go back to committers proactively
> > > including the branch. If we don't hit the releases then we declare the
> > > branch EOL. That designation which still would allow for releases, but
> > > would change cadence expectations, update status on the downloads
> > > listing, docs, and avoid committers having to think about the branch.
> > > On Mon, Dec 17, 2018 at 1:32 PM Andrew Purtell <ap...@apache.org>
> > > wrote:
> > > >
> > > > I have been releasing 1.4 semi-monthly (usually, monthly) and Sean
> has
> > > been
> > > > releasing 1.2 every quarter. So maybe quarterly releases would be
> good?
> > > > What do others think? What is the minimum release schedule to make it
> > > worth
> > > > your while for commits/backports to a branch? At least once every
> half
> > > > year? More often?
> > > >
> > > > On Mon, Dec 17, 2018 at 11:23 AM Francis Christopher Liu <
> > > > toffer.liu@gmail.com> wrote:
> > > >
> > > > > > Given there was no release activity on 1.3 all year may I ask how
> > > you are
> > > > > using 1.3? Are you consuming upstream changes by cherry pick into
> an
> > > > > internal branch?
> > > > > It depends on the urgency of an internal release we either pull in
> > all
> > > > > changes up to a release, tip or cherry-pick. For the more recent
> > > releases
> > > > > we've been cherry picking. Tho we intend to pull in all changes
> > again.
> > > BTW
> > > > > I did release 1.3.2 in March.
> > > > >
> > > > > >It’s great that you’ve stepped forward to offer ongoing RM
> activity.
> > > We
> > > > > will need this commitment and a new pattern of more frequent
> > releasing
> > > to
> > > > > justify keeping the code line alive, I think.
> > > > > Let me know what would be an acceptable release cadence and I'll
> > carve
> > > out
> > > > > time.
> > > > >
> > > > > >Did you see that I stepped forward to make a release? There is a
> > VOTE
> > > > > thread now for 1.3.3RC0.  Perhaps we can start there? Would you use
> > it?
> > > > > Would you +1? Or are there changes in there that are of concern?
> > Please
> > > > > consider commenting on the VOTE.
> > > > > Yes we will use it, my intention is to be as current to branch-1.3
> as
> > > > > possible. Yes, I intend to vote on the release. I am currently
> > running
> > > the
> > > > > unit test and going through the release. Apologies for you having
> to
> > > cut
> > > > > the release.
> > > > >
> > > > > Thanks,
> > > > > Francis
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > On Mon, Dec 17, 2018 at 8:48 AM Andrew Purtell <
> > > andrew.purtell@gmail.com>
> > > > > wrote:
> > > > >
> > > > > > It’s been a year since the last release. For what it’s worth I
> see
> > no
> > > > > harm
> > > > > > in continuing to release 1.3, but you have to consider how
> > > burdensome it
> > > > > is
> > > > > > to have an open code line that bug fixes need to be committed
> into.
> > > Given
> > > > > > there was no release activity on 1.3 all year may I ask how you
> are
> > > using
> > > > > > 1.3? Are you consuming upstream changes by cherry pick into an
> > > internal
> > > > > > branch? Or are you not consuming any upstream changes at all? If
> > the
> > > > > > latter, then what’s the point? If the former, it still isn’t
> great,
> > > > > because
> > > > > > while changes may be getting out into production somewhere it’s
> > only
> > > you
> > > > > > who is benefitting. We need releases from branch-1.3 a lot more
> > > > > frequently
> > > > > > or it’s a bad deal for the community. Committers have to deal
> with
> > > > > > effectively a dead branch. Users get no releases. Given the
> > consensus
> > > > > > expressed on this thread we don’t want this deal. It’s great that
> > > you’ve
> > > > > > stepped forward to offer ongoing RM activity. We will need this
> > > > > commitment
> > > > > > and a new pattern of more frequent releasing to justify keeping
> the
> > > code
> > > > > > line alive, I think.
> > > > > >
> > > > > > Did you see that I stepped forward to make a release? There is a
> > VOTE
> > > > > > thread now for 1.3.3RC0.  Perhaps we can start there? Would you
> use
> > > it?
> > > > > > Would you +1? Or are there changes in there that are of concern?
> > > Please
> > > > > > consider commenting on the VOTE.
> > > > > >
> > > > > >
> > > > > > > On Dec 17, 2018, at 8:31 AM, Francis Christopher Liu <
> > > > > > toffer.liu@gmail.com> wrote:
> > > > > > >
> > > > > > > Hi,
> > > > > > >
> > > > > > > Apologies a bit late to this discussion. I would still like to
> > > continue
> > > > > > > making 1.3 releases. If the concern is having a better cadence
> of
> > > > > > releases
> > > > > > > let me know how often the community would like (quarterly,
> every
> > > other
> > > > > > > month, etc) and I'll make sure to carve out time with my
> > employer.
> > > We
> > > > > > will
> > > > > > > be on 1.3 for a while. I believe it would be beneficial for the
> > > > > community
> > > > > > > and my employer for us to be on an active release line, hence
> my
> > > > > > interest.
> > > > > > >
> > > > > > > Let me know what you guys think?
> > > > > > >
> > > > > > > Thanks,
> > > > > > > Francis
> > > > > > >
> > > > > > >
> > > > > > >> On Mon, Dec 10, 2018 at 6:04 PM Andrew Purtell <
> > > apurtell@apache.org>
> > > > > > wrote:
> > > > > > >>
> > > > > > >> Thank you all for your comments. It looks like we have
> consensus
> > > to
> > > > > EOL
> > > > > > 1.3
> > > > > > >> and RM one final release. I will start working on that
> release,
> > > 1.3.3,
> > > > > > now.
> > > > > > >>
> > > > > > >>> On Mon, Dec 10, 2018 at 8:50 AM Josh Elser <
> elserj@apache.org>
> > > > > wrote:
> > > > > > >>>
> > > > > > >>> +1
> > > > > > >>>
> > > > > > >>>> On 12/7/18 2:24 PM, Andrew Purtell wrote:
> > > > > > >>>> We haven't had a release from branch-1.3 for a long time and
> > do
> > > not
> > > > > > >>> appear
> > > > > > >>>> to have an active RM for it. Unless a RM for 1.3 steps
> forward
> > > and
> > > > > > >>> promises
> > > > > > >>>> to make a release in the very near future, I propose we make
> > one
> > > > > more
> > > > > > >>>> release of 1.3, from the head of branch-1.3, and then retire
> > the
> > > > > > >> branch.
> > > > > > >>> If
> > > > > > >>>> this is acceptable I can RM the final 1.3 release.
> > > > > > >>>>
> > > > > > >>>
> > > > > > >>
> > > > > > >>
> > > > > > >> --
> > > > > > >> Best regards,
> > > > > > >> Andrew
> > > > > > >>
> > > > > > >> Words like orphans lost among the crosstalk, meaning torn from
> > > truth's
> > > > > > >> decrepit hands
> > > > > > >>   - A23, Crosstalk
> > > > > > >>
> > > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > > Best regards,
> > > > Andrew
> > > >
> > > > Words like orphans lost among the crosstalk, meaning torn from
> truth's
> > > > decrepit hands
> > > >    - A23, Crosstalk
> > >
> >
>

Re: [DISCUSS] EOL branch-1.3

[Andrew Purtell <ap...@apache.org>]

Sure, that sounds good. We have a consensus to do more frequent minor
releasing so there is no problem bumping minors whenever needed on
branch-1. Let's play it by ear.

On Fri, Dec 21, 2018 at 12:09 AM Francis Christopher Liu <
toffer.liu@gmail.com> wrote:

> > If you have local changes you’d like to upstream please open JIRAs or
> update the fix version on existing to include 1.5.0 so we can gather them
> into a list and consider them. Although, I’d like to release 1.5.0 in
> January 2019 so maybe we need a new fix version of 1.6.0 to denote
> significant changes to hit later in the year? (Like split meta?)
>
> That'd be great if we can get it in a branch-1 release. Tho it's a stretch
> to make it by January 2019 so prolly 1.6 then. To start I'll work on
> putting up the split meta patch and we'll put up other smaller patches
> while we get this one in.
>
>
>
> On Wed, Dec 19, 2018 at 9:32 AM Andrew Purtell <an...@gmail.com>
> wrote:
>
> > Upstreaming local changes into a new (minor?) Apache release that we can
> > circle around and upgrade to is our strategy too. One of my goals with
> > branch-1 and upcoming releasing of 1.5.0 is that 1.5 is a functional
> > superset of everything we depend on in production as well as all the
> other
> > community improvements. Perhaps 1.5 can serve in the same way for you? If
> > you have local changes you’d like to upstream please open JIRAs or update
> > the fix version on existing to include 1.5.0 so we can gather them into a
> > list and consider them. Although, I’d like to release 1.5.0 in January
> 2019
> > so maybe we need a new fix version of 1.6.0 to denote significant changes
> > to hit later in the year? (Like split meta?) That’s fine too.  But let’s
> > organize your needs in a way we can track them.
> >
> >
> > On Dec 19, 2018, at 12:52 AM, Francis Christopher Liu <
> > toffer.liu@gmail.com> wrote:
> >
> > >> Granted, 1.3 was never declared the "stable" release line so folks
> > should
> > > have expected it could die off whenever, but it really sucks to not see
> > > releases when you've decided to use a release line. All downstreamer
> > users
> > > shouldn't have to maintain a fork.
> > >
> > > Agreed, this is my fault and I apologize for that.
> > >
> > >> I've found in maintaining the 1.2 release line that the RM has to
> > > proactively review all the commits at least up to the major release
> line
> > in
> > > order to make sure things get included.  As mentioned in a few
> different
> > > DISCUSS threads, we have too many branches active and committers have
> > > limited bandwidth so stuff gets missed. just doing it as a part of the
> > > release takes quite some time if one hasn't been keeping an eye out.
> > >
> > > Agreed, I noticed this as well when cutting 1.3.2. There were a lot of
> > > backporting jiras in the release. I also had the intent to monitor
> > branch-1
> > > for missed backports thanks for reminding me. If doing releases at a
> > > monthly cadence then it won't be too bad during the time of release?
> > >
> > >> FWIW, I agree that effort towards getting your deployment onto a
> future
> > > branch-1 release would be better. It'd be nice if that could include
> > > discussing what it would take for periodic updates to future branch-1
> > minor
> > > releases to become your plan instead of e.g. sticking to branch-1.4.z
> > >
> > > Yes my proposal encapsulates that. Essentially if we push most of our
> > > patches (especially the big ones) upstream then it won't be as big an
> > > effort to move between branches that have them. (Also addressing the
> > > question why it's difficult to move from 1.3 to 1.4).
> > >
> > >> On Mon, Dec 17, 2018 at 5:41 PM Sean Busbey <bu...@apache.org>
> wrote:
> > >>
> > >> If I really stop to reflect on it, I'm fine with whatever for the
> > branch. I
> > >> just want to make sure we're proactively setting expectations for
> > >> downstream users.
> > >>
> > >> Granted, 1.3 was never declared the "stable" release line so folks
> > should
> > >> have expected it could die off whenever, but it really sucks to not
> see
> > >> releases when you've decided to use a release line. All downstreamer
> > users
> > >> shouldn't have to maintain a fork.
> > >>
> > >> I've found in maintaining the 1.2 release line that the RM has to
> > >> proactively review all the commits at least up to the major release
> > line in
> > >> order to make sure things get included. As mentioned in a few
> different
> > >> DISCUSS threads, we have too many branches active and committers have
> > >> limited bandwidth so stuff gets missed. just doing it as a part of the
> > >> release takes quite some time if one hasn't been keeping an eye out.
> > >>
> > >> FWIW, I agree that effort towards getting your deployment onto a
> future
> > >> branch-1 release would be better. It'd be nice if that could include
> > >> discussing what it would take for periodic updates to future branch-1
> > minor
> > >> releases to become your plan instead of e.g. sticking to branch-1.4.z
> > >>
> > >> On Mon, Dec 17, 2018, 18:38 Francis Christopher Liu <
> > toffer.liu@gmail.com
> > >> wrote:
> > >>
> > >>>> How about we have a probationary period where the RM takes care of
> > >>> pulling in changes for branch-1.3 releases? After say a quarter of
> > >>> hitting a monthly cadence we go back to committers proactively
> > >>> including the branch.
> > >>>
> > >>> How about I just release monthly during the probationary period?
> > >> Monitoring
> > >>> and backporting all patches sounds like effort that would be better
> > >>> allocated to open sourcing our internal patches? Or if you want some
> > >>> measure of me/us upstreaming patches (works towards moving to a newer
> > >>> branch). That seems much more beneficial for all?
> > >>>
> > >>>
> > >>>
> > >>>> On Mon, Dec 17, 2018 at 3:09 PM Sean Busbey <bu...@apache.org>
> > wrote:
> > >>>>
> > >>>> I've worked to get back to monthly because I don't think quarterly
> is
> > >>>> often enough to be useful. (but take this with a grain of salt
> since I
> > >>>> am not a user of the branch in question)
> > >>>>
> > >>>> - 1.2.9: 2018-11-27
> > >>>> - 1.2.8: 2018-10-20
> > >>>> - 1.2.7: 2018-09-16
> > >>>>
> > >>>> I'll be starting 1.2.10 soon.
> > >>>>
> > >>>> I'm still happy to have releases from an EOL branch. I just expect
> > >>>> that the RM will handle the backporting process for that branch so
> > >>>> committers don't have to worry about it when accepting
> contributions.
> > >>>>
> > >>>> How about we have a probationary period where the RM takes care of
> > >>>> pulling in changes for branch-1.3 releases? After say a quarter of
> > >>>> hitting a monthly cadence we go back to committers proactively
> > >>>> including the branch. If we don't hit the releases then we declare
> the
> > >>>> branch EOL. That designation which still would allow for releases,
> but
> > >>>> would change cadence expectations, update status on the downloads
> > >>>> listing, docs, and avoid committers having to think about the
> branch.
> > >>>> On Mon, Dec 17, 2018 at 1:32 PM Andrew Purtell <apurtell@apache.org
> >
> > >>>> wrote:
> > >>>>>
> > >>>>> I have been releasing 1.4 semi-monthly (usually, monthly) and Sean
> > >> has
> > >>>> been
> > >>>>> releasing 1.2 every quarter. So maybe quarterly releases would be
> > >> good?
> > >>>>> What do others think? What is the minimum release schedule to make
> it
> > >>>> worth
> > >>>>> your while for commits/backports to a branch? At least once every
> > >> half
> > >>>>> year? More often?
> > >>>>>
> > >>>>> On Mon, Dec 17, 2018 at 11:23 AM Francis Christopher Liu <
> > >>>>> toffer.liu@gmail.com> wrote:
> > >>>>>
> > >>>>>>> Given there was no release activity on 1.3 all year may I ask how
> > >>>> you are
> > >>>>>> using 1.3? Are you consuming upstream changes by cherry pick into
> > >> an
> > >>>>>> internal branch?
> > >>>>>> It depends on the urgency of an internal release we either pull in
> > >>> all
> > >>>>>> changes up to a release, tip or cherry-pick. For the more recent
> > >>>> releases
> > >>>>>> we've been cherry picking. Tho we intend to pull in all changes
> > >>> again.
> > >>>> BTW
> > >>>>>> I did release 1.3.2 in March.
> > >>>>>>
> > >>>>>>> It’s great that you’ve stepped forward to offer ongoing RM
> > >> activity.
> > >>>> We
> > >>>>>> will need this commitment and a new pattern of more frequent
> > >>> releasing
> > >>>> to
> > >>>>>> justify keeping the code line alive, I think.
> > >>>>>> Let me know what would be an acceptable release cadence and I'll
> > >>> carve
> > >>>> out
> > >>>>>> time.
> > >>>>>>
> > >>>>>>> Did you see that I stepped forward to make a release? There is a
> > >>> VOTE
> > >>>>>> thread now for 1.3.3RC0.  Perhaps we can start there? Would you
> use
> > >>> it?
> > >>>>>> Would you +1? Or are there changes in there that are of concern?
> > >>> Please
> > >>>>>> consider commenting on the VOTE.
> > >>>>>> Yes we will use it, my intention is to be as current to branch-1.3
> > >> as
> > >>>>>> possible. Yes, I intend to vote on the release. I am currently
> > >>> running
> > >>>> the
> > >>>>>> unit test and going through the release. Apologies for you having
> > >> to
> > >>>> cut
> > >>>>>> the release.
> > >>>>>>
> > >>>>>> Thanks,
> > >>>>>> Francis
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>> On Mon, Dec 17, 2018 at 8:48 AM Andrew Purtell <
> > >>>> andrew.purtell@gmail.com>
> > >>>>>> wrote:
> > >>>>>>
> > >>>>>>> It’s been a year since the last release. For what it’s worth I
> > >> see
> > >>> no
> > >>>>>> harm
> > >>>>>>> in continuing to release 1.3, but you have to consider how
> > >>>> burdensome it
> > >>>>>> is
> > >>>>>>> to have an open code line that bug fixes need to be committed
> > >> into.
> > >>>> Given
> > >>>>>>> there was no release activity on 1.3 all year may I ask how you
> > >> are
> > >>>> using
> > >>>>>>> 1.3? Are you consuming upstream changes by cherry pick into an
> > >>>> internal
> > >>>>>>> branch? Or are you not consuming any upstream changes at all? If
> > >>> the
> > >>>>>>> latter, then what’s the point? If the former, it still isn’t
> > >> great,
> > >>>>>> because
> > >>>>>>> while changes may be getting out into production somewhere it’s
> > >>> only
> > >>>> you
> > >>>>>>> who is benefitting. We need releases from branch-1.3 a lot more
> > >>>>>> frequently
> > >>>>>>> or it’s a bad deal for the community. Committers have to deal
> > >> with
> > >>>>>>> effectively a dead branch. Users get no releases. Given the
> > >>> consensus
> > >>>>>>> expressed on this thread we don’t want this deal. It’s great that
> > >>>> you’ve
> > >>>>>>> stepped forward to offer ongoing RM activity. We will need this
> > >>>>>> commitment
> > >>>>>>> and a new pattern of more frequent releasing to justify keeping
> > >> the
> > >>>> code
> > >>>>>>> line alive, I think.
> > >>>>>>>
> > >>>>>>> Did you see that I stepped forward to make a release? There is a
> > >>> VOTE
> > >>>>>>> thread now for 1.3.3RC0.  Perhaps we can start there? Would you
> > >> use
> > >>>> it?
> > >>>>>>> Would you +1? Or are there changes in there that are of concern?
> > >>>> Please
> > >>>>>>> consider commenting on the VOTE.
> > >>>>>>>
> > >>>>>>>
> > >>>>>>>> On Dec 17, 2018, at 8:31 AM, Francis Christopher Liu <
> > >>>>>>> toffer.liu@gmail.com> wrote:
> > >>>>>>>>
> > >>>>>>>> Hi,
> > >>>>>>>>
> > >>>>>>>> Apologies a bit late to this discussion. I would still like to
> > >>>> continue
> > >>>>>>>> making 1.3 releases. If the concern is having a better cadence
> > >> of
> > >>>>>>> releases
> > >>>>>>>> let me know how often the community would like (quarterly,
> > >> every
> > >>>> other
> > >>>>>>>> month, etc) and I'll make sure to carve out time with my
> > >>> employer.
> > >>>> We
> > >>>>>>> will
> > >>>>>>>> be on 1.3 for a while. I believe it would be beneficial for the
> > >>>>>> community
> > >>>>>>>> and my employer for us to be on an active release line, hence
> > >> my
> > >>>>>>> interest.
> > >>>>>>>>
> > >>>>>>>> Let me know what you guys think?
> > >>>>>>>>
> > >>>>>>>> Thanks,
> > >>>>>>>> Francis
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>> On Mon, Dec 10, 2018 at 6:04 PM Andrew Purtell <
> > >>>> apurtell@apache.org>
> > >>>>>>> wrote:
> > >>>>>>>>>
> > >>>>>>>>> Thank you all for your comments. It looks like we have
> > >> consensus
> > >>>> to
> > >>>>>> EOL
> > >>>>>>> 1.3
> > >>>>>>>>> and RM one final release. I will start working on that
> > >> release,
> > >>>> 1.3.3,
> > >>>>>>> now.
> > >>>>>>>>>
> > >>>>>>>>>> On Mon, Dec 10, 2018 at 8:50 AM Josh Elser <
> > >> elserj@apache.org>
> > >>>>>> wrote:
> > >>>>>>>>>>
> > >>>>>>>>>> +1
> > >>>>>>>>>>
> > >>>>>>>>>>> On 12/7/18 2:24 PM, Andrew Purtell wrote:
> > >>>>>>>>>>> We haven't had a release from branch-1.3 for a long time and
> > >>> do
> > >>>> not
> > >>>>>>>>>> appear
> > >>>>>>>>>>> to have an active RM for it. Unless a RM for 1.3 steps
> > >> forward
> > >>>> and
> > >>>>>>>>>> promises
> > >>>>>>>>>>> to make a release in the very near future, I propose we make
> > >>> one
> > >>>>>> more
> > >>>>>>>>>>> release of 1.3, from the head of branch-1.3, and then retire
> > >>> the
> > >>>>>>>>> branch.
> > >>>>>>>>>> If
> > >>>>>>>>>>> this is acceptable I can RM the final 1.3 release.
> > >>>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>> --
> > >>>>>>>>> Best regards,
> > >>>>>>>>> Andrew
> > >>>>>>>>>
> > >>>>>>>>> Words like orphans lost among the crosstalk, meaning torn from
> > >>>> truth's
> > >>>>>>>>> decrepit hands
> > >>>>>>>>>  - A23, Crosstalk
> > >>>>>>>>>
> > >>>>>>>
> > >>>>>>
> > >>>>>
> > >>>>>
> > >>>>> --
> > >>>>> Best regards,
> > >>>>> Andrew
> > >>>>>
> > >>>>> Words like orphans lost among the crosstalk, meaning torn from
> > >> truth's
> > >>>>> decrepit hands
> > >>>>>   - A23, Crosstalk
> > >>>>
> > >>>
> > >>
> >
>


-- 
Best regards,
Andrew

Words like orphans lost among the crosstalk, meaning torn from truth's
decrepit hands
   - A23, Crosstalk

Re: [DISCUSS] EOL branch-1.3

[Francis Christopher Liu <to...@gmail.com>]

> If you have local changes you’d like to upstream please open JIRAs or
update the fix version on existing to include 1.5.0 so we can gather them
into a list and consider them. Although, I’d like to release 1.5.0 in
January 2019 so maybe we need a new fix version of 1.6.0 to denote
significant changes to hit later in the year? (Like split meta?)

That'd be great if we can get it in a branch-1 release. Tho it's a stretch
to make it by January 2019 so prolly 1.6 then. To start I'll work on
putting up the split meta patch and we'll put up other smaller patches
while we get this one in.



On Wed, Dec 19, 2018 at 9:32 AM Andrew Purtell <an...@gmail.com>
wrote:

> Upstreaming local changes into a new (minor?) Apache release that we can
> circle around and upgrade to is our strategy too. One of my goals with
> branch-1 and upcoming releasing of 1.5.0 is that 1.5 is a functional
> superset of everything we depend on in production as well as all the other
> community improvements. Perhaps 1.5 can serve in the same way for you? If
> you have local changes you’d like to upstream please open JIRAs or update
> the fix version on existing to include 1.5.0 so we can gather them into a
> list and consider them. Although, I’d like to release 1.5.0 in January 2019
> so maybe we need a new fix version of 1.6.0 to denote significant changes
> to hit later in the year? (Like split meta?) That’s fine too.  But let’s
> organize your needs in a way we can track them.
>
>
> On Dec 19, 2018, at 12:52 AM, Francis Christopher Liu <
> toffer.liu@gmail.com> wrote:
>
> >> Granted, 1.3 was never declared the "stable" release line so folks
> should
> > have expected it could die off whenever, but it really sucks to not see
> > releases when you've decided to use a release line. All downstreamer
> users
> > shouldn't have to maintain a fork.
> >
> > Agreed, this is my fault and I apologize for that.
> >
> >> I've found in maintaining the 1.2 release line that the RM has to
> > proactively review all the commits at least up to the major release line
> in
> > order to make sure things get included.  As mentioned in a few different
> > DISCUSS threads, we have too many branches active and committers have
> > limited bandwidth so stuff gets missed. just doing it as a part of the
> > release takes quite some time if one hasn't been keeping an eye out.
> >
> > Agreed, I noticed this as well when cutting 1.3.2. There were a lot of
> > backporting jiras in the release. I also had the intent to monitor
> branch-1
> > for missed backports thanks for reminding me. If doing releases at a
> > monthly cadence then it won't be too bad during the time of release?
> >
> >> FWIW, I agree that effort towards getting your deployment onto a future
> > branch-1 release would be better. It'd be nice if that could include
> > discussing what it would take for periodic updates to future branch-1
> minor
> > releases to become your plan instead of e.g. sticking to branch-1.4.z
> >
> > Yes my proposal encapsulates that. Essentially if we push most of our
> > patches (especially the big ones) upstream then it won't be as big an
> > effort to move between branches that have them. (Also addressing the
> > question why it's difficult to move from 1.3 to 1.4).
> >
> >> On Mon, Dec 17, 2018 at 5:41 PM Sean Busbey <bu...@apache.org> wrote:
> >>
> >> If I really stop to reflect on it, I'm fine with whatever for the
> branch. I
> >> just want to make sure we're proactively setting expectations for
> >> downstream users.
> >>
> >> Granted, 1.3 was never declared the "stable" release line so folks
> should
> >> have expected it could die off whenever, but it really sucks to not see
> >> releases when you've decided to use a release line. All downstreamer
> users
> >> shouldn't have to maintain a fork.
> >>
> >> I've found in maintaining the 1.2 release line that the RM has to
> >> proactively review all the commits at least up to the major release
> line in
> >> order to make sure things get included. As mentioned in a few different
> >> DISCUSS threads, we have too many branches active and committers have
> >> limited bandwidth so stuff gets missed. just doing it as a part of the
> >> release takes quite some time if one hasn't been keeping an eye out.
> >>
> >> FWIW, I agree that effort towards getting your deployment onto a future
> >> branch-1 release would be better. It'd be nice if that could include
> >> discussing what it would take for periodic updates to future branch-1
> minor
> >> releases to become your plan instead of e.g. sticking to branch-1.4.z
> >>
> >> On Mon, Dec 17, 2018, 18:38 Francis Christopher Liu <
> toffer.liu@gmail.com
> >> wrote:
> >>
> >>>> How about we have a probationary period where the RM takes care of
> >>> pulling in changes for branch-1.3 releases? After say a quarter of
> >>> hitting a monthly cadence we go back to committers proactively
> >>> including the branch.
> >>>
> >>> How about I just release monthly during the probationary period?
> >> Monitoring
> >>> and backporting all patches sounds like effort that would be better
> >>> allocated to open sourcing our internal patches? Or if you want some
> >>> measure of me/us upstreaming patches (works towards moving to a newer
> >>> branch). That seems much more beneficial for all?
> >>>
> >>>
> >>>
> >>>> On Mon, Dec 17, 2018 at 3:09 PM Sean Busbey <bu...@apache.org>
> wrote:
> >>>>
> >>>> I've worked to get back to monthly because I don't think quarterly is
> >>>> often enough to be useful. (but take this with a grain of salt since I
> >>>> am not a user of the branch in question)
> >>>>
> >>>> - 1.2.9: 2018-11-27
> >>>> - 1.2.8: 2018-10-20
> >>>> - 1.2.7: 2018-09-16
> >>>>
> >>>> I'll be starting 1.2.10 soon.
> >>>>
> >>>> I'm still happy to have releases from an EOL branch. I just expect
> >>>> that the RM will handle the backporting process for that branch so
> >>>> committers don't have to worry about it when accepting contributions.
> >>>>
> >>>> How about we have a probationary period where the RM takes care of
> >>>> pulling in changes for branch-1.3 releases? After say a quarter of
> >>>> hitting a monthly cadence we go back to committers proactively
> >>>> including the branch. If we don't hit the releases then we declare the
> >>>> branch EOL. That designation which still would allow for releases, but
> >>>> would change cadence expectations, update status on the downloads
> >>>> listing, docs, and avoid committers having to think about the branch.
> >>>> On Mon, Dec 17, 2018 at 1:32 PM Andrew Purtell <ap...@apache.org>
> >>>> wrote:
> >>>>>
> >>>>> I have been releasing 1.4 semi-monthly (usually, monthly) and Sean
> >> has
> >>>> been
> >>>>> releasing 1.2 every quarter. So maybe quarterly releases would be
> >> good?
> >>>>> What do others think? What is the minimum release schedule to make it
> >>>> worth
> >>>>> your while for commits/backports to a branch? At least once every
> >> half
> >>>>> year? More often?
> >>>>>
> >>>>> On Mon, Dec 17, 2018 at 11:23 AM Francis Christopher Liu <
> >>>>> toffer.liu@gmail.com> wrote:
> >>>>>
> >>>>>>> Given there was no release activity on 1.3 all year may I ask how
> >>>> you are
> >>>>>> using 1.3? Are you consuming upstream changes by cherry pick into
> >> an
> >>>>>> internal branch?
> >>>>>> It depends on the urgency of an internal release we either pull in
> >>> all
> >>>>>> changes up to a release, tip or cherry-pick. For the more recent
> >>>> releases
> >>>>>> we've been cherry picking. Tho we intend to pull in all changes
> >>> again.
> >>>> BTW
> >>>>>> I did release 1.3.2 in March.
> >>>>>>
> >>>>>>> It’s great that you’ve stepped forward to offer ongoing RM
> >> activity.
> >>>> We
> >>>>>> will need this commitment and a new pattern of more frequent
> >>> releasing
> >>>> to
> >>>>>> justify keeping the code line alive, I think.
> >>>>>> Let me know what would be an acceptable release cadence and I'll
> >>> carve
> >>>> out
> >>>>>> time.
> >>>>>>
> >>>>>>> Did you see that I stepped forward to make a release? There is a
> >>> VOTE
> >>>>>> thread now for 1.3.3RC0.  Perhaps we can start there? Would you use
> >>> it?
> >>>>>> Would you +1? Or are there changes in there that are of concern?
> >>> Please
> >>>>>> consider commenting on the VOTE.
> >>>>>> Yes we will use it, my intention is to be as current to branch-1.3
> >> as
> >>>>>> possible. Yes, I intend to vote on the release. I am currently
> >>> running
> >>>> the
> >>>>>> unit test and going through the release. Apologies for you having
> >> to
> >>>> cut
> >>>>>> the release.
> >>>>>>
> >>>>>> Thanks,
> >>>>>> Francis
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> On Mon, Dec 17, 2018 at 8:48 AM Andrew Purtell <
> >>>> andrew.purtell@gmail.com>
> >>>>>> wrote:
> >>>>>>
> >>>>>>> It’s been a year since the last release. For what it’s worth I
> >> see
> >>> no
> >>>>>> harm
> >>>>>>> in continuing to release 1.3, but you have to consider how
> >>>> burdensome it
> >>>>>> is
> >>>>>>> to have an open code line that bug fixes need to be committed
> >> into.
> >>>> Given
> >>>>>>> there was no release activity on 1.3 all year may I ask how you
> >> are
> >>>> using
> >>>>>>> 1.3? Are you consuming upstream changes by cherry pick into an
> >>>> internal
> >>>>>>> branch? Or are you not consuming any upstream changes at all? If
> >>> the
> >>>>>>> latter, then what’s the point? If the former, it still isn’t
> >> great,
> >>>>>> because
> >>>>>>> while changes may be getting out into production somewhere it’s
> >>> only
> >>>> you
> >>>>>>> who is benefitting. We need releases from branch-1.3 a lot more
> >>>>>> frequently
> >>>>>>> or it’s a bad deal for the community. Committers have to deal
> >> with
> >>>>>>> effectively a dead branch. Users get no releases. Given the
> >>> consensus
> >>>>>>> expressed on this thread we don’t want this deal. It’s great that
> >>>> you’ve
> >>>>>>> stepped forward to offer ongoing RM activity. We will need this
> >>>>>> commitment
> >>>>>>> and a new pattern of more frequent releasing to justify keeping
> >> the
> >>>> code
> >>>>>>> line alive, I think.
> >>>>>>>
> >>>>>>> Did you see that I stepped forward to make a release? There is a
> >>> VOTE
> >>>>>>> thread now for 1.3.3RC0.  Perhaps we can start there? Would you
> >> use
> >>>> it?
> >>>>>>> Would you +1? Or are there changes in there that are of concern?
> >>>> Please
> >>>>>>> consider commenting on the VOTE.
> >>>>>>>
> >>>>>>>
> >>>>>>>> On Dec 17, 2018, at 8:31 AM, Francis Christopher Liu <
> >>>>>>> toffer.liu@gmail.com> wrote:
> >>>>>>>>
> >>>>>>>> Hi,
> >>>>>>>>
> >>>>>>>> Apologies a bit late to this discussion. I would still like to
> >>>> continue
> >>>>>>>> making 1.3 releases. If the concern is having a better cadence
> >> of
> >>>>>>> releases
> >>>>>>>> let me know how often the community would like (quarterly,
> >> every
> >>>> other
> >>>>>>>> month, etc) and I'll make sure to carve out time with my
> >>> employer.
> >>>> We
> >>>>>>> will
> >>>>>>>> be on 1.3 for a while. I believe it would be beneficial for the
> >>>>>> community
> >>>>>>>> and my employer for us to be on an active release line, hence
> >> my
> >>>>>>> interest.
> >>>>>>>>
> >>>>>>>> Let me know what you guys think?
> >>>>>>>>
> >>>>>>>> Thanks,
> >>>>>>>> Francis
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>> On Mon, Dec 10, 2018 at 6:04 PM Andrew Purtell <
> >>>> apurtell@apache.org>
> >>>>>>> wrote:
> >>>>>>>>>
> >>>>>>>>> Thank you all for your comments. It looks like we have
> >> consensus
> >>>> to
> >>>>>> EOL
> >>>>>>> 1.3
> >>>>>>>>> and RM one final release. I will start working on that
> >> release,
> >>>> 1.3.3,
> >>>>>>> now.
> >>>>>>>>>
> >>>>>>>>>> On Mon, Dec 10, 2018 at 8:50 AM Josh Elser <
> >> elserj@apache.org>
> >>>>>> wrote:
> >>>>>>>>>>
> >>>>>>>>>> +1
> >>>>>>>>>>
> >>>>>>>>>>> On 12/7/18 2:24 PM, Andrew Purtell wrote:
> >>>>>>>>>>> We haven't had a release from branch-1.3 for a long time and
> >>> do
> >>>> not
> >>>>>>>>>> appear
> >>>>>>>>>>> to have an active RM for it. Unless a RM for 1.3 steps
> >> forward
> >>>> and
> >>>>>>>>>> promises
> >>>>>>>>>>> to make a release in the very near future, I propose we make
> >>> one
> >>>>>> more
> >>>>>>>>>>> release of 1.3, from the head of branch-1.3, and then retire
> >>> the
> >>>>>>>>> branch.
> >>>>>>>>>> If
> >>>>>>>>>>> this is acceptable I can RM the final 1.3 release.
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> --
> >>>>>>>>> Best regards,
> >>>>>>>>> Andrew
> >>>>>>>>>
> >>>>>>>>> Words like orphans lost among the crosstalk, meaning torn from
> >>>> truth's
> >>>>>>>>> decrepit hands
> >>>>>>>>>  - A23, Crosstalk
> >>>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>>> --
> >>>>> Best regards,
> >>>>> Andrew
> >>>>>
> >>>>> Words like orphans lost among the crosstalk, meaning torn from
> >> truth's
> >>>>> decrepit hands
> >>>>>   - A23, Crosstalk
> >>>>
> >>>
> >>
>

Re: [DISCUSS] EOL branch-1.3

[Andrew Purtell <an...@gmail.com>]

Upstreaming local changes into a new (minor?) Apache release that we can circle around and upgrade to is our strategy too. One of my goals with branch-1 and upcoming releasing of 1.5.0 is that 1.5 is a functional superset of everything we depend on in production as well as all the other community improvements. Perhaps 1.5 can serve in the same way for you? If you have local changes you’d like to upstream please open JIRAs or update the fix version on existing to include 1.5.0 so we can gather them into a list and consider them. Although, I’d like to release 1.5.0 in January 2019 so maybe we need a new fix version of 1.6.0 to denote significant changes to hit later in the year? (Like split meta?) That’s fine too.  But let’s organize your needs in a way we can track them. 


On Dec 19, 2018, at 12:52 AM, Francis Christopher Liu <to...@gmail.com> wrote:

>> Granted, 1.3 was never declared the "stable" release line so folks should
> have expected it could die off whenever, but it really sucks to not see
> releases when you've decided to use a release line. All downstreamer users
> shouldn't have to maintain a fork.
> 
> Agreed, this is my fault and I apologize for that.
> 
>> I've found in maintaining the 1.2 release line that the RM has to
> proactively review all the commits at least up to the major release line in
> order to make sure things get included.  As mentioned in a few different
> DISCUSS threads, we have too many branches active and committers have
> limited bandwidth so stuff gets missed. just doing it as a part of the
> release takes quite some time if one hasn't been keeping an eye out.
> 
> Agreed, I noticed this as well when cutting 1.3.2. There were a lot of
> backporting jiras in the release. I also had the intent to monitor branch-1
> for missed backports thanks for reminding me. If doing releases at a
> monthly cadence then it won't be too bad during the time of release?
> 
>> FWIW, I agree that effort towards getting your deployment onto a future
> branch-1 release would be better. It'd be nice if that could include
> discussing what it would take for periodic updates to future branch-1 minor
> releases to become your plan instead of e.g. sticking to branch-1.4.z
> 
> Yes my proposal encapsulates that. Essentially if we push most of our
> patches (especially the big ones) upstream then it won't be as big an
> effort to move between branches that have them. (Also addressing the
> question why it's difficult to move from 1.3 to 1.4).
> 
>> On Mon, Dec 17, 2018 at 5:41 PM Sean Busbey <bu...@apache.org> wrote:
>> 
>> If I really stop to reflect on it, I'm fine with whatever for the branch. I
>> just want to make sure we're proactively setting expectations for
>> downstream users.
>> 
>> Granted, 1.3 was never declared the "stable" release line so folks should
>> have expected it could die off whenever, but it really sucks to not see
>> releases when you've decided to use a release line. All downstreamer users
>> shouldn't have to maintain a fork.
>> 
>> I've found in maintaining the 1.2 release line that the RM has to
>> proactively review all the commits at least up to the major release line in
>> order to make sure things get included. As mentioned in a few different
>> DISCUSS threads, we have too many branches active and committers have
>> limited bandwidth so stuff gets missed. just doing it as a part of the
>> release takes quite some time if one hasn't been keeping an eye out.
>> 
>> FWIW, I agree that effort towards getting your deployment onto a future
>> branch-1 release would be better. It'd be nice if that could include
>> discussing what it would take for periodic updates to future branch-1 minor
>> releases to become your plan instead of e.g. sticking to branch-1.4.z
>> 
>> On Mon, Dec 17, 2018, 18:38 Francis Christopher Liu <toffer.liu@gmail.com
>> wrote:
>> 
>>>> How about we have a probationary period where the RM takes care of
>>> pulling in changes for branch-1.3 releases? After say a quarter of
>>> hitting a monthly cadence we go back to committers proactively
>>> including the branch.
>>> 
>>> How about I just release monthly during the probationary period?
>> Monitoring
>>> and backporting all patches sounds like effort that would be better
>>> allocated to open sourcing our internal patches? Or if you want some
>>> measure of me/us upstreaming patches (works towards moving to a newer
>>> branch). That seems much more beneficial for all?
>>> 
>>> 
>>> 
>>>> On Mon, Dec 17, 2018 at 3:09 PM Sean Busbey <bu...@apache.org> wrote:
>>>> 
>>>> I've worked to get back to monthly because I don't think quarterly is
>>>> often enough to be useful. (but take this with a grain of salt since I
>>>> am not a user of the branch in question)
>>>> 
>>>> - 1.2.9: 2018-11-27
>>>> - 1.2.8: 2018-10-20
>>>> - 1.2.7: 2018-09-16
>>>> 
>>>> I'll be starting 1.2.10 soon.
>>>> 
>>>> I'm still happy to have releases from an EOL branch. I just expect
>>>> that the RM will handle the backporting process for that branch so
>>>> committers don't have to worry about it when accepting contributions.
>>>> 
>>>> How about we have a probationary period where the RM takes care of
>>>> pulling in changes for branch-1.3 releases? After say a quarter of
>>>> hitting a monthly cadence we go back to committers proactively
>>>> including the branch. If we don't hit the releases then we declare the
>>>> branch EOL. That designation which still would allow for releases, but
>>>> would change cadence expectations, update status on the downloads
>>>> listing, docs, and avoid committers having to think about the branch.
>>>> On Mon, Dec 17, 2018 at 1:32 PM Andrew Purtell <ap...@apache.org>
>>>> wrote:
>>>>> 
>>>>> I have been releasing 1.4 semi-monthly (usually, monthly) and Sean
>> has
>>>> been
>>>>> releasing 1.2 every quarter. So maybe quarterly releases would be
>> good?
>>>>> What do others think? What is the minimum release schedule to make it
>>>> worth
>>>>> your while for commits/backports to a branch? At least once every
>> half
>>>>> year? More often?
>>>>> 
>>>>> On Mon, Dec 17, 2018 at 11:23 AM Francis Christopher Liu <
>>>>> toffer.liu@gmail.com> wrote:
>>>>> 
>>>>>>> Given there was no release activity on 1.3 all year may I ask how
>>>> you are
>>>>>> using 1.3? Are you consuming upstream changes by cherry pick into
>> an
>>>>>> internal branch?
>>>>>> It depends on the urgency of an internal release we either pull in
>>> all
>>>>>> changes up to a release, tip or cherry-pick. For the more recent
>>>> releases
>>>>>> we've been cherry picking. Tho we intend to pull in all changes
>>> again.
>>>> BTW
>>>>>> I did release 1.3.2 in March.
>>>>>> 
>>>>>>> It’s great that you’ve stepped forward to offer ongoing RM
>> activity.
>>>> We
>>>>>> will need this commitment and a new pattern of more frequent
>>> releasing
>>>> to
>>>>>> justify keeping the code line alive, I think.
>>>>>> Let me know what would be an acceptable release cadence and I'll
>>> carve
>>>> out
>>>>>> time.
>>>>>> 
>>>>>>> Did you see that I stepped forward to make a release? There is a
>>> VOTE
>>>>>> thread now for 1.3.3RC0.  Perhaps we can start there? Would you use
>>> it?
>>>>>> Would you +1? Or are there changes in there that are of concern?
>>> Please
>>>>>> consider commenting on the VOTE.
>>>>>> Yes we will use it, my intention is to be as current to branch-1.3
>> as
>>>>>> possible. Yes, I intend to vote on the release. I am currently
>>> running
>>>> the
>>>>>> unit test and going through the release. Apologies for you having
>> to
>>>> cut
>>>>>> the release.
>>>>>> 
>>>>>> Thanks,
>>>>>> Francis
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> On Mon, Dec 17, 2018 at 8:48 AM Andrew Purtell <
>>>> andrew.purtell@gmail.com>
>>>>>> wrote:
>>>>>> 
>>>>>>> It’s been a year since the last release. For what it’s worth I
>> see
>>> no
>>>>>> harm
>>>>>>> in continuing to release 1.3, but you have to consider how
>>>> burdensome it
>>>>>> is
>>>>>>> to have an open code line that bug fixes need to be committed
>> into.
>>>> Given
>>>>>>> there was no release activity on 1.3 all year may I ask how you
>> are
>>>> using
>>>>>>> 1.3? Are you consuming upstream changes by cherry pick into an
>>>> internal
>>>>>>> branch? Or are you not consuming any upstream changes at all? If
>>> the
>>>>>>> latter, then what’s the point? If the former, it still isn’t
>> great,
>>>>>> because
>>>>>>> while changes may be getting out into production somewhere it’s
>>> only
>>>> you
>>>>>>> who is benefitting. We need releases from branch-1.3 a lot more
>>>>>> frequently
>>>>>>> or it’s a bad deal for the community. Committers have to deal
>> with
>>>>>>> effectively a dead branch. Users get no releases. Given the
>>> consensus
>>>>>>> expressed on this thread we don’t want this deal. It’s great that
>>>> you’ve
>>>>>>> stepped forward to offer ongoing RM activity. We will need this
>>>>>> commitment
>>>>>>> and a new pattern of more frequent releasing to justify keeping
>> the
>>>> code
>>>>>>> line alive, I think.
>>>>>>> 
>>>>>>> Did you see that I stepped forward to make a release? There is a
>>> VOTE
>>>>>>> thread now for 1.3.3RC0.  Perhaps we can start there? Would you
>> use
>>>> it?
>>>>>>> Would you +1? Or are there changes in there that are of concern?
>>>> Please
>>>>>>> consider commenting on the VOTE.
>>>>>>> 
>>>>>>> 
>>>>>>>> On Dec 17, 2018, at 8:31 AM, Francis Christopher Liu <
>>>>>>> toffer.liu@gmail.com> wrote:
>>>>>>>> 
>>>>>>>> Hi,
>>>>>>>> 
>>>>>>>> Apologies a bit late to this discussion. I would still like to
>>>> continue
>>>>>>>> making 1.3 releases. If the concern is having a better cadence
>> of
>>>>>>> releases
>>>>>>>> let me know how often the community would like (quarterly,
>> every
>>>> other
>>>>>>>> month, etc) and I'll make sure to carve out time with my
>>> employer.
>>>> We
>>>>>>> will
>>>>>>>> be on 1.3 for a while. I believe it would be beneficial for the
>>>>>> community
>>>>>>>> and my employer for us to be on an active release line, hence
>> my
>>>>>>> interest.
>>>>>>>> 
>>>>>>>> Let me know what you guys think?
>>>>>>>> 
>>>>>>>> Thanks,
>>>>>>>> Francis
>>>>>>>> 
>>>>>>>> 
>>>>>>>>> On Mon, Dec 10, 2018 at 6:04 PM Andrew Purtell <
>>>> apurtell@apache.org>
>>>>>>> wrote:
>>>>>>>>> 
>>>>>>>>> Thank you all for your comments. It looks like we have
>> consensus
>>>> to
>>>>>> EOL
>>>>>>> 1.3
>>>>>>>>> and RM one final release. I will start working on that
>> release,
>>>> 1.3.3,
>>>>>>> now.
>>>>>>>>> 
>>>>>>>>>> On Mon, Dec 10, 2018 at 8:50 AM Josh Elser <
>> elserj@apache.org>
>>>>>> wrote:
>>>>>>>>>> 
>>>>>>>>>> +1
>>>>>>>>>> 
>>>>>>>>>>> On 12/7/18 2:24 PM, Andrew Purtell wrote:
>>>>>>>>>>> We haven't had a release from branch-1.3 for a long time and
>>> do
>>>> not
>>>>>>>>>> appear
>>>>>>>>>>> to have an active RM for it. Unless a RM for 1.3 steps
>> forward
>>>> and
>>>>>>>>>> promises
>>>>>>>>>>> to make a release in the very near future, I propose we make
>>> one
>>>>>> more
>>>>>>>>>>> release of 1.3, from the head of branch-1.3, and then retire
>>> the
>>>>>>>>> branch.
>>>>>>>>>> If
>>>>>>>>>>> this is acceptable I can RM the final 1.3 release.
>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> --
>>>>>>>>> Best regards,
>>>>>>>>> Andrew
>>>>>>>>> 
>>>>>>>>> Words like orphans lost among the crosstalk, meaning torn from
>>>> truth's
>>>>>>>>> decrepit hands
>>>>>>>>>  - A23, Crosstalk
>>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>> 
>>>>> 
>>>>> --
>>>>> Best regards,
>>>>> Andrew
>>>>> 
>>>>> Words like orphans lost among the crosstalk, meaning torn from
>> truth's
>>>>> decrepit hands
>>>>>   - A23, Crosstalk
>>>> 
>>> 
>> 

Re: [DISCUSS] EOL branch-1.3

[Francis Christopher Liu <to...@gmail.com>]

> Granted, 1.3 was never declared the "stable" release line so folks should
have expected it could die off whenever, but it really sucks to not see
releases when you've decided to use a release line. All downstreamer users
shouldn't have to maintain a fork.

Agreed, this is my fault and I apologize for that.

> I've found in maintaining the 1.2 release line that the RM has to
proactively review all the commits at least up to the major release line in
order to make sure things get included.  As mentioned in a few different
DISCUSS threads, we have too many branches active and committers have
limited bandwidth so stuff gets missed. just doing it as a part of the
release takes quite some time if one hasn't been keeping an eye out.

Agreed, I noticed this as well when cutting 1.3.2. There were a lot of
backporting jiras in the release. I also had the intent to monitor branch-1
for missed backports thanks for reminding me. If doing releases at a
monthly cadence then it won't be too bad during the time of release?

> FWIW, I agree that effort towards getting your deployment onto a future
branch-1 release would be better. It'd be nice if that could include
discussing what it would take for periodic updates to future branch-1 minor
releases to become your plan instead of e.g. sticking to branch-1.4.z

Yes my proposal encapsulates that. Essentially if we push most of our
patches (especially the big ones) upstream then it won't be as big an
effort to move between branches that have them. (Also addressing the
question why it's difficult to move from 1.3 to 1.4).

On Mon, Dec 17, 2018 at 5:41 PM Sean Busbey <bu...@apache.org> wrote:

> If I really stop to reflect on it, I'm fine with whatever for the branch. I
> just want to make sure we're proactively setting expectations for
> downstream users.
>
> Granted, 1.3 was never declared the "stable" release line so folks should
> have expected it could die off whenever, but it really sucks to not see
> releases when you've decided to use a release line. All downstreamer users
> shouldn't have to maintain a fork.
>
> I've found in maintaining the 1.2 release line that the RM has to
> proactively review all the commits at least up to the major release line in
> order to make sure things get included. As mentioned in a few different
> DISCUSS threads, we have too many branches active and committers have
> limited bandwidth so stuff gets missed. just doing it as a part of the
> release takes quite some time if one hasn't been keeping an eye out.
>
> FWIW, I agree that effort towards getting your deployment onto a future
> branch-1 release would be better. It'd be nice if that could include
> discussing what it would take for periodic updates to future branch-1 minor
> releases to become your plan instead of e.g. sticking to branch-1.4.z
>
> On Mon, Dec 17, 2018, 18:38 Francis Christopher Liu <toffer.liu@gmail.com
> wrote:
>
> > > How about we have a probationary period where the RM takes care of
> > pulling in changes for branch-1.3 releases? After say a quarter of
> > hitting a monthly cadence we go back to committers proactively
> > including the branch.
> >
> > How about I just release monthly during the probationary period?
> Monitoring
> > and backporting all patches sounds like effort that would be better
> > allocated to open sourcing our internal patches? Or if you want some
> > measure of me/us upstreaming patches (works towards moving to a newer
> > branch). That seems much more beneficial for all?
> >
> >
> >
> > On Mon, Dec 17, 2018 at 3:09 PM Sean Busbey <bu...@apache.org> wrote:
> >
> > > I've worked to get back to monthly because I don't think quarterly is
> > > often enough to be useful. (but take this with a grain of salt since I
> > > am not a user of the branch in question)
> > >
> > > - 1.2.9: 2018-11-27
> > > - 1.2.8: 2018-10-20
> > > - 1.2.7: 2018-09-16
> > >
> > > I'll be starting 1.2.10 soon.
> > >
> > > I'm still happy to have releases from an EOL branch. I just expect
> > > that the RM will handle the backporting process for that branch so
> > > committers don't have to worry about it when accepting contributions.
> > >
> > > How about we have a probationary period where the RM takes care of
> > > pulling in changes for branch-1.3 releases? After say a quarter of
> > > hitting a monthly cadence we go back to committers proactively
> > > including the branch. If we don't hit the releases then we declare the
> > > branch EOL. That designation which still would allow for releases, but
> > > would change cadence expectations, update status on the downloads
> > > listing, docs, and avoid committers having to think about the branch.
> > > On Mon, Dec 17, 2018 at 1:32 PM Andrew Purtell <ap...@apache.org>
> > > wrote:
> > > >
> > > > I have been releasing 1.4 semi-monthly (usually, monthly) and Sean
> has
> > > been
> > > > releasing 1.2 every quarter. So maybe quarterly releases would be
> good?
> > > > What do others think? What is the minimum release schedule to make it
> > > worth
> > > > your while for commits/backports to a branch? At least once every
> half
> > > > year? More often?
> > > >
> > > > On Mon, Dec 17, 2018 at 11:23 AM Francis Christopher Liu <
> > > > toffer.liu@gmail.com> wrote:
> > > >
> > > > > > Given there was no release activity on 1.3 all year may I ask how
> > > you are
> > > > > using 1.3? Are you consuming upstream changes by cherry pick into
> an
> > > > > internal branch?
> > > > > It depends on the urgency of an internal release we either pull in
> > all
> > > > > changes up to a release, tip or cherry-pick. For the more recent
> > > releases
> > > > > we've been cherry picking. Tho we intend to pull in all changes
> > again.
> > > BTW
> > > > > I did release 1.3.2 in March.
> > > > >
> > > > > >It’s great that you’ve stepped forward to offer ongoing RM
> activity.
> > > We
> > > > > will need this commitment and a new pattern of more frequent
> > releasing
> > > to
> > > > > justify keeping the code line alive, I think.
> > > > > Let me know what would be an acceptable release cadence and I'll
> > carve
> > > out
> > > > > time.
> > > > >
> > > > > >Did you see that I stepped forward to make a release? There is a
> > VOTE
> > > > > thread now for 1.3.3RC0.  Perhaps we can start there? Would you use
> > it?
> > > > > Would you +1? Or are there changes in there that are of concern?
> > Please
> > > > > consider commenting on the VOTE.
> > > > > Yes we will use it, my intention is to be as current to branch-1.3
> as
> > > > > possible. Yes, I intend to vote on the release. I am currently
> > running
> > > the
> > > > > unit test and going through the release. Apologies for you having
> to
> > > cut
> > > > > the release.
> > > > >
> > > > > Thanks,
> > > > > Francis
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > On Mon, Dec 17, 2018 at 8:48 AM Andrew Purtell <
> > > andrew.purtell@gmail.com>
> > > > > wrote:
> > > > >
> > > > > > It’s been a year since the last release. For what it’s worth I
> see
> > no
> > > > > harm
> > > > > > in continuing to release 1.3, but you have to consider how
> > > burdensome it
> > > > > is
> > > > > > to have an open code line that bug fixes need to be committed
> into.
> > > Given
> > > > > > there was no release activity on 1.3 all year may I ask how you
> are
> > > using
> > > > > > 1.3? Are you consuming upstream changes by cherry pick into an
> > > internal
> > > > > > branch? Or are you not consuming any upstream changes at all? If
> > the
> > > > > > latter, then what’s the point? If the former, it still isn’t
> great,
> > > > > because
> > > > > > while changes may be getting out into production somewhere it’s
> > only
> > > you
> > > > > > who is benefitting. We need releases from branch-1.3 a lot more
> > > > > frequently
> > > > > > or it’s a bad deal for the community. Committers have to deal
> with
> > > > > > effectively a dead branch. Users get no releases. Given the
> > consensus
> > > > > > expressed on this thread we don’t want this deal. It’s great that
> > > you’ve
> > > > > > stepped forward to offer ongoing RM activity. We will need this
> > > > > commitment
> > > > > > and a new pattern of more frequent releasing to justify keeping
> the
> > > code
> > > > > > line alive, I think.
> > > > > >
> > > > > > Did you see that I stepped forward to make a release? There is a
> > VOTE
> > > > > > thread now for 1.3.3RC0.  Perhaps we can start there? Would you
> use
> > > it?
> > > > > > Would you +1? Or are there changes in there that are of concern?
> > > Please
> > > > > > consider commenting on the VOTE.
> > > > > >
> > > > > >
> > > > > > > On Dec 17, 2018, at 8:31 AM, Francis Christopher Liu <
> > > > > > toffer.liu@gmail.com> wrote:
> > > > > > >
> > > > > > > Hi,
> > > > > > >
> > > > > > > Apologies a bit late to this discussion. I would still like to
> > > continue
> > > > > > > making 1.3 releases. If the concern is having a better cadence
> of
> > > > > > releases
> > > > > > > let me know how often the community would like (quarterly,
> every
> > > other
> > > > > > > month, etc) and I'll make sure to carve out time with my
> > employer.
> > > We
> > > > > > will
> > > > > > > be on 1.3 for a while. I believe it would be beneficial for the
> > > > > community
> > > > > > > and my employer for us to be on an active release line, hence
> my
> > > > > > interest.
> > > > > > >
> > > > > > > Let me know what you guys think?
> > > > > > >
> > > > > > > Thanks,
> > > > > > > Francis
> > > > > > >
> > > > > > >
> > > > > > >> On Mon, Dec 10, 2018 at 6:04 PM Andrew Purtell <
> > > apurtell@apache.org>
> > > > > > wrote:
> > > > > > >>
> > > > > > >> Thank you all for your comments. It looks like we have
> consensus
> > > to
> > > > > EOL
> > > > > > 1.3
> > > > > > >> and RM one final release. I will start working on that
> release,
> > > 1.3.3,
> > > > > > now.
> > > > > > >>
> > > > > > >>> On Mon, Dec 10, 2018 at 8:50 AM Josh Elser <
> elserj@apache.org>
> > > > > wrote:
> > > > > > >>>
> > > > > > >>> +1
> > > > > > >>>
> > > > > > >>>> On 12/7/18 2:24 PM, Andrew Purtell wrote:
> > > > > > >>>> We haven't had a release from branch-1.3 for a long time and
> > do
> > > not
> > > > > > >>> appear
> > > > > > >>>> to have an active RM for it. Unless a RM for 1.3 steps
> forward
> > > and
> > > > > > >>> promises
> > > > > > >>>> to make a release in the very near future, I propose we make
> > one
> > > > > more
> > > > > > >>>> release of 1.3, from the head of branch-1.3, and then retire
> > the
> > > > > > >> branch.
> > > > > > >>> If
> > > > > > >>>> this is acceptable I can RM the final 1.3 release.
> > > > > > >>>>
> > > > > > >>>
> > > > > > >>
> > > > > > >>
> > > > > > >> --
> > > > > > >> Best regards,
> > > > > > >> Andrew
> > > > > > >>
> > > > > > >> Words like orphans lost among the crosstalk, meaning torn from
> > > truth's
> > > > > > >> decrepit hands
> > > > > > >>   - A23, Crosstalk
> > > > > > >>
> > > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > > Best regards,
> > > > Andrew
> > > >
> > > > Words like orphans lost among the crosstalk, meaning torn from
> truth's
> > > > decrepit hands
> > > >    - A23, Crosstalk
> > >
> >
>

Re: [DISCUSS] EOL branch-1.3

[Sean Busbey <bu...@apache.org>]

If I really stop to reflect on it, I'm fine with whatever for the branch. I
just want to make sure we're proactively setting expectations for
downstream users.

Granted, 1.3 was never declared the "stable" release line so folks should
have expected it could die off whenever, but it really sucks to not see
releases when you've decided to use a release line. All downstreamer users
shouldn't have to maintain a fork.

I've found in maintaining the 1.2 release line that the RM has to
proactively review all the commits at least up to the major release line in
order to make sure things get included. As mentioned in a few different
DISCUSS threads, we have too many branches active and committers have
limited bandwidth so stuff gets missed. just doing it as a part of the
release takes quite some time if one hasn't been keeping an eye out.

FWIW, I agree that effort towards getting your deployment onto a future
branch-1 release would be better. It'd be nice if that could include
discussing what it would take for periodic updates to future branch-1 minor
releases to become your plan instead of e.g. sticking to branch-1.4.z

On Mon, Dec 17, 2018, 18:38 Francis Christopher Liu <toffer.liu@gmail.com
wrote:

> > How about we have a probationary period where the RM takes care of
> pulling in changes for branch-1.3 releases? After say a quarter of
> hitting a monthly cadence we go back to committers proactively
> including the branch.
>
> How about I just release monthly during the probationary period? Monitoring
> and backporting all patches sounds like effort that would be better
> allocated to open sourcing our internal patches? Or if you want some
> measure of me/us upstreaming patches (works towards moving to a newer
> branch). That seems much more beneficial for all?
>
>
>
> On Mon, Dec 17, 2018 at 3:09 PM Sean Busbey <bu...@apache.org> wrote:
>
> > I've worked to get back to monthly because I don't think quarterly is
> > often enough to be useful. (but take this with a grain of salt since I
> > am not a user of the branch in question)
> >
> > - 1.2.9: 2018-11-27
> > - 1.2.8: 2018-10-20
> > - 1.2.7: 2018-09-16
> >
> > I'll be starting 1.2.10 soon.
> >
> > I'm still happy to have releases from an EOL branch. I just expect
> > that the RM will handle the backporting process for that branch so
> > committers don't have to worry about it when accepting contributions.
> >
> > How about we have a probationary period where the RM takes care of
> > pulling in changes for branch-1.3 releases? After say a quarter of
> > hitting a monthly cadence we go back to committers proactively
> > including the branch. If we don't hit the releases then we declare the
> > branch EOL. That designation which still would allow for releases, but
> > would change cadence expectations, update status on the downloads
> > listing, docs, and avoid committers having to think about the branch.
> > On Mon, Dec 17, 2018 at 1:32 PM Andrew Purtell <ap...@apache.org>
> > wrote:
> > >
> > > I have been releasing 1.4 semi-monthly (usually, monthly) and Sean has
> > been
> > > releasing 1.2 every quarter. So maybe quarterly releases would be good?
> > > What do others think? What is the minimum release schedule to make it
> > worth
> > > your while for commits/backports to a branch? At least once every half
> > > year? More often?
> > >
> > > On Mon, Dec 17, 2018 at 11:23 AM Francis Christopher Liu <
> > > toffer.liu@gmail.com> wrote:
> > >
> > > > > Given there was no release activity on 1.3 all year may I ask how
> > you are
> > > > using 1.3? Are you consuming upstream changes by cherry pick into an
> > > > internal branch?
> > > > It depends on the urgency of an internal release we either pull in
> all
> > > > changes up to a release, tip or cherry-pick. For the more recent
> > releases
> > > > we've been cherry picking. Tho we intend to pull in all changes
> again.
> > BTW
> > > > I did release 1.3.2 in March.
> > > >
> > > > >It’s great that you’ve stepped forward to offer ongoing RM activity.
> > We
> > > > will need this commitment and a new pattern of more frequent
> releasing
> > to
> > > > justify keeping the code line alive, I think.
> > > > Let me know what would be an acceptable release cadence and I'll
> carve
> > out
> > > > time.
> > > >
> > > > >Did you see that I stepped forward to make a release? There is a
> VOTE
> > > > thread now for 1.3.3RC0.  Perhaps we can start there? Would you use
> it?
> > > > Would you +1? Or are there changes in there that are of concern?
> Please
> > > > consider commenting on the VOTE.
> > > > Yes we will use it, my intention is to be as current to branch-1.3 as
> > > > possible. Yes, I intend to vote on the release. I am currently
> running
> > the
> > > > unit test and going through the release. Apologies for you having to
> > cut
> > > > the release.
> > > >
> > > > Thanks,
> > > > Francis
> > > >
> > > >
> > > >
> > > >
> > > > On Mon, Dec 17, 2018 at 8:48 AM Andrew Purtell <
> > andrew.purtell@gmail.com>
> > > > wrote:
> > > >
> > > > > It’s been a year since the last release. For what it’s worth I see
> no
> > > > harm
> > > > > in continuing to release 1.3, but you have to consider how
> > burdensome it
> > > > is
> > > > > to have an open code line that bug fixes need to be committed into.
> > Given
> > > > > there was no release activity on 1.3 all year may I ask how you are
> > using
> > > > > 1.3? Are you consuming upstream changes by cherry pick into an
> > internal
> > > > > branch? Or are you not consuming any upstream changes at all? If
> the
> > > > > latter, then what’s the point? If the former, it still isn’t great,
> > > > because
> > > > > while changes may be getting out into production somewhere it’s
> only
> > you
> > > > > who is benefitting. We need releases from branch-1.3 a lot more
> > > > frequently
> > > > > or it’s a bad deal for the community. Committers have to deal with
> > > > > effectively a dead branch. Users get no releases. Given the
> consensus
> > > > > expressed on this thread we don’t want this deal. It’s great that
> > you’ve
> > > > > stepped forward to offer ongoing RM activity. We will need this
> > > > commitment
> > > > > and a new pattern of more frequent releasing to justify keeping the
> > code
> > > > > line alive, I think.
> > > > >
> > > > > Did you see that I stepped forward to make a release? There is a
> VOTE
> > > > > thread now for 1.3.3RC0.  Perhaps we can start there? Would you use
> > it?
> > > > > Would you +1? Or are there changes in there that are of concern?
> > Please
> > > > > consider commenting on the VOTE.
> > > > >
> > > > >
> > > > > > On Dec 17, 2018, at 8:31 AM, Francis Christopher Liu <
> > > > > toffer.liu@gmail.com> wrote:
> > > > > >
> > > > > > Hi,
> > > > > >
> > > > > > Apologies a bit late to this discussion. I would still like to
> > continue
> > > > > > making 1.3 releases. If the concern is having a better cadence of
> > > > > releases
> > > > > > let me know how often the community would like (quarterly, every
> > other
> > > > > > month, etc) and I'll make sure to carve out time with my
> employer.
> > We
> > > > > will
> > > > > > be on 1.3 for a while. I believe it would be beneficial for the
> > > > community
> > > > > > and my employer for us to be on an active release line, hence my
> > > > > interest.
> > > > > >
> > > > > > Let me know what you guys think?
> > > > > >
> > > > > > Thanks,
> > > > > > Francis
> > > > > >
> > > > > >
> > > > > >> On Mon, Dec 10, 2018 at 6:04 PM Andrew Purtell <
> > apurtell@apache.org>
> > > > > wrote:
> > > > > >>
> > > > > >> Thank you all for your comments. It looks like we have consensus
> > to
> > > > EOL
> > > > > 1.3
> > > > > >> and RM one final release. I will start working on that release,
> > 1.3.3,
> > > > > now.
> > > > > >>
> > > > > >>> On Mon, Dec 10, 2018 at 8:50 AM Josh Elser <el...@apache.org>
> > > > wrote:
> > > > > >>>
> > > > > >>> +1
> > > > > >>>
> > > > > >>>> On 12/7/18 2:24 PM, Andrew Purtell wrote:
> > > > > >>>> We haven't had a release from branch-1.3 for a long time and
> do
> > not
> > > > > >>> appear
> > > > > >>>> to have an active RM for it. Unless a RM for 1.3 steps forward
> > and
> > > > > >>> promises
> > > > > >>>> to make a release in the very near future, I propose we make
> one
> > > > more
> > > > > >>>> release of 1.3, from the head of branch-1.3, and then retire
> the
> > > > > >> branch.
> > > > > >>> If
> > > > > >>>> this is acceptable I can RM the final 1.3 release.
> > > > > >>>>
> > > > > >>>
> > > > > >>
> > > > > >>
> > > > > >> --
> > > > > >> Best regards,
> > > > > >> Andrew
> > > > > >>
> > > > > >> Words like orphans lost among the crosstalk, meaning torn from
> > truth's
> > > > > >> decrepit hands
> > > > > >>   - A23, Crosstalk
> > > > > >>
> > > > >
> > > >
> > >
> > >
> > > --
> > > Best regards,
> > > Andrew
> > >
> > > Words like orphans lost among the crosstalk, meaning torn from truth's
> > > decrepit hands
> > >    - A23, Crosstalk
> >
>

Re: [DISCUSS] EOL branch-1.3

[Francis Christopher Liu <to...@gmail.com>]

> How about we have a probationary period where the RM takes care of
pulling in changes for branch-1.3 releases? After say a quarter of
hitting a monthly cadence we go back to committers proactively
including the branch.

How about I just release monthly during the probationary period? Monitoring
and backporting all patches sounds like effort that would be better
allocated to open sourcing our internal patches? Or if you want some
measure of me/us upstreaming patches (works towards moving to a newer
branch). That seems much more beneficial for all?



On Mon, Dec 17, 2018 at 3:09 PM Sean Busbey <bu...@apache.org> wrote:

> I've worked to get back to monthly because I don't think quarterly is
> often enough to be useful. (but take this with a grain of salt since I
> am not a user of the branch in question)
>
> - 1.2.9: 2018-11-27
> - 1.2.8: 2018-10-20
> - 1.2.7: 2018-09-16
>
> I'll be starting 1.2.10 soon.
>
> I'm still happy to have releases from an EOL branch. I just expect
> that the RM will handle the backporting process for that branch so
> committers don't have to worry about it when accepting contributions.
>
> How about we have a probationary period where the RM takes care of
> pulling in changes for branch-1.3 releases? After say a quarter of
> hitting a monthly cadence we go back to committers proactively
> including the branch. If we don't hit the releases then we declare the
> branch EOL. That designation which still would allow for releases, but
> would change cadence expectations, update status on the downloads
> listing, docs, and avoid committers having to think about the branch.
> On Mon, Dec 17, 2018 at 1:32 PM Andrew Purtell <ap...@apache.org>
> wrote:
> >
> > I have been releasing 1.4 semi-monthly (usually, monthly) and Sean has
> been
> > releasing 1.2 every quarter. So maybe quarterly releases would be good?
> > What do others think? What is the minimum release schedule to make it
> worth
> > your while for commits/backports to a branch? At least once every half
> > year? More often?
> >
> > On Mon, Dec 17, 2018 at 11:23 AM Francis Christopher Liu <
> > toffer.liu@gmail.com> wrote:
> >
> > > > Given there was no release activity on 1.3 all year may I ask how
> you are
> > > using 1.3? Are you consuming upstream changes by cherry pick into an
> > > internal branch?
> > > It depends on the urgency of an internal release we either pull in all
> > > changes up to a release, tip or cherry-pick. For the more recent
> releases
> > > we've been cherry picking. Tho we intend to pull in all changes again.
> BTW
> > > I did release 1.3.2 in March.
> > >
> > > >It’s great that you’ve stepped forward to offer ongoing RM activity.
> We
> > > will need this commitment and a new pattern of more frequent releasing
> to
> > > justify keeping the code line alive, I think.
> > > Let me know what would be an acceptable release cadence and I'll carve
> out
> > > time.
> > >
> > > >Did you see that I stepped forward to make a release? There is a VOTE
> > > thread now for 1.3.3RC0.  Perhaps we can start there? Would you use it?
> > > Would you +1? Or are there changes in there that are of concern? Please
> > > consider commenting on the VOTE.
> > > Yes we will use it, my intention is to be as current to branch-1.3 as
> > > possible. Yes, I intend to vote on the release. I am currently running
> the
> > > unit test and going through the release. Apologies for you having to
> cut
> > > the release.
> > >
> > > Thanks,
> > > Francis
> > >
> > >
> > >
> > >
> > > On Mon, Dec 17, 2018 at 8:48 AM Andrew Purtell <
> andrew.purtell@gmail.com>
> > > wrote:
> > >
> > > > It’s been a year since the last release. For what it’s worth I see no
> > > harm
> > > > in continuing to release 1.3, but you have to consider how
> burdensome it
> > > is
> > > > to have an open code line that bug fixes need to be committed into.
> Given
> > > > there was no release activity on 1.3 all year may I ask how you are
> using
> > > > 1.3? Are you consuming upstream changes by cherry pick into an
> internal
> > > > branch? Or are you not consuming any upstream changes at all? If the
> > > > latter, then what’s the point? If the former, it still isn’t great,
> > > because
> > > > while changes may be getting out into production somewhere it’s only
> you
> > > > who is benefitting. We need releases from branch-1.3 a lot more
> > > frequently
> > > > or it’s a bad deal for the community. Committers have to deal with
> > > > effectively a dead branch. Users get no releases. Given the consensus
> > > > expressed on this thread we don’t want this deal. It’s great that
> you’ve
> > > > stepped forward to offer ongoing RM activity. We will need this
> > > commitment
> > > > and a new pattern of more frequent releasing to justify keeping the
> code
> > > > line alive, I think.
> > > >
> > > > Did you see that I stepped forward to make a release? There is a VOTE
> > > > thread now for 1.3.3RC0.  Perhaps we can start there? Would you use
> it?
> > > > Would you +1? Or are there changes in there that are of concern?
> Please
> > > > consider commenting on the VOTE.
> > > >
> > > >
> > > > > On Dec 17, 2018, at 8:31 AM, Francis Christopher Liu <
> > > > toffer.liu@gmail.com> wrote:
> > > > >
> > > > > Hi,
> > > > >
> > > > > Apologies a bit late to this discussion. I would still like to
> continue
> > > > > making 1.3 releases. If the concern is having a better cadence of
> > > > releases
> > > > > let me know how often the community would like (quarterly, every
> other
> > > > > month, etc) and I'll make sure to carve out time with my employer.
> We
> > > > will
> > > > > be on 1.3 for a while. I believe it would be beneficial for the
> > > community
> > > > > and my employer for us to be on an active release line, hence my
> > > > interest.
> > > > >
> > > > > Let me know what you guys think?
> > > > >
> > > > > Thanks,
> > > > > Francis
> > > > >
> > > > >
> > > > >> On Mon, Dec 10, 2018 at 6:04 PM Andrew Purtell <
> apurtell@apache.org>
> > > > wrote:
> > > > >>
> > > > >> Thank you all for your comments. It looks like we have consensus
> to
> > > EOL
> > > > 1.3
> > > > >> and RM one final release. I will start working on that release,
> 1.3.3,
> > > > now.
> > > > >>
> > > > >>> On Mon, Dec 10, 2018 at 8:50 AM Josh Elser <el...@apache.org>
> > > wrote:
> > > > >>>
> > > > >>> +1
> > > > >>>
> > > > >>>> On 12/7/18 2:24 PM, Andrew Purtell wrote:
> > > > >>>> We haven't had a release from branch-1.3 for a long time and do
> not
> > > > >>> appear
> > > > >>>> to have an active RM for it. Unless a RM for 1.3 steps forward
> and
> > > > >>> promises
> > > > >>>> to make a release in the very near future, I propose we make one
> > > more
> > > > >>>> release of 1.3, from the head of branch-1.3, and then retire the
> > > > >> branch.
> > > > >>> If
> > > > >>>> this is acceptable I can RM the final 1.3 release.
> > > > >>>>
> > > > >>>
> > > > >>
> > > > >>
> > > > >> --
> > > > >> Best regards,
> > > > >> Andrew
> > > > >>
> > > > >> Words like orphans lost among the crosstalk, meaning torn from
> truth's
> > > > >> decrepit hands
> > > > >>   - A23, Crosstalk
> > > > >>
> > > >
> > >
> >
> >
> > --
> > Best regards,
> > Andrew
> >
> > Words like orphans lost among the crosstalk, meaning torn from truth's
> > decrepit hands
> >    - A23, Crosstalk
>

Re: [DISCUSS] EOL branch-1.3

[Sean Busbey <bu...@apache.org>]

I've worked to get back to monthly because I don't think quarterly is
often enough to be useful. (but take this with a grain of salt since I
am not a user of the branch in question)

- 1.2.9: 2018-11-27
- 1.2.8: 2018-10-20
- 1.2.7: 2018-09-16

I'll be starting 1.2.10 soon.

I'm still happy to have releases from an EOL branch. I just expect
that the RM will handle the backporting process for that branch so
committers don't have to worry about it when accepting contributions.

How about we have a probationary period where the RM takes care of
pulling in changes for branch-1.3 releases? After say a quarter of
hitting a monthly cadence we go back to committers proactively
including the branch. If we don't hit the releases then we declare the
branch EOL. That designation which still would allow for releases, but
would change cadence expectations, update status on the downloads
listing, docs, and avoid committers having to think about the branch.
On Mon, Dec 17, 2018 at 1:32 PM Andrew Purtell <ap...@apache.org> wrote:
>
> I have been releasing 1.4 semi-monthly (usually, monthly) and Sean has been
> releasing 1.2 every quarter. So maybe quarterly releases would be good?
> What do others think? What is the minimum release schedule to make it worth
> your while for commits/backports to a branch? At least once every half
> year? More often?
>
> On Mon, Dec 17, 2018 at 11:23 AM Francis Christopher Liu <
> toffer.liu@gmail.com> wrote:
>
> > > Given there was no release activity on 1.3 all year may I ask how you are
> > using 1.3? Are you consuming upstream changes by cherry pick into an
> > internal branch?
> > It depends on the urgency of an internal release we either pull in all
> > changes up to a release, tip or cherry-pick. For the more recent releases
> > we've been cherry picking. Tho we intend to pull in all changes again. BTW
> > I did release 1.3.2 in March.
> >
> > >It’s great that you’ve stepped forward to offer ongoing RM activity. We
> > will need this commitment and a new pattern of more frequent releasing to
> > justify keeping the code line alive, I think.
> > Let me know what would be an acceptable release cadence and I'll carve out
> > time.
> >
> > >Did you see that I stepped forward to make a release? There is a VOTE
> > thread now for 1.3.3RC0.  Perhaps we can start there? Would you use it?
> > Would you +1? Or are there changes in there that are of concern? Please
> > consider commenting on the VOTE.
> > Yes we will use it, my intention is to be as current to branch-1.3 as
> > possible. Yes, I intend to vote on the release. I am currently running the
> > unit test and going through the release. Apologies for you having to cut
> > the release.
> >
> > Thanks,
> > Francis
> >
> >
> >
> >
> > On Mon, Dec 17, 2018 at 8:48 AM Andrew Purtell <an...@gmail.com>
> > wrote:
> >
> > > It’s been a year since the last release. For what it’s worth I see no
> > harm
> > > in continuing to release 1.3, but you have to consider how burdensome it
> > is
> > > to have an open code line that bug fixes need to be committed into. Given
> > > there was no release activity on 1.3 all year may I ask how you are using
> > > 1.3? Are you consuming upstream changes by cherry pick into an internal
> > > branch? Or are you not consuming any upstream changes at all? If the
> > > latter, then what’s the point? If the former, it still isn’t great,
> > because
> > > while changes may be getting out into production somewhere it’s only you
> > > who is benefitting. We need releases from branch-1.3 a lot more
> > frequently
> > > or it’s a bad deal for the community. Committers have to deal with
> > > effectively a dead branch. Users get no releases. Given the consensus
> > > expressed on this thread we don’t want this deal. It’s great that you’ve
> > > stepped forward to offer ongoing RM activity. We will need this
> > commitment
> > > and a new pattern of more frequent releasing to justify keeping the code
> > > line alive, I think.
> > >
> > > Did you see that I stepped forward to make a release? There is a VOTE
> > > thread now for 1.3.3RC0.  Perhaps we can start there? Would you use it?
> > > Would you +1? Or are there changes in there that are of concern? Please
> > > consider commenting on the VOTE.
> > >
> > >
> > > > On Dec 17, 2018, at 8:31 AM, Francis Christopher Liu <
> > > toffer.liu@gmail.com> wrote:
> > > >
> > > > Hi,
> > > >
> > > > Apologies a bit late to this discussion. I would still like to continue
> > > > making 1.3 releases. If the concern is having a better cadence of
> > > releases
> > > > let me know how often the community would like (quarterly, every other
> > > > month, etc) and I'll make sure to carve out time with my employer. We
> > > will
> > > > be on 1.3 for a while. I believe it would be beneficial for the
> > community
> > > > and my employer for us to be on an active release line, hence my
> > > interest.
> > > >
> > > > Let me know what you guys think?
> > > >
> > > > Thanks,
> > > > Francis
> > > >
> > > >
> > > >> On Mon, Dec 10, 2018 at 6:04 PM Andrew Purtell <ap...@apache.org>
> > > wrote:
> > > >>
> > > >> Thank you all for your comments. It looks like we have consensus to
> > EOL
> > > 1.3
> > > >> and RM one final release. I will start working on that release, 1.3.3,
> > > now.
> > > >>
> > > >>> On Mon, Dec 10, 2018 at 8:50 AM Josh Elser <el...@apache.org>
> > wrote:
> > > >>>
> > > >>> +1
> > > >>>
> > > >>>> On 12/7/18 2:24 PM, Andrew Purtell wrote:
> > > >>>> We haven't had a release from branch-1.3 for a long time and do not
> > > >>> appear
> > > >>>> to have an active RM for it. Unless a RM for 1.3 steps forward and
> > > >>> promises
> > > >>>> to make a release in the very near future, I propose we make one
> > more
> > > >>>> release of 1.3, from the head of branch-1.3, and then retire the
> > > >> branch.
> > > >>> If
> > > >>>> this is acceptable I can RM the final 1.3 release.
> > > >>>>
> > > >>>
> > > >>
> > > >>
> > > >> --
> > > >> Best regards,
> > > >> Andrew
> > > >>
> > > >> Words like orphans lost among the crosstalk, meaning torn from truth's
> > > >> decrepit hands
> > > >>   - A23, Crosstalk
> > > >>
> > >
> >
>
>
> --
> Best regards,
> Andrew
>
> Words like orphans lost among the crosstalk, meaning torn from truth's
> decrepit hands
>    - A23, Crosstalk

Re: [DISCUSS] EOL branch-1.3

[Andrew Purtell <ap...@apache.org>]

I have been releasing 1.4 semi-monthly (usually, monthly) and Sean has been
releasing 1.2 every quarter. So maybe quarterly releases would be good?
What do others think? What is the minimum release schedule to make it worth
your while for commits/backports to a branch? At least once every half
year? More often?

On Mon, Dec 17, 2018 at 11:23 AM Francis Christopher Liu <
toffer.liu@gmail.com> wrote:

> > Given there was no release activity on 1.3 all year may I ask how you are
> using 1.3? Are you consuming upstream changes by cherry pick into an
> internal branch?
> It depends on the urgency of an internal release we either pull in all
> changes up to a release, tip or cherry-pick. For the more recent releases
> we've been cherry picking. Tho we intend to pull in all changes again. BTW
> I did release 1.3.2 in March.
>
> >It’s great that you’ve stepped forward to offer ongoing RM activity. We
> will need this commitment and a new pattern of more frequent releasing to
> justify keeping the code line alive, I think.
> Let me know what would be an acceptable release cadence and I'll carve out
> time.
>
> >Did you see that I stepped forward to make a release? There is a VOTE
> thread now for 1.3.3RC0.  Perhaps we can start there? Would you use it?
> Would you +1? Or are there changes in there that are of concern? Please
> consider commenting on the VOTE.
> Yes we will use it, my intention is to be as current to branch-1.3 as
> possible. Yes, I intend to vote on the release. I am currently running the
> unit test and going through the release. Apologies for you having to cut
> the release.
>
> Thanks,
> Francis
>
>
>
>
> On Mon, Dec 17, 2018 at 8:48 AM Andrew Purtell <an...@gmail.com>
> wrote:
>
> > It’s been a year since the last release. For what it’s worth I see no
> harm
> > in continuing to release 1.3, but you have to consider how burdensome it
> is
> > to have an open code line that bug fixes need to be committed into. Given
> > there was no release activity on 1.3 all year may I ask how you are using
> > 1.3? Are you consuming upstream changes by cherry pick into an internal
> > branch? Or are you not consuming any upstream changes at all? If the
> > latter, then what’s the point? If the former, it still isn’t great,
> because
> > while changes may be getting out into production somewhere it’s only you
> > who is benefitting. We need releases from branch-1.3 a lot more
> frequently
> > or it’s a bad deal for the community. Committers have to deal with
> > effectively a dead branch. Users get no releases. Given the consensus
> > expressed on this thread we don’t want this deal. It’s great that you’ve
> > stepped forward to offer ongoing RM activity. We will need this
> commitment
> > and a new pattern of more frequent releasing to justify keeping the code
> > line alive, I think.
> >
> > Did you see that I stepped forward to make a release? There is a VOTE
> > thread now for 1.3.3RC0.  Perhaps we can start there? Would you use it?
> > Would you +1? Or are there changes in there that are of concern? Please
> > consider commenting on the VOTE.
> >
> >
> > > On Dec 17, 2018, at 8:31 AM, Francis Christopher Liu <
> > toffer.liu@gmail.com> wrote:
> > >
> > > Hi,
> > >
> > > Apologies a bit late to this discussion. I would still like to continue
> > > making 1.3 releases. If the concern is having a better cadence of
> > releases
> > > let me know how often the community would like (quarterly, every other
> > > month, etc) and I'll make sure to carve out time with my employer. We
> > will
> > > be on 1.3 for a while. I believe it would be beneficial for the
> community
> > > and my employer for us to be on an active release line, hence my
> > interest.
> > >
> > > Let me know what you guys think?
> > >
> > > Thanks,
> > > Francis
> > >
> > >
> > >> On Mon, Dec 10, 2018 at 6:04 PM Andrew Purtell <ap...@apache.org>
> > wrote:
> > >>
> > >> Thank you all for your comments. It looks like we have consensus to
> EOL
> > 1.3
> > >> and RM one final release. I will start working on that release, 1.3.3,
> > now.
> > >>
> > >>> On Mon, Dec 10, 2018 at 8:50 AM Josh Elser <el...@apache.org>
> wrote:
> > >>>
> > >>> +1
> > >>>
> > >>>> On 12/7/18 2:24 PM, Andrew Purtell wrote:
> > >>>> We haven't had a release from branch-1.3 for a long time and do not
> > >>> appear
> > >>>> to have an active RM for it. Unless a RM for 1.3 steps forward and
> > >>> promises
> > >>>> to make a release in the very near future, I propose we make one
> more
> > >>>> release of 1.3, from the head of branch-1.3, and then retire the
> > >> branch.
> > >>> If
> > >>>> this is acceptable I can RM the final 1.3 release.
> > >>>>
> > >>>
> > >>
> > >>
> > >> --
> > >> Best regards,
> > >> Andrew
> > >>
> > >> Words like orphans lost among the crosstalk, meaning torn from truth's
> > >> decrepit hands
> > >>   - A23, Crosstalk
> > >>
> >
>


-- 
Best regards,
Andrew

Words like orphans lost among the crosstalk, meaning torn from truth's
decrepit hands
   - A23, Crosstalk

Re: [DISCUSS] EOL branch-1.3

[Francis Christopher Liu <to...@gmail.com>]

> Given there was no release activity on 1.3 all year may I ask how you are
using 1.3? Are you consuming upstream changes by cherry pick into an
internal branch?
It depends on the urgency of an internal release we either pull in all
changes up to a release, tip or cherry-pick. For the more recent releases
we've been cherry picking. Tho we intend to pull in all changes again. BTW
I did release 1.3.2 in March.

>It’s great that you’ve stepped forward to offer ongoing RM activity. We
will need this commitment and a new pattern of more frequent releasing to
justify keeping the code line alive, I think.
Let me know what would be an acceptable release cadence and I'll carve out
time.

>Did you see that I stepped forward to make a release? There is a VOTE
thread now for 1.3.3RC0.  Perhaps we can start there? Would you use it?
Would you +1? Or are there changes in there that are of concern? Please
consider commenting on the VOTE.
Yes we will use it, my intention is to be as current to branch-1.3 as
possible. Yes, I intend to vote on the release. I am currently running the
unit test and going through the release. Apologies for you having to cut
the release.

Thanks,
Francis




On Mon, Dec 17, 2018 at 8:48 AM Andrew Purtell <an...@gmail.com>
wrote:

> It’s been a year since the last release. For what it’s worth I see no harm
> in continuing to release 1.3, but you have to consider how burdensome it is
> to have an open code line that bug fixes need to be committed into. Given
> there was no release activity on 1.3 all year may I ask how you are using
> 1.3? Are you consuming upstream changes by cherry pick into an internal
> branch? Or are you not consuming any upstream changes at all? If the
> latter, then what’s the point? If the former, it still isn’t great, because
> while changes may be getting out into production somewhere it’s only you
> who is benefitting. We need releases from branch-1.3 a lot more frequently
> or it’s a bad deal for the community. Committers have to deal with
> effectively a dead branch. Users get no releases. Given the consensus
> expressed on this thread we don’t want this deal. It’s great that you’ve
> stepped forward to offer ongoing RM activity. We will need this commitment
> and a new pattern of more frequent releasing to justify keeping the code
> line alive, I think.
>
> Did you see that I stepped forward to make a release? There is a VOTE
> thread now for 1.3.3RC0.  Perhaps we can start there? Would you use it?
> Would you +1? Or are there changes in there that are of concern? Please
> consider commenting on the VOTE.
>
>
> > On Dec 17, 2018, at 8:31 AM, Francis Christopher Liu <
> toffer.liu@gmail.com> wrote:
> >
> > Hi,
> >
> > Apologies a bit late to this discussion. I would still like to continue
> > making 1.3 releases. If the concern is having a better cadence of
> releases
> > let me know how often the community would like (quarterly, every other
> > month, etc) and I'll make sure to carve out time with my employer. We
> will
> > be on 1.3 for a while. I believe it would be beneficial for the community
> > and my employer for us to be on an active release line, hence my
> interest.
> >
> > Let me know what you guys think?
> >
> > Thanks,
> > Francis
> >
> >
> >> On Mon, Dec 10, 2018 at 6:04 PM Andrew Purtell <ap...@apache.org>
> wrote:
> >>
> >> Thank you all for your comments. It looks like we have consensus to EOL
> 1.3
> >> and RM one final release. I will start working on that release, 1.3.3,
> now.
> >>
> >>> On Mon, Dec 10, 2018 at 8:50 AM Josh Elser <el...@apache.org> wrote:
> >>>
> >>> +1
> >>>
> >>>> On 12/7/18 2:24 PM, Andrew Purtell wrote:
> >>>> We haven't had a release from branch-1.3 for a long time and do not
> >>> appear
> >>>> to have an active RM for it. Unless a RM for 1.3 steps forward and
> >>> promises
> >>>> to make a release in the very near future, I propose we make one more
> >>>> release of 1.3, from the head of branch-1.3, and then retire the
> >> branch.
> >>> If
> >>>> this is acceptable I can RM the final 1.3 release.
> >>>>
> >>>
> >>
> >>
> >> --
> >> Best regards,
> >> Andrew
> >>
> >> Words like orphans lost among the crosstalk, meaning torn from truth's
> >> decrepit hands
> >>   - A23, Crosstalk
> >>
>

Re: [DISCUSS] EOL branch-1.3

[Andrew Purtell <an...@gmail.com>]

It’s been a year since the last release. For what it’s worth I see no harm in continuing to release 1.3, but you have to consider how burdensome it is to have an open code line that bug fixes need to be committed into. Given there was no release activity on 1.3 all year may I ask how you are using 1.3? Are you consuming upstream changes by cherry pick into an internal branch? Or are you not consuming any upstream changes at all? If the latter, then what’s the point? If the former, it still isn’t great, because while changes may be getting out into production somewhere it’s only you who is benefitting. We need releases from branch-1.3 a lot more frequently or it’s a bad deal for the community. Committers have to deal with effectively a dead branch. Users get no releases. Given the consensus expressed on this thread we don’t want this deal. It’s great that you’ve stepped forward to offer ongoing RM activity. We will need this commitment and a new pattern of more frequent releasing to justify keeping the code line alive, I think. 

Did you see that I stepped forward to make a release? There is a VOTE thread now for 1.3.3RC0.  Perhaps we can start there? Would you use it? Would you +1? Or are there changes in there that are of concern? Please consider commenting on the VOTE. 


> On Dec 17, 2018, at 8:31 AM, Francis Christopher Liu <to...@gmail.com> wrote:
> 
> Hi,
> 
> Apologies a bit late to this discussion. I would still like to continue
> making 1.3 releases. If the concern is having a better cadence of releases
> let me know how often the community would like (quarterly, every other
> month, etc) and I'll make sure to carve out time with my employer. We will
> be on 1.3 for a while. I believe it would be beneficial for the community
> and my employer for us to be on an active release line, hence my interest.
> 
> Let me know what you guys think?
> 
> Thanks,
> Francis
> 
> 
>> On Mon, Dec 10, 2018 at 6:04 PM Andrew Purtell <ap...@apache.org> wrote:
>> 
>> Thank you all for your comments. It looks like we have consensus to EOL 1.3
>> and RM one final release. I will start working on that release, 1.3.3, now.
>> 
>>> On Mon, Dec 10, 2018 at 8:50 AM Josh Elser <el...@apache.org> wrote:
>>> 
>>> +1
>>> 
>>>> On 12/7/18 2:24 PM, Andrew Purtell wrote:
>>>> We haven't had a release from branch-1.3 for a long time and do not
>>> appear
>>>> to have an active RM for it. Unless a RM for 1.3 steps forward and
>>> promises
>>>> to make a release in the very near future, I propose we make one more
>>>> release of 1.3, from the head of branch-1.3, and then retire the
>> branch.
>>> If
>>>> this is acceptable I can RM the final 1.3 release.
>>>> 
>>> 
>> 
>> 
>> --
>> Best regards,
>> Andrew
>> 
>> Words like orphans lost among the crosstalk, meaning torn from truth's
>> decrepit hands
>>   - A23, Crosstalk
>> 

Re: [DISCUSS] EOL branch-1.3

[Francis Christopher Liu <to...@gmail.com>]

Hi,

Apologies a bit late to this discussion. I would still like to continue
making 1.3 releases. If the concern is having a better cadence of releases
let me know how often the community would like (quarterly, every other
month, etc) and I'll make sure to carve out time with my employer. We will
be on 1.3 for a while. I believe it would be beneficial for the community
and my employer for us to be on an active release line, hence my interest.

Let me know what you guys think?

Thanks,
Francis


On Mon, Dec 10, 2018 at 6:04 PM Andrew Purtell <ap...@apache.org> wrote:

> Thank you all for your comments. It looks like we have consensus to EOL 1.3
> and RM one final release. I will start working on that release, 1.3.3, now.
>
> On Mon, Dec 10, 2018 at 8:50 AM Josh Elser <el...@apache.org> wrote:
>
> > +1
> >
> > On 12/7/18 2:24 PM, Andrew Purtell wrote:
> > > We haven't had a release from branch-1.3 for a long time and do not
> > appear
> > > to have an active RM for it. Unless a RM for 1.3 steps forward and
> > promises
> > > to make a release in the very near future, I propose we make one more
> > > release of 1.3, from the head of branch-1.3, and then retire the
> branch.
> > If
> > > this is acceptable I can RM the final 1.3 release.
> > >
> >
>
>
> --
> Best regards,
> Andrew
>
> Words like orphans lost among the crosstalk, meaning torn from truth's
> decrepit hands
>    - A23, Crosstalk
>

Re: [DISCUSS] EOL branch-1.3

[Andrew Purtell <ap...@apache.org>]

Thank you all for your comments. It looks like we have consensus to EOL 1.3
and RM one final release. I will start working on that release, 1.3.3, now.

On Mon, Dec 10, 2018 at 8:50 AM Josh Elser <el...@apache.org> wrote:

> +1
>
> On 12/7/18 2:24 PM, Andrew Purtell wrote:
> > We haven't had a release from branch-1.3 for a long time and do not
> appear
> > to have an active RM for it. Unless a RM for 1.3 steps forward and
> promises
> > to make a release in the very near future, I propose we make one more
> > release of 1.3, from the head of branch-1.3, and then retire the branch.
> If
> > this is acceptable I can RM the final 1.3 release.
> >
>


-- 
Best regards,
Andrew

Words like orphans lost among the crosstalk, meaning torn from truth's
decrepit hands
   - A23, Crosstalk

Re: [DISCUSS] EOL branch-1.3

[Josh Elser <el...@apache.org>]

+1

On 12/7/18 2:24 PM, Andrew Purtell wrote:
> We haven't had a release from branch-1.3 for a long time and do not appear
> to have an active RM for it. Unless a RM for 1.3 steps forward and promises
> to make a release in the very near future, I propose we make one more
> release of 1.3, from the head of branch-1.3, and then retire the branch. If
> this is acceptable I can RM the final 1.3 release.
> 

Re: [DISCUSS] EOL branch-1.3

[Allan Yang <al...@apache.org>]

+1, the less, the better.
Best Regards
Allan Yang


Sean Busbey <bu...@apache.org> 于2018年12月8日周六 上午10:09写道：

> correct, branch-1.2 was the stable release line prior to 1.4 becoming
> it in August.
>
> at the time I said I'd keep making monthly 1.2.z releases for ~6 months:
>
> https://s.apache.org/EYkB
>
> I wanted to give folks who heed our "this is the stable line" advice a
> cushion for planning migration once we updated it to a different
> release line.
> On Fri, Dec 7, 2018 at 7:57 PM Guanghao Zhang <zg...@gmail.com> wrote:
> >
> > +1. But branch-1.2 is not EOL now?
> >
> > 张铎(Duo Zhang) <pa...@gmail.com> 于2018年12月8日周六 上午9:28写道：
> >
> > > +1.
> > >
> > > Andrew Purtell <ap...@apache.org> 于2018年12月8日周六 上午5:45写道：
> > >
> > > > I'm good with doing one more 1.3 release. It would be my pleasure to
> > > offer
> > > > that service to the community. I like RM-ing.
> > > >
> > > >
> > > > On Fri, Dec 7, 2018 at 12:29 PM Stack <st...@duboce.net> wrote:
> > > >
> > > > > +1
> > > > >
> > > > > (Pity you have to make a release to EOL it).
> > > > >
> > > > > S
> > > > >
> > > > > On Fri, Dec 7, 2018 at 11:25 AM Andrew Purtell <
> apurtell@apache.org>
> > > > > wrote:
> > > > >
> > > > > > We haven't had a release from branch-1.3 for a long time and do
> not
> > > > > appear
> > > > > > to have an active RM for it. Unless a RM for 1.3 steps forward
> and
> > > > > promises
> > > > > > to make a release in the very near future, I propose we make one
> more
> > > > > > release of 1.3, from the head of branch-1.3, and then retire the
> > > > branch.
> > > > > If
> > > > > > this is acceptable I can RM the final 1.3 release.
> > > > > >
> > > > > > --
> > > > > > Best regards,
> > > > > > Andrew
> > > > > >
> > > > > > Words like orphans lost among the crosstalk, meaning torn from
> > > truth's
> > > > > > decrepit hands
> > > > > >    - A23, Crosstalk
> > > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > > Best regards,
> > > > Andrew
> > > >
> > > > Words like orphans lost among the crosstalk, meaning torn from
> truth's
> > > > decrepit hands
> > > >    - A23, Crosstalk
> > > >
> > >
>

Re: [DISCUSS] EOL branch-1.3

[Allan Yang <al...@apache.org>]

+1, the less, the better.
Best Regards
Allan Yang


Sean Busbey <bu...@apache.org> 于2018年12月8日周六 上午10:09写道：

> correct, branch-1.2 was the stable release line prior to 1.4 becoming
> it in August.
>
> at the time I said I'd keep making monthly 1.2.z releases for ~6 months:
>
> https://s.apache.org/EYkB
>
> I wanted to give folks who heed our "this is the stable line" advice a
> cushion for planning migration once we updated it to a different
> release line.
> On Fri, Dec 7, 2018 at 7:57 PM Guanghao Zhang <zg...@gmail.com> wrote:
> >
> > +1. But branch-1.2 is not EOL now?
> >
> > 张铎(Duo Zhang) <pa...@gmail.com> 于2018年12月8日周六 上午9:28写道：
> >
> > > +1.
> > >
> > > Andrew Purtell <ap...@apache.org> 于2018年12月8日周六 上午5:45写道：
> > >
> > > > I'm good with doing one more 1.3 release. It would be my pleasure to
> > > offer
> > > > that service to the community. I like RM-ing.
> > > >
> > > >
> > > > On Fri, Dec 7, 2018 at 12:29 PM Stack <st...@duboce.net> wrote:
> > > >
> > > > > +1
> > > > >
> > > > > (Pity you have to make a release to EOL it).
> > > > >
> > > > > S
> > > > >
> > > > > On Fri, Dec 7, 2018 at 11:25 AM Andrew Purtell <
> apurtell@apache.org>
> > > > > wrote:
> > > > >
> > > > > > We haven't had a release from branch-1.3 for a long time and do
> not
> > > > > appear
> > > > > > to have an active RM for it. Unless a RM for 1.3 steps forward
> and
> > > > > promises
> > > > > > to make a release in the very near future, I propose we make one
> more
> > > > > > release of 1.3, from the head of branch-1.3, and then retire the
> > > > branch.
> > > > > If
> > > > > > this is acceptable I can RM the final 1.3 release.
> > > > > >
> > > > > > --
> > > > > > Best regards,
> > > > > > Andrew
> > > > > >
> > > > > > Words like orphans lost among the crosstalk, meaning torn from
> > > truth's
> > > > > > decrepit hands
> > > > > >    - A23, Crosstalk
> > > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > > Best regards,
> > > > Andrew
> > > >
> > > > Words like orphans lost among the crosstalk, meaning torn from
> truth's
> > > > decrepit hands
> > > >    - A23, Crosstalk
> > > >
> > >
>

Re: [DISCUSS] EOL branch-1.3

[Sean Busbey <bu...@apache.org>]

correct, branch-1.2 was the stable release line prior to 1.4 becoming
it in August.

at the time I said I'd keep making monthly 1.2.z releases for ~6 months:

https://s.apache.org/EYkB

I wanted to give folks who heed our "this is the stable line" advice a
cushion for planning migration once we updated it to a different
release line.
On Fri, Dec 7, 2018 at 7:57 PM Guanghao Zhang <zg...@gmail.com> wrote:
>
> +1. But branch-1.2 is not EOL now?
>
> 张铎(Duo Zhang) <pa...@gmail.com> 于2018年12月8日周六 上午9:28写道：
>
> > +1.
> >
> > Andrew Purtell <ap...@apache.org> 于2018年12月8日周六 上午5:45写道：
> >
> > > I'm good with doing one more 1.3 release. It would be my pleasure to
> > offer
> > > that service to the community. I like RM-ing.
> > >
> > >
> > > On Fri, Dec 7, 2018 at 12:29 PM Stack <st...@duboce.net> wrote:
> > >
> > > > +1
> > > >
> > > > (Pity you have to make a release to EOL it).
> > > >
> > > > S
> > > >
> > > > On Fri, Dec 7, 2018 at 11:25 AM Andrew Purtell <ap...@apache.org>
> > > > wrote:
> > > >
> > > > > We haven't had a release from branch-1.3 for a long time and do not
> > > > appear
> > > > > to have an active RM for it. Unless a RM for 1.3 steps forward and
> > > > promises
> > > > > to make a release in the very near future, I propose we make one more
> > > > > release of 1.3, from the head of branch-1.3, and then retire the
> > > branch.
> > > > If
> > > > > this is acceptable I can RM the final 1.3 release.
> > > > >
> > > > > --
> > > > > Best regards,
> > > > > Andrew
> > > > >
> > > > > Words like orphans lost among the crosstalk, meaning torn from
> > truth's
> > > > > decrepit hands
> > > > >    - A23, Crosstalk
> > > > >
> > > >
> > >
> > >
> > > --
> > > Best regards,
> > > Andrew
> > >
> > > Words like orphans lost among the crosstalk, meaning torn from truth's
> > > decrepit hands
> > >    - A23, Crosstalk
> > >
> >

Re: [DISCUSS] EOL branch-1.3

[Sean Busbey <bu...@apache.org>]

correct, branch-1.2 was the stable release line prior to 1.4 becoming
it in August.

at the time I said I'd keep making monthly 1.2.z releases for ~6 months:

https://s.apache.org/EYkB

I wanted to give folks who heed our "this is the stable line" advice a
cushion for planning migration once we updated it to a different
release line.
On Fri, Dec 7, 2018 at 7:57 PM Guanghao Zhang <zg...@gmail.com> wrote:
>
> +1. But branch-1.2 is not EOL now?
>
> 张铎(Duo Zhang) <pa...@gmail.com> 于2018年12月8日周六 上午9:28写道：
>
> > +1.
> >
> > Andrew Purtell <ap...@apache.org> 于2018年12月8日周六 上午5:45写道：
> >
> > > I'm good with doing one more 1.3 release. It would be my pleasure to
> > offer
> > > that service to the community. I like RM-ing.
> > >
> > >
> > > On Fri, Dec 7, 2018 at 12:29 PM Stack <st...@duboce.net> wrote:
> > >
> > > > +1
> > > >
> > > > (Pity you have to make a release to EOL it).
> > > >
> > > > S
> > > >
> > > > On Fri, Dec 7, 2018 at 11:25 AM Andrew Purtell <ap...@apache.org>
> > > > wrote:
> > > >
> > > > > We haven't had a release from branch-1.3 for a long time and do not
> > > > appear
> > > > > to have an active RM for it. Unless a RM for 1.3 steps forward and
> > > > promises
> > > > > to make a release in the very near future, I propose we make one more
> > > > > release of 1.3, from the head of branch-1.3, and then retire the
> > > branch.
> > > > If
> > > > > this is acceptable I can RM the final 1.3 release.
> > > > >
> > > > > --
> > > > > Best regards,
> > > > > Andrew
> > > > >
> > > > > Words like orphans lost among the crosstalk, meaning torn from
> > truth's
> > > > > decrepit hands
> > > > >    - A23, Crosstalk
> > > > >
> > > >
> > >
> > >
> > > --
> > > Best regards,
> > > Andrew
> > >
> > > Words like orphans lost among the crosstalk, meaning torn from truth's
> > > decrepit hands
> > >    - A23, Crosstalk
> > >
> >

Re: [DISCUSS] EOL branch-1.3

[Guanghao Zhang <zg...@gmail.com>]

+1. But branch-1.2 is not EOL now?

张铎(Duo Zhang) <pa...@gmail.com> 于2018年12月8日周六 上午9:28写道：

> +1.
>
> Andrew Purtell <ap...@apache.org> 于2018年12月8日周六 上午5:45写道：
>
> > I'm good with doing one more 1.3 release. It would be my pleasure to
> offer
> > that service to the community. I like RM-ing.
> >
> >
> > On Fri, Dec 7, 2018 at 12:29 PM Stack <st...@duboce.net> wrote:
> >
> > > +1
> > >
> > > (Pity you have to make a release to EOL it).
> > >
> > > S
> > >
> > > On Fri, Dec 7, 2018 at 11:25 AM Andrew Purtell <ap...@apache.org>
> > > wrote:
> > >
> > > > We haven't had a release from branch-1.3 for a long time and do not
> > > appear
> > > > to have an active RM for it. Unless a RM for 1.3 steps forward and
> > > promises
> > > > to make a release in the very near future, I propose we make one more
> > > > release of 1.3, from the head of branch-1.3, and then retire the
> > branch.
> > > If
> > > > this is acceptable I can RM the final 1.3 release.
> > > >
> > > > --
> > > > Best regards,
> > > > Andrew
> > > >
> > > > Words like orphans lost among the crosstalk, meaning torn from
> truth's
> > > > decrepit hands
> > > >    - A23, Crosstalk
> > > >
> > >
> >
> >
> > --
> > Best regards,
> > Andrew
> >
> > Words like orphans lost among the crosstalk, meaning torn from truth's
> > decrepit hands
> >    - A23, Crosstalk
> >
>

Re: [DISCUSS] EOL branch-1.3

[Guanghao Zhang <zg...@gmail.com>]

+1. But branch-1.2 is not EOL now?

张铎(Duo Zhang) <pa...@gmail.com> 于2018年12月8日周六 上午9:28写道：

> +1.
>
> Andrew Purtell <ap...@apache.org> 于2018年12月8日周六 上午5:45写道：
>
> > I'm good with doing one more 1.3 release. It would be my pleasure to
> offer
> > that service to the community. I like RM-ing.
> >
> >
> > On Fri, Dec 7, 2018 at 12:29 PM Stack <st...@duboce.net> wrote:
> >
> > > +1
> > >
> > > (Pity you have to make a release to EOL it).
> > >
> > > S
> > >
> > > On Fri, Dec 7, 2018 at 11:25 AM Andrew Purtell <ap...@apache.org>
> > > wrote:
> > >
> > > > We haven't had a release from branch-1.3 for a long time and do not
> > > appear
> > > > to have an active RM for it. Unless a RM for 1.3 steps forward and
> > > promises
> > > > to make a release in the very near future, I propose we make one more
> > > > release of 1.3, from the head of branch-1.3, and then retire the
> > branch.
> > > If
> > > > this is acceptable I can RM the final 1.3 release.
> > > >
> > > > --
> > > > Best regards,
> > > > Andrew
> > > >
> > > > Words like orphans lost among the crosstalk, meaning torn from
> truth's
> > > > decrepit hands
> > > >    - A23, Crosstalk
> > > >
> > >
> >
> >
> > --
> > Best regards,
> > Andrew
> >
> > Words like orphans lost among the crosstalk, meaning torn from truth's
> > decrepit hands
> >    - A23, Crosstalk
> >
>

Re: [DISCUSS] EOL branch-1.3

["张铎 (Duo Zhang)" <pa...@gmail.com>]

+1.

Andrew Purtell <ap...@apache.org> 于2018年12月8日周六 上午5:45写道：

> I'm good with doing one more 1.3 release. It would be my pleasure to offer
> that service to the community. I like RM-ing.
>
>
> On Fri, Dec 7, 2018 at 12:29 PM Stack <st...@duboce.net> wrote:
>
> > +1
> >
> > (Pity you have to make a release to EOL it).
> >
> > S
> >
> > On Fri, Dec 7, 2018 at 11:25 AM Andrew Purtell <ap...@apache.org>
> > wrote:
> >
> > > We haven't had a release from branch-1.3 for a long time and do not
> > appear
> > > to have an active RM for it. Unless a RM for 1.3 steps forward and
> > promises
> > > to make a release in the very near future, I propose we make one more
> > > release of 1.3, from the head of branch-1.3, and then retire the
> branch.
> > If
> > > this is acceptable I can RM the final 1.3 release.
> > >
> > > --
> > > Best regards,
> > > Andrew
> > >
> > > Words like orphans lost among the crosstalk, meaning torn from truth's
> > > decrepit hands
> > >    - A23, Crosstalk
> > >
> >
>
>
> --
> Best regards,
> Andrew
>
> Words like orphans lost among the crosstalk, meaning torn from truth's
> decrepit hands
>    - A23, Crosstalk
>

Re: [DISCUSS] EOL branch-1.3

["张铎 (Duo Zhang)" <pa...@gmail.com>]

+1.

Andrew Purtell <ap...@apache.org> 于2018年12月8日周六 上午5:45写道：

> I'm good with doing one more 1.3 release. It would be my pleasure to offer
> that service to the community. I like RM-ing.
>
>
> On Fri, Dec 7, 2018 at 12:29 PM Stack <st...@duboce.net> wrote:
>
> > +1
> >
> > (Pity you have to make a release to EOL it).
> >
> > S
> >
> > On Fri, Dec 7, 2018 at 11:25 AM Andrew Purtell <ap...@apache.org>
> > wrote:
> >
> > > We haven't had a release from branch-1.3 for a long time and do not
> > appear
> > > to have an active RM for it. Unless a RM for 1.3 steps forward and
> > promises
> > > to make a release in the very near future, I propose we make one more
> > > release of 1.3, from the head of branch-1.3, and then retire the
> branch.
> > If
> > > this is acceptable I can RM the final 1.3 release.
> > >
> > > --
> > > Best regards,
> > > Andrew
> > >
> > > Words like orphans lost among the crosstalk, meaning torn from truth's
> > > decrepit hands
> > >    - A23, Crosstalk
> > >
> >
>
>
> --
> Best regards,
> Andrew
>
> Words like orphans lost among the crosstalk, meaning torn from truth's
> decrepit hands
>    - A23, Crosstalk
>

Re: [DISCUSS] EOL branch-1.3

[Andrew Purtell <ap...@apache.org>]

I'm good with doing one more 1.3 release. It would be my pleasure to offer
that service to the community. I like RM-ing.


On Fri, Dec 7, 2018 at 12:29 PM Stack <st...@duboce.net> wrote:

> +1
>
> (Pity you have to make a release to EOL it).
>
> S
>
> On Fri, Dec 7, 2018 at 11:25 AM Andrew Purtell <ap...@apache.org>
> wrote:
>
> > We haven't had a release from branch-1.3 for a long time and do not
> appear
> > to have an active RM for it. Unless a RM for 1.3 steps forward and
> promises
> > to make a release in the very near future, I propose we make one more
> > release of 1.3, from the head of branch-1.3, and then retire the branch.
> If
> > this is acceptable I can RM the final 1.3 release.
> >
> > --
> > Best regards,
> > Andrew
> >
> > Words like orphans lost among the crosstalk, meaning torn from truth's
> > decrepit hands
> >    - A23, Crosstalk
> >
>


-- 
Best regards,
Andrew

Words like orphans lost among the crosstalk, meaning torn from truth's
decrepit hands
   - A23, Crosstalk

Re: [DISCUSS] EOL branch-1.3

[Andrew Purtell <ap...@apache.org>]

I'm good with doing one more 1.3 release. It would be my pleasure to offer
that service to the community. I like RM-ing.


On Fri, Dec 7, 2018 at 12:29 PM Stack <st...@duboce.net> wrote:

> +1
>
> (Pity you have to make a release to EOL it).
>
> S
>
> On Fri, Dec 7, 2018 at 11:25 AM Andrew Purtell <ap...@apache.org>
> wrote:
>
> > We haven't had a release from branch-1.3 for a long time and do not
> appear
> > to have an active RM for it. Unless a RM for 1.3 steps forward and
> promises
> > to make a release in the very near future, I propose we make one more
> > release of 1.3, from the head of branch-1.3, and then retire the branch.
> If
> > this is acceptable I can RM the final 1.3 release.
> >
> > --
> > Best regards,
> > Andrew
> >
> > Words like orphans lost among the crosstalk, meaning torn from truth's
> > decrepit hands
> >    - A23, Crosstalk
> >
>


-- 
Best regards,
Andrew

Words like orphans lost among the crosstalk, meaning torn from truth's
decrepit hands
   - A23, Crosstalk

Re: [DISCUSS] EOL branch-1.3

[Stack <st...@duboce.net>]

+1

(Pity you have to make a release to EOL it).

S

On Fri, Dec 7, 2018 at 11:25 AM Andrew Purtell <ap...@apache.org> wrote:

> We haven't had a release from branch-1.3 for a long time and do not appear
> to have an active RM for it. Unless a RM for 1.3 steps forward and promises
> to make a release in the very near future, I propose we make one more
> release of 1.3, from the head of branch-1.3, and then retire the branch. If
> this is acceptable I can RM the final 1.3 release.
>
> --
> Best regards,
> Andrew
>
> Words like orphans lost among the crosstalk, meaning torn from truth's
> decrepit hands
>    - A23, Crosstalk
>

Re: [DISCUSS] EOL branch-1.3

[Stack <st...@duboce.net>]

+1

(Pity you have to make a release to EOL it).

S

On Fri, Dec 7, 2018 at 11:25 AM Andrew Purtell <ap...@apache.org> wrote:

> We haven't had a release from branch-1.3 for a long time and do not appear
> to have an active RM for it. Unless a RM for 1.3 steps forward and promises
> to make a release in the very near future, I propose we make one more
> release of 1.3, from the head of branch-1.3, and then retire the branch. If
> this is acceptable I can RM the final 1.3 release.
>
> --
> Best regards,
> Andrew
>
> Words like orphans lost among the crosstalk, meaning torn from truth's
> decrepit hands
>    - A23, Crosstalk
>