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 >
