On Sat, Mar 04, 2017 at 09:53:08PM +0100, Guillaume Munch wrote: > But the most important to me is if 2.3 could please be branched at > feature freeze so that I don't have a backlog of patches to rebase six > months later.
This is a good discussion to have early. My poor decision regarding branching for the 2.2.0 cycle caused a lot of frustration for everyone. When we branch 2.3, this branch would be named "2.3.x", right? The slightly weird thing would be that the release manager would be in charge of the 2.3.x branch until 2.3.0 and then the stable branch maintainer would be in charge of the branch after 2.3.0. Before, it was more clear because the stable branch maintainer was always in charge of 2.y.x branches because they were branched on release. Did I get that difference correct? I suppose an alternative would be to call the branch "2.3.0" and then after 2.3.0 is released, branch 2.3.x from 2.3.0. But I think that is more complicated. From what I understand, the only reason not to branch early is to avoid work duplication (e.g. if automatic merge is not correct) on master branch and 2.3.x branch. Are there any other disadvantages to branching early? Perhaps there is a small probability that we forget a backport (because we have to backport from master to both 2.3.x anad 2.2.x). For the sake of argument, what would be the disadvantage to branching even before the feature freeze? This discussion gets more complex once we talk about our opinions regarding 2.3.1 and 2.3.2 releases. When we get close to releasing 2.3.0, there will be bug fixes that might be viewed as desirable for eventual inclusion in 2.3.x, but too risky for 2.3.0. If I remember correctly, this was a point of debate. On the one hand, I think some people thought "if a patch fixes a bug, and if it is viewed to be safe enough to consider for stable branch, it should be included in 2.3.0 if 2.3.0 has not been released." On the other hand, some (including me) thought "even if a patch fixes a bug and even if it looks safe, if the bug is not important and if the patch didn't get testing, it might be viewed as too risky to include the patch in 2.3.0 a week before release". Note that "too risky" here does not mean risky on an absolute level, it just means that the benefit-to-risk ratio is low. Depending on which argument one prefers in the above paragraph, that is what decides whether we should have e.g. 2.3.1-staging and 2.3.2-staging branches or not. Why both 2.3.1-staging and 2.3.2-staging? Because 2.3.1 might be released very quickly after 2.3.0 is released, so it should not be expected that a patch in there will get much additional testing. I think there is a view that we should keep the possibility of doing a 2.3.1 release soon after the 2.3.0 release. The alternative might be to do a 2.3.0.1 release if there is real urgency, and otherwise proceed with 2.3.1 as a normal minor release. Actually, now that I think about it, it seems that we could reduce the number of branches by one by not having 2.3.1-staging. I wonder if the following would be a clean way of proceeding: instead of 2.3.1-staging and 2.3.2-staging, we just have 2.3.x-staging, and once 2.3.0 is tagged (which is on the 2.3.x branch), 2.3.x-staging is immediately merged into 2.3.x. In the case that we need to do a quick release (e.g. a couple of weeks after 2.3.0 is released), we branch 2.3.1 (or 2.3.0.1 if preferred) from 2.3.0 (which will be behind 2.3.x at this point), and just include the critical patches. For the case where we do not need to do an emergency release, we branch 2.3.1 from 2.3.x, as normal. In case anyone is curious, here are some relevant discussions regarding branching for the 2.2.0 cycle. If I understand correctly, most of the problems and confusion would have been solved if I had branched 2.2.0 early. https://www.mail-archive.com/search?l=mid&q=20160411230555.GA9496%40OptiPlex-9020.ad.ufl.edu https://www.mail-archive.com/search?l=mid&q=57123167.2040904%40lyx.org https://www.mail-archive.com/search?l=mid&q=57129605.6090806%40lyx.org In case someone is craving wants more complexity, we can also discuss our view for the last point release of 2.2.x. For example, should all commits to the 2.3.x branch be backported to the 2.2.x branch? Or only critical patches and the lyx2lyx patch? > If you create a 2.4 milestone then I can already re-target the bugs that > I care about so as to have a better picture of 2.3. +1 We should also perhaps discuss how trac should be handled more generally, but I think it makes sense to figure out our git branching strategy first. For a disucssion on how we handled trac for the 2.2.0 cycle, see: https://www.mail-archive.com/search?l=mid&q=57129763.9060007%40lyx.org Scott
signature.asc
Description: PGP signature
