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....@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 <bus...@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 <apurt...@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....@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.purt...@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....@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 < > > apurt...@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 <els...@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 > > >
