I can also start separate discussion thread on what prevents 1.3 (and 1.4 subsequently, though Andrew would be the right person here) from being marked stable in our books, so this issue gets more focused attention.
-Mikhail On Tue, Aug 8, 2017 at 8:10 AM, Mikhail Antonov <olorinb...@gmail.com> wrote: > I think in the dev community interest and ultimately in interest of our > users to have a fewer maintained branches. > > For a variety of reasons. > > Efforts put in the maintenance of old release lines is the effort not put > into releasing new ones, since community resources are > finite. Active backporting (beyond critical security fixes and such) of > new things somewhat reduces users incentive to upgrade often. Then we can > get in the loop situation when new major features aren't deemed very stable > - but it's really hard to get features of that complexity stable and robust > if they're not used beyond integration tests. > > So before we go too deeply into discussion on how to make backporting > easier, I'd rather see us focusing on releasing new branches and making > them stable. > > -Mikhail > > > > On Tue, Aug 8, 2017 at 7:10 AM, Sean Busbey <bus...@apache.org> wrote: > >> Are we approaching this problem wrong though? >> >> Most of the cherry picks I have to do to the maintenance release lines are >> clean. >> >> What if we get more tooling to help with the everything-goes-right case? >> >> My last read of asf policy and infra folks (from back in the website >> automation) is they won't look favorably on Jenkins pushing back ports >> into >> our repo. >> >> But! We could make something similar to the website job from back when a >> committer still had to do the git push. A nightly job that tries to cherry >> pick and gives us a set of back ports that worked. >> >> We could either have it look to jira for fix versions to try backporting >> to, or we could have it try everything and update jira with what worked. >> >> Thoughts? >> >> On Aug 8, 2017 02:14, "Stack" <st...@duboce.net> wrote: >> >> > (This came up during dev meeting in Shenzhen) We are running too many >> > branches and/or when applying patches, we do not do a good job >> backporting >> > to all active branches, especially fixes. >> > >> > We have master, branch-2, branch-1, branch-1.4, branch-1.3, branch-1.2, >> and >> > branch-1.1 active currently. If a dirty bug fix, the applier is >> backporting >> > to 7 branches. It takes a while applying to all especially if the >> backport >> > doesn't go in clean. I suppose the RM could monitor all upstream of them >> > and then pull wanted patches back (we could do that too) but seems like >> a >> > burden on an RMer. >> > >> > We should EOL a few? >> > >> > Nick is on branch-1.1 release at the moment. Perhaps this could be the >> last >> > off branch-1.1. >> > >> > 1.2 hosts our current stable release though 1.3 is out. How about we >> cut a >> > release off 1.3, call it stable, and then EOL 1.2 after another release >> or >> > so? >> > >> > What you all think? >> > >> > Thanks, >> > S >> > >> > > > > -- > Thanks, > Michael Antonov > -- Thanks, Michael Antonov
