I made branch-1.4 a few weeks ago only. I did it because I had hoped to RC quite quickly. Then the reality of compatibility breaks and failing unit tests hit, as well as insufficient time for me to make progress on my must-have for the release, which is a backport to RSGroups. I will get to all of this as soon as I can given work commitments. Maybe we can have a RC of 1.4.0 by the end of next month.
I don't disagree with you, though. If there were more active scrutiny of branch-1 then we would have found the compat breaks and addressed the test problems near when they happened and my work as RM of 1.4 will have been lessened considerably. I would like to see us move to a model where we have three main code lines: master: 3.x branch-2: 2.x branch-1: 1.x and we migrate our RM model away from RMs curating patch branches to a model where there are three people actively monitoring the state of the above three branches, and, when considering releasing, we prefer to cut new minors from these three branches (modulo master) over patch release work. There will be times when patch releases are necessary. I don't think a dedicated RM for a patch branch is necessary, though. If there is a critical bug fix for branch-1, the "RM" for branch-1 can spin patch releases of all 1.x code lines we have decided to keep alive and run votes on all of them. This is incremental additional effort after getting set up to make releases in the first place. There are two huge benefits: 1. We split precious RM resources in fewer ways. 2. We have fewer code lines receiving the majority of commits, so committers do less work. On Tue, Aug 8, 2017 at 10:19 AM, Zach York <zyork.contribut...@gmail.com> wrote: > One problem that I see is that it appears we are cutting branches extremely > early. > I'm going to pick on branch-1.4 for a moment. This branch has existed (as > far as I can remember) for at least 3-6 months, yet we still have not had a > 1.4.0 release. I understand that releases can take time, but this adds pain > for developers (If I'm developing a new feature or bug fix, do I put it on > branch-1 and it will be pulled into branch-1.4 or do I need to explicitly > put it on branch-1.4?). It seems that this branch should be the same as > branch-1 at the moment. > > So my suggestion would be use branch-1 (or branch-2 now) for all > development and only create a branch when the first release of a line is > imminent. > > Perhaps I am missing some context, but that is my 2 cents. > > Thanks, > Zach > > On Tue, Aug 8, 2017 at 9:14 AM, Mike Drob <md...@apache.org> wrote: > > > > The discussion also brought up the notion of an LTS release line. I'm > not > > > sure how this jives with the more fequent minors, but would require > some > > > branch that's so stable that an RM can effectively spin releases blind. > > > > Seems to me like this branch would necessarily need to be very > > backport-light? Only the top of the highest priority issues would be > > backportable to it, no? > > > > On Tue, Aug 8, 2017 at 11:09 AM, Nick Dimiduk <ndimi...@apache.org> > wrote: > > > > > Last time we DISCUSSed EOL of 1.1 was back in November. At that time, a > > > litany of issues were raised re: 1.2. Have those concerns been > addressed? > > > It seems to me that making this one the last release is too abrupt to > > folks > > > tracking Apache. Would be better to give some notice. > > > > > > Had a nice hallway conversation a couple months back (at PhoenixCon, as > > it > > > happens; they feel the pain as well) about our branch situation. I'll > let > > > the others chime in with more details, but the gist as I recall is that > > we > > > should be doing more frequent minor releases with fewer patch releases. > > > This pushes stabilization efforts closer to master and also imposes > more > > > strict stability requirements on big new features before they can be > > merged > > > off the feature branch. > > > > > > The discussion also brought up the notion of an LTS release line. I'm > not > > > sure how this jives with the more fequent minors, but would require > some > > > branch that's so stable that an RM can effectively spin releases blind. > > > > > > On Tue, Aug 8, 2017 at 12:14 AM 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 > > > > > > > > > > -- Best regards, Andrew Words like orphans lost among the crosstalk, meaning torn from truth's decrepit hands - A23, Crosstalk
