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