> 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 <[email protected]> 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 <[email protected] > 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 <[email protected]> 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 <[email protected]> > > > 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 < > > > > [email protected]> 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 < > > > [email protected]> > > > > > 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 < > > > > > > [email protected]> 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 < > > > [email protected]> > > > > > > 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 < > [email protected]> > > > > > 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 > > > > > >
