Re: master is locked for 2.2.0rc1 preparation
On Mon, Apr 18, 2016 at 09:37:23PM +0200, Georg Baum wrote: > Scott Kostyshak wrote: > > > On Thu, Apr 14, 2016 at 09:08:50PM +0200, Georg Baum wrote: > > > >> PS: Since RC is "Release candidate" we should IMHO only allow really > >> critical bug fixes between RC1 and 2.2.0 final. In particular I think we > >> should not do a RC2. > > > > I think I mostly agree, although I would take off the qualifier "really" > > for critical bugs. Also I think patches that fix regressions, even if > > they are not critical regressions, should also be allowed in. What are > > your thoughts on patches that fix non-critical regressions? (or perhaps > > a regression falls under your category of "really critical" by > > definition?) > > No, not all regressions are critical (e.g. if a workaround exists and the > regression is not in an important feature.) My rule of thumb would be to > allow patches that do only local code changes (i.e. could only break the > feature that has the regression anyway), and patches that change more > central code only if the regression is important. I think this is a good rule of thumb. Thanks, Scott signature.asc Description: PGP signature
Re: master is locked for 2.2.0rc1 preparation
On Wed, Apr 13, 2016 at 11:20 AM, Pavel Sanda wrote: > Scott Kostyshak wrote: >> B) Branch 2.2.x from master and continue "unstable" development on >> master. >> >> To me it does not feel right that the commits in-between 2.2.0rc1 and >> 2.2.0 final would not *necessarily* be in master's commit history. I > > I would prefer to see 2.2.0 final commit in master, reason being > history searches via git log etc. > git log $(git merge-base HEAD 2.2.0)..HEAD Vincent
Re: master is locked for 2.2.0rc1 preparation
Scott Kostyshak wrote: > On Thu, Apr 14, 2016 at 09:08:50PM +0200, Georg Baum wrote: > >> PS: Since RC is "Release candidate" we should IMHO only allow really >> critical bug fixes between RC1 and 2.2.0 final. In particular I think we >> should not do a RC2. > > I think I mostly agree, although I would take off the qualifier "really" > for critical bugs. Also I think patches that fix regressions, even if > they are not critical regressions, should also be allowed in. What are > your thoughts on patches that fix non-critical regressions? (or perhaps > a regression falls under your category of "really critical" by > definition?) No, not all regressions are critical (e.g. if a workaround exists and the regression is not in an important feature.) My rule of thumb would be to allow patches that do only local code changes (i.e. could only break the feature that has the regression anyway), and patches that change more central code only if the regression is important. Georg
Re: master is locked for 2.2.0rc1 preparation
On Thu, Apr 14, 2016 at 09:08:50PM +0200, Georg Baum wrote: > PS: Since RC is "Release candidate" we should IMHO only allow really > critical bug fixes between RC1 and 2.2.0 final. In particular I think we > should not do a RC2. I think I mostly agree, although I would take off the qualifier "really" for critical bugs. Also I think patches that fix regressions, even if they are not critical regressions, should also be allowed in. What are your thoughts on patches that fix non-critical regressions? (or perhaps a regression falls under your category of "really critical" by definition?) Scott signature.asc Description: PGP signature
Re: master is locked for 2.2.0rc1 preparation
Le 14/04/16 21:01, Georg Baum a écrit : Jean-Marc Lasgouttes wrote: I would like also to see a strategy for 2.2.1. Do we reserve this milestone for urgent fixes and keep 2.2.2 for more mundane backports? Or do we treat it just like any other stable release. I would recommend to reserve it for urgent fixes. I have made very good experiences with such a strategy. A x.y.0 release is always more buggy than the stable release that it replaces, so as a user I want to get the same amount of stability back as soon as possible. As a developer I expect that urgent issues will appear after a few days or weeks, since many users wait for the final release and don't participate in beta testing. Allowing only important fixes for x.y.1 helps to get back the desired stability as quickly as possible. Once it is there, we can riak a little bit more. I tend to agree with this. After two weeks, if nothing urgent showed up, we can still decide to make .1 a normal stable release. JMarc
Re: master is locked for 2.2.0rc1 preparation
Richard Heck wrote: > Then I propose to go ahead and create 2.3-staging and 2.2.1-staging now. > The former will be open for all commits, as if it were master, and will > eventually be merged to master; the latter will be treated as stable and > will be managed by me alongside 2.1.x. Why so many branches? This is too complicated for me (mentally, not technically). What is master supposed to be when we have both 2.3-staging and 2.2-staging? I would like to have one branch for 2.3 development and one branch for 2.2 development, but not more. I have a slight preference for continuing 2.2 development in master and having a 2.3-staging branch, which gets merged to master once 2.2.0 is released, but the other mentioned alternatives would also be fine with me as long as there are not more than two branches involved. Georg PS: Since RC is "Release candidate" we should IMHO only allow really critical bug fixes between RC1 and 2.2.0 final. In particular I think we should not do a RC2.
Re: master is locked for 2.2.0rc1 preparation
Jean-Marc Lasgouttes wrote: > I would like also to see a strategy for 2.2.1. Do we reserve this > milestone for urgent fixes and keep 2.2.2 for more mundane backports? Or > do we treat it just like any other stable release. I would recommend to reserve it for urgent fixes. I have made very good experiences with such a strategy. A x.y.0 release is always more buggy than the stable release that it replaces, so as a user I want to get the same amount of stability back as soon as possible. As a developer I expect that urgent issues will appear after a few days or weeks, since many users wait for the final release and don't participate in beta testing. Allowing only important fixes for x.y.1 helps to get back the desired stability as quickly as possible. Once it is there, we can riak a little bit more. Georg
Re: master is locked for 2.2.0rc1 preparation
On Wed, Apr 13, 2016 at 02:02:23PM -0400, Richard Heck wrote: > On 04/13/2016 05:20 AM, Pavel Sanda wrote: > > Scott Kostyshak wrote: > >> B) Branch 2.2.x from master and continue "unstable" development on master. > >> > >> To me it does not feel right that the commits in-between 2.2.0rc1 and > >> 2.2.0 final would not *necessarily* be in master's commit history. > > I would prefer to see 2.2.0 final commit in master, reason being > > history searches via git log etc. > > Then I propose to go ahead and create 2.3-staging and 2.2.1-staging now. > The former will be open for all commits, as if it were master, and will > eventually be merged to master; the latter will be treated as stable and > will be managed by me alongside 2.1.x. > > OK? Yes I agree. This is simple and I think it will be easy for everyone to understand. In addition to what you said, it seems that master should be merged into 2.2.1-staging immediately after the 2.2.0 release (and of course before merging 2.3-staging to master) right? Do you have macros that accomplish this? If so, please go ahead. Otherwise, I believe the following commands would accomplish what we want: git checkout master git branch 2.3.staging git branch 2.2.1-staging git push -u origin 2.2.1-staging To discuss another issue, let's take the situation of a very safe commit that fixes a bug (so we want this in the 2.2.0 release). Which of the following do you (and others) have in mind? - commit separately (e.g. with cherry-pick) to 2.3-staging, 2.2.1-staging, and master - commit only to master, because after 2.2.0 is released 2.2.1-staging will also get this commit - commit only to master, but every week we merge master back into both 2.2.1-staging and 2.3-staging Scott signature.asc Description: PGP signature
Re: master is locked for 2.2.0rc1 preparation
On Tue, Apr 12, 2016 at 10:38:02PM +0200, Vincent van Ravesteijn wrote: > Op 12 apr. 2016 22:07 schreef "Vincent van Ravesteijn" : > > > > > > Op 12 apr. 2016 21:29 schreef "Jean-Marc Lasgouttes" : > > > > > > > > Le 12/04/16 18:45, Scott Kostyshak a écrit : > > > > > >> So in the commit history of master we will not see the final 2.2.0 > > >> release (e.g. fde16219 for 2.1.0)? > > >> > > >> Have we done this before in this way? > > > > > > > > > No Vincent did not want that. But since he is away, we can be naughty. > > > > Hmm, maybe I just didn't want or was not allowed to break with history too > much. > > In my opinion, release management and branches should be done as follows: > > - all development for 2.3.0 can be done at master. > - all development for 2.2.0 can be done at a 2.2.x branch > > - do the release for 2.2.0Rc1 at a "release" branch based on the 2.2.x > branch at that moment (no need of closing/reopening branch anymore). This > means that the commits for 2.2.0rc1 that shouldn't be part of 2.3.0 do not > have to be reverted afterwards. E.g. this avoids changing version from dev > to Rc1 and back in the next commit. > > - Continue development and periodically merge the 2.2.x branch into master > (besides weird exceptions, all commits that go into 2.2.0 will be in the > master that will be the start of 2.3.0) > > - when Rc2 is to be released, merge 2.2.x into "release", change Rc1 to Rc2 > and tag. > > - Continue until 2.2.0 is released. > > Afterwards I would try to avoid cherry-picking as well as I hate the double > commit policy. However, the 2.2.x will be a dead branch eventually, so to > avoid git management we could continue like we always did. > > Conclusion: development can continue on master and still all commits that > form 2.2.0 are in the "new" master for 2.3.0, (except for the > version-change-like commits that are decoration). > > Vincent Thanks for this detailed outline, Vincent. I read it and it makes sense to me (except for a couple of small questions that I would want to clarify to make sure I understand), but I think there is a larger chance that I would mess something up. Further, since we did not start doing this for rc1, and it's not clear to me whether we have done this in the past for LyX, I'm hesitant to start doing it now. I prefer to go with something that is simple for me to implement and easy for everyone else (even those with an aversion to git) to understand. Scott signature.asc Description: PGP signature
Re: master is locked for 2.2.0rc1 preparation
On Tue, Apr 12, 2016 at 09:52:47PM +0200, Jean-Marc Lasgouttes wrote: > Le 12/04/16 21:33, Scott Kostyshak a écrit : > >Let's focus on the following options: > > > >A) Branch 2.3.staging from master and continue "unstable" development on > >2.3.staging. After 2.2.0 is released we merge 2.3.staging into > >master. > > > >B) Branch 2.2.x from master and continue "unstable" development on > >master. > > > >To me it does not feel right that the commits in-between 2.2.0rc1 and > >2.2.0 final would not *necessarily* be in master's commit history. I > >think this breaks precedent. Although we would in practice cherry-pick > >from one to the other, this would not be true for the commits that are > >specific to the 2.2.0 release. Specifically, to me it feels right that > >fde16219 is in master's commit history. > > As a data point, gcc seems to do the early branching: > http://www.phoronix.com/scan.php?page=news_item&px=gcc-5-branched-gcc-6.0 > > If you look at Qt, they would have branched at the time of feature freeze > (with comparable delays): > https://wiki.qt.io/Qt_5.7_Release Branching is one thing but merging after the release is another. I took a look at Qt (to be specific, the qtbase repository). I chose 5.5 release to look at. The 5.5.0 release (commit hash fae33bfb or tag "v5.5.0") is in the master history. Looking at the branching in gitk confirms that 5.5.0 branch was merged back into the 5.5 branch (which would be our equivalent of the master branch). As regards to LyX I don't care much whether we branch staging for branch release, but it does make sense to me that there is a merge afterwards. > >I don't see the advantage of B over A and I don't think we have done B > >before. > > This is why it is so exciting ;) > > >JMarc or anyone else would you have a strong opinion _against_ going > >with A over B? > > I do not have a strong opinion. Whatever you choose will be fine. OK. Scott signature.asc Description: PGP signature
Re: master is locked for 2.2.0rc1 preparation
Richard Heck wrote: > Then I propose to go ahead and create 2.3-staging and 2.2.1-staging now. > The former will be open for all commits, as if it were master, and will > eventually be merged to master; the latter will be treated as stable and > will be managed by me alongside 2.1.x. > > OK? Fine with me. Pavel
Re: master is locked for 2.2.0rc1 preparation
On 04/13/2016 05:20 AM, Pavel Sanda wrote: > Scott Kostyshak wrote: >> B) Branch 2.2.x from master and continue "unstable" development on master. >> >> To me it does not feel right that the commits in-between 2.2.0rc1 and 2.2.0 >> final would not *necessarily* be in master's commit history. > I would prefer to see 2.2.0 final commit in master, reason being > history searches via git log etc. Then I propose to go ahead and create 2.3-staging and 2.2.1-staging now. The former will be open for all commits, as if it were master, and will eventually be merged to master; the latter will be treated as stable and will be managed by me alongside 2.1.x. OK? Richard
Re: master is locked for 2.2.0rc1 preparation
Scott Kostyshak wrote: > B) Branch 2.2.x from master and continue "unstable" development on > master. > > To me it does not feel right that the commits in-between 2.2.0rc1 and > 2.2.0 final would not *necessarily* be in master's commit history. I I would prefer to see 2.2.0 final commit in master, reason being history searches via git log etc. Pavel
Re: master is locked for 2.2.0rc1 preparation
Op 12 apr. 2016 22:07 schreef "Vincent van Ravesteijn" : > > > Op 12 apr. 2016 21:29 schreef "Jean-Marc Lasgouttes" : > > > > > Le 12/04/16 18:45, Scott Kostyshak a écrit : > > > >> So in the commit history of master we will not see the final 2.2.0 > >> release (e.g. fde16219 for 2.1.0)? > >> > >> Have we done this before in this way? > > > > > > No Vincent did not want that. But since he is away, we can be naughty. > Hmm, maybe I just didn't want or was not allowed to break with history too much. In my opinion, release management and branches should be done as follows: - all development for 2.3.0 can be done at master. - all development for 2.2.0 can be done at a 2.2.x branch - do the release for 2.2.0Rc1 at a "release" branch based on the 2.2.x branch at that moment (no need of closing/reopening branch anymore). This means that the commits for 2.2.0rc1 that shouldn't be part of 2.3.0 do not have to be reverted afterwards. E.g. this avoids changing version from dev to Rc1 and back in the next commit. - Continue development and periodically merge the 2.2.x branch into master (besides weird exceptions, all commits that go into 2.2.0 will be in the master that will be the start of 2.3.0) - when Rc2 is to be released, merge 2.2.x into "release", change Rc1 to Rc2 and tag. - Continue until 2.2.0 is released. Afterwards I would try to avoid cherry-picking as well as I hate the double commit policy. However, the 2.2.x will be a dead branch eventually, so to avoid git management we could continue like we always did. Conclusion: development can continue on master and still all commits that form 2.2.0 are in the "new" master for 2.3.0, (except for the version-change-like commits that are decoration). Vincent
Re: master is locked for 2.2.0rc1 preparation
Le 12/04/16 22:07, Vincent van Ravesteijn a écrit : > No Vincent did not want that. But since he is away, we can be naughty. Huh, what? So you are here lurking, I knew it. Hello Vincent, I'm glad to read you! JMarc
Re: master is locked for 2.2.0rc1 preparation
Op 12 apr. 2016 21:29 schreef "Jean-Marc Lasgouttes" : > > Le 12/04/16 18:45, Scott Kostyshak a écrit : > >> So in the commit history of master we will not see the final 2.2.0 >> release (e.g. fde16219 for 2.1.0)? >> >> Have we done this before in this way? > > > No Vincent did not want that. But since he is away, we can be naughty. Huh, what? Vincent
Re: master is locked for 2.2.0rc1 preparation
Le 12/04/16 21:33, Scott Kostyshak a écrit : Let's focus on the following options: A) Branch 2.3.staging from master and continue "unstable" development on 2.3.staging. After 2.2.0 is released we merge 2.3.staging into master. B) Branch 2.2.x from master and continue "unstable" development on master. To me it does not feel right that the commits in-between 2.2.0rc1 and 2.2.0 final would not *necessarily* be in master's commit history. I think this breaks precedent. Although we would in practice cherry-pick from one to the other, this would not be true for the commits that are specific to the 2.2.0 release. Specifically, to me it feels right that fde16219 is in master's commit history. As a data point, gcc seems to do the early branching: http://www.phoronix.com/scan.php?page=news_item&px=gcc-5-branched-gcc-6.0 If you look at Qt, they would have branched at the time of feature freeze (with comparable delays): https://wiki.qt.io/Qt_5.7_Release I don't see the advantage of B over A and I don't think we have done B before. This is why it is so exciting ;) JMarc or anyone else would you have a strong opinion _against_ going with A over B? I do not have a strong opinion. Whatever you choose will be fine. JMarc
Re: master is locked for 2.2.0rc1 preparation
On 04/12/2016 03:33 PM, Scott Kostyshak wrote: On Tue, Apr 12, 2016 at 03:23:07PM -0400, Richard Heck wrote: On 04/12/2016 03:09 PM, Jean-Marc Lasgouttes wrote: Le 12/04/16 20:19, Pavel Sanda a �crit : Scott Kostyshak wrote: It is your call, anyway. It or something similar seems like a good idea to me. I just want to make sure I understand the details. One detail you should also understand is that people will pay less attention to you once master is free :) Yes I'm sure everyone will be happy and rightly so. I think it is a question of choosing between different ways of allowing development to continue. My assumption is that the effort to get 2.2.0 out now is comparable to the normal stable branch handling. But I may be wrong. This seems right to me +1 but it is Scott's call, as you said. I doubt it matters in practice whether we branch 2.2.x or introduce a staging branch. I agree that it doesn't really matter so I prefer what I think is more conventional. I'll explain more below. I have not seen that being all blocked on master made bug resolution frantic. I suspect bugs that arise for 2.2.0 now will be reported to one of the list, and we'll deal with them the way we dealt with the Flex regression. +1 Let's focus on the following options: A) Branch 2.3.staging from master and continue "unstable" development on 2.3.staging. After 2.2.0 is released we merge 2.3.staging into master. B) Branch 2.2.x from master and continue "unstable" development on master. To me it does not feel right that the commits in-between 2.2.0rc1 and 2.2.0 final would not *necessarily* be in master's commit history. I think this breaks precedent. Although we would in practice cherry-pick from one to the other, this would not be true for the commits that are specific to the 2.2.0 release. Specifically, to me it feels right that fde16219 is in master's commit history. I don't see the advantage of B over A and I don't think we have done B before. Yes, you are right: Last time, we did (A). And I don't have any objection to doing that again. Richard
Re: master is locked for 2.2.0rc1 preparation
On Tue, Apr 12, 2016 at 03:23:07PM -0400, Richard Heck wrote: > On 04/12/2016 03:09 PM, Jean-Marc Lasgouttes wrote: > >Le 12/04/16 20:19, Pavel Sanda a �crit : > >>Scott Kostyshak wrote: > It is your call, anyway. > >>> > >>>It or something similar seems like a good idea to me. I just want to > >>>make sure I understand the details. > >> > >>One detail you should also understand is that people will pay less > >>attention to you once master is free :) Yes I'm sure everyone will be happy and rightly so. I think it is a question of choosing between different ways of allowing development to continue. > > > >My assumption is that the effort to get 2.2.0 out now is comparable to the > >normal stable branch handling. But I may be wrong. > > This seems right to me +1 > but it is Scott's call, as you said. I doubt it > matters in practice whether we branch 2.2.x or introduce a staging branch. I agree that it doesn't really matter so I prefer what I think is more conventional. I'll explain more below. > >I have not seen that being all blocked on master made bug resolution > >frantic. > > I suspect bugs that arise for 2.2.0 now will be reported to one of the list, > and we'll deal with them the way we dealt with the Flex regression. +1 Let's focus on the following options: A) Branch 2.3.staging from master and continue "unstable" development on 2.3.staging. After 2.2.0 is released we merge 2.3.staging into master. B) Branch 2.2.x from master and continue "unstable" development on master. To me it does not feel right that the commits in-between 2.2.0rc1 and 2.2.0 final would not *necessarily* be in master's commit history. I think this breaks precedent. Although we would in practice cherry-pick from one to the other, this would not be true for the commits that are specific to the 2.2.0 release. Specifically, to me it feels right that fde16219 is in master's commit history. I don't see the advantage of B over A and I don't think we have done B before. JMarc or anyone else would you have a strong opinion _against_ going with A over B? Scott signature.asc Description: PGP signature
Re: master is locked for 2.2.0rc1 preparation
Le 12/04/16 18:45, Scott Kostyshak a écrit : So in the commit history of master we will not see the final 2.2.0 release (e.g. fde16219 for 2.1.0)? Have we done this before in this way? No Vincent did not want that. But since he is away, we can be naughty. It or something similar seems like a good idea to me. I just want to make sure I understand the details. I'd say it is common to do that in larger projects. But these orgs probably have QA teams to make it work. JMarc
Re: master is locked for 2.2.0rc1 preparation
On 04/12/2016 03:09 PM, Jean-Marc Lasgouttes wrote: Le 12/04/16 20:19, Pavel Sanda a �crit : Scott Kostyshak wrote: It is your call, anyway. It or something similar seems like a good idea to me. I just want to make sure I understand the details. One detail you should also understand is that people will pay less attention to you once master is free :) My assumption is that the effort to get 2.2.0 out now is comparable to the normal stable branch handling. But I may be wrong. This seems right to me, but it is Scott's call, as you said. I doubt it matters in practice whether we branch 2.2.x or introduce a staging branch. I have not seen that being all blocked on master made bug resolution frantic. I suspect bugs that arise for 2.2.0 now will be reported to one of the list, and we'll deal with them the way we dealt with the Flex regression. Richard
Re: master is locked for 2.2.0rc1 preparation
Le 12/04/16 20:19, Pavel Sanda a écrit : Scott Kostyshak wrote: It is your call, anyway. It or something similar seems like a good idea to me. I just want to make sure I understand the details. One detail you should also understand is that people will pay less attention to you once master is free :) My assumption is that the effort to get 2.2.0 out now is comparable to the normal stable branch handling. But I may be wrong. I have not seen that being all blocked on master made bug resolution frantic. JMarc
Re: master is locked for 2.2.0rc1 preparation
Scott Kostyshak wrote: > > It is your call, anyway. > > It or something similar seems like a good idea to me. I just want to > make sure I understand the details. One detail you should also understand is that people will pay less attention to you once master is free :) Pavel
Re: master is locked for 2.2.0rc1 preparation
On Tue, Apr 12, 2016 at 06:29:14PM +0200, Jean-Marc Lasgouttes wrote: > Le 12/04/16 18:20, Scott Kostyshak a écrit : > >On Tue, Apr 12, 2016 at 11:57:40AM -0400, Richard Heck wrote: > >>On 04/12/2016 04:42 AM, Jean-Marc Lasgouttes wrote: > >>>Le 12/04/2016 04:09, Richard Heck a écrit : > I propose to create a 2.3.staging branch so development can proceed. We > did this with this 2.1 cycle. Alternatively, we could create a > 2.2.0.fixes branch, from which 2.2.0 will be tagged, and you can have > full control over that. > >>> > >>>Why don't we branch 2.2.x right now and resume working on master? Do > >>>you think that the amount of work until 2.2.0 is so large that this > >>>would entail work duplication? > >> > >>I thought about that, too, but was reluctant to suggest it for fear of > >>starting a flame war. But it would be a natural thing to do at this point. > >> > >>Scott, do you have views about this? > > > >Would we then merge 2.2.x into master at the 2.2.0 release? > > No we would manage that like we manage stable right now, by backporting one > by one. It is like considering that rc1 is 2.2.-1 and that we already work > with the stable branch, instead of beginning at 2.2.0 time. So in the commit history of master we will not see the final 2.2.0 release (e.g. fde16219 for 2.1.0)? Have we done this before in this way? > It is your call, anyway. It or something similar seems like a good idea to me. I just want to make sure I understand the details. Scott signature.asc Description: PGP signature
Re: master is locked for 2.2.0rc1 preparation
Le 12/04/16 18:20, Scott Kostyshak a écrit : On Tue, Apr 12, 2016 at 11:57:40AM -0400, Richard Heck wrote: On 04/12/2016 04:42 AM, Jean-Marc Lasgouttes wrote: Le 12/04/2016 04:09, Richard Heck a écrit : I propose to create a 2.3.staging branch so development can proceed. We did this with this 2.1 cycle. Alternatively, we could create a 2.2.0.fixes branch, from which 2.2.0 will be tagged, and you can have full control over that. Why don't we branch 2.2.x right now and resume working on master? Do you think that the amount of work until 2.2.0 is so large that this would entail work duplication? I thought about that, too, but was reluctant to suggest it for fear of starting a flame war. But it would be a natural thing to do at this point. Scott, do you have views about this? Would we then merge 2.2.x into master at the 2.2.0 release? No we would manage that like we manage stable right now, by backporting one by one. It is like considering that rc1 is 2.2.-1 and that we already work with the stable branch, instead of beginning at 2.2.0 time. It is your call, anyway. JMarc
Re: master is locked for 2.2.0rc1 preparation
On Tue, Apr 12, 2016 at 11:57:40AM -0400, Richard Heck wrote: > On 04/12/2016 04:42 AM, Jean-Marc Lasgouttes wrote: > > Le 12/04/2016 04:09, Richard Heck a écrit : > >> I propose to create a 2.3.staging branch so development can proceed. We > >> did this with this 2.1 cycle. Alternatively, we could create a > >> 2.2.0.fixes branch, from which 2.2.0 will be tagged, and you can have > >> full control over that. > > > > Why don't we branch 2.2.x right now and resume working on master? Do > > you think that the amount of work until 2.2.0 is so large that this > > would entail work duplication? > > I thought about that, too, but was reluctant to suggest it for fear of > starting a flame war. But it would be a natural thing to do at this point. > > Scott, do you have views about this? Would we then merge 2.2.x into master at the 2.2.0 release? Scott signature.asc Description: PGP signature
Re: master is locked for 2.2.0rc1 preparation
On 04/12/2016 04:42 AM, Jean-Marc Lasgouttes wrote: > Le 12/04/2016 04:09, Richard Heck a écrit : >> I propose to create a 2.3.staging branch so development can proceed. We >> did this with this 2.1 cycle. Alternatively, we could create a >> 2.2.0.fixes branch, from which 2.2.0 will be tagged, and you can have >> full control over that. > > Why don't we branch 2.2.x right now and resume working on master? Do > you think that the amount of work until 2.2.0 is so large that this > would entail work duplication? I thought about that, too, but was reluctant to suggest it for fear of starting a flame war. But it would be a natural thing to do at this point. Scott, do you have views about this? > I would like also to see a strategy for 2.2.1. Do we reserve this > milestone for urgent fixes and keep 2.2.2 for more mundane backports? > Or do we treat it just like any other stable release. I guess my strategy would be to allow anything that is completley safe and maybe to hold onto patches that are a bit less so. If it looks like we don't need a "quick" release of 2.2.1, then we can include those other patches. If we do need such a release, I won't include them. Practically, I'd plan to create 2.2.1-staging, so that things that will go to 2.2.1 don't get forgotten, and also some other branch for the "held" patches. All just a way to keep track of things. Branches in git are cheap. FYI, I just created a 2.2.2 milestone for this sort of purpose. > Finally, there are a few fixes that will not be in 2.2.0 that I would > like to backport for 2.1.5. Is this possible? A typical example is > http://www.lyx.org/trac/ticket/10048 I believe we have done this before, i.e., last time, so you can go ahead. I'd also be happy to have the patch for 10063 in 2.1.5. But we should wait to do any of that until we're sure what we're doing otherwise, e.g., until 2.2.x exists. Richard
Re: master is locked for 2.2.0rc1 preparation
Le 12/04/2016 04:09, Richard Heck a écrit : I propose to create a 2.3.staging branch so development can proceed. We did this with this 2.1 cycle. Alternatively, we could create a 2.2.0.fixes branch, from which 2.2.0 will be tagged, and you can have full control over that. Why don't we branch 2.2.x right now and resume working on master? Do you think that the amount of work until 2.2.0 is so large that this would entail work duplication? Personally, part of my 2.3 work is already in a pair of branches (features/trivial and features/betterpaint) and I do not see the benefit of merging them in a temporary branch. I would like also to see a strategy for 2.2.1. Do we reserve this milestone for urgent fixes and keep 2.2.2 for more mundane backports? Or do we treat it just like any other stable release. Finally, there are a few fixes that will not be in 2.2.0 that I would like to backport for 2.1.5. Is this possible? A typical example is http://www.lyx.org/trac/ticket/10048 JMarc
Re: master is locked for 2.2.0rc1 preparation
On Mon, Apr 11, 2016 at 10:38:28PM -0400, Richard Heck wrote: > On 04/11/2016 10:19 PM, Scott Kostyshak wrote: > > On Mon, Apr 11, 2016 at 10:09:32PM -0400, Richard Heck wrote: > >> On 04/11/2016 09:49 PM, Scott Kostyshak wrote: > >>> On Mon, Apr 11, 2016 at 07:05:55PM -0400, Scott Kostyshak wrote: > Dear all, > > Please do not commit to master. I am doing some final compilation tests > and checks and will soon tag and tar 2.2.0rc1. > >>> Compilation tests and other checks went well. Commits have been pushed. > >>> Master branch is now "open". > >> I would think at this point that any commit to master needs your approval. > > Thanks, yes should I should been more clear about what "open" means now. > > > >> I propose to create a 2.3.staging branch so development can proceed. We > >> did this with this 2.1 cycle. > > I agree. > > > > Just to make sure, are the following commands correct? > > > > git branch 2.3.staging > > git push -u origin 2.3.staging > > I believe so. (I have macros that do these for me.) Ah if you have it automated then please go ahead. > Assuming you do > these from master. Good point. The full list of commands should then be git checkout master git branch 2.3.staging git push -u origin 2.3.staging Scott signature.asc Description: PGP signature
Re: master is locked for 2.2.0rc1 preparation
On 04/11/2016 10:19 PM, Scott Kostyshak wrote: > On Mon, Apr 11, 2016 at 10:09:32PM -0400, Richard Heck wrote: >> On 04/11/2016 09:49 PM, Scott Kostyshak wrote: >>> On Mon, Apr 11, 2016 at 07:05:55PM -0400, Scott Kostyshak wrote: Dear all, Please do not commit to master. I am doing some final compilation tests and checks and will soon tag and tar 2.2.0rc1. >>> Compilation tests and other checks went well. Commits have been pushed. >>> Master branch is now "open". >> I would think at this point that any commit to master needs your approval. > Thanks, yes should I should been more clear about what "open" means now. > >> I propose to create a 2.3.staging branch so development can proceed. We did >> this with this 2.1 cycle. > I agree. > > Just to make sure, are the following commands correct? > > git branch 2.3.staging > git push -u origin 2.3.staging I believe so. (I have macros that do these for me.) Assuming you do these from master. rh
Re: master is locked for 2.2.0rc1 preparation
On Mon, Apr 11, 2016 at 10:09:32PM -0400, Richard Heck wrote: > On 04/11/2016 09:49 PM, Scott Kostyshak wrote: > > On Mon, Apr 11, 2016 at 07:05:55PM -0400, Scott Kostyshak wrote: > >> Dear all, > >> > >> Please do not commit to master. I am doing some final compilation tests > >> and checks and will soon tag and tar 2.2.0rc1. > > Compilation tests and other checks went well. Commits have been pushed. > > Master branch is now "open". > > I would think at this point that any commit to master needs your approval. Thanks, yes should I should been more clear about what "open" means now. > I propose to create a 2.3.staging branch so development can proceed. We > did this with this 2.1 cycle. I agree. Just to make sure, are the following commands correct? git branch 2.3.staging git push -u origin 2.3.staging Scott signature.asc Description: PGP signature
Re: master is locked for 2.2.0rc1 preparation
On 04/11/2016 09:49 PM, Scott Kostyshak wrote: > On Mon, Apr 11, 2016 at 07:05:55PM -0400, Scott Kostyshak wrote: >> Dear all, >> >> Please do not commit to master. I am doing some final compilation tests >> and checks and will soon tag and tar 2.2.0rc1. > Compilation tests and other checks went well. Commits have been pushed. > Master branch is now "open". I would think at this point that any commit to master needs your approval. I propose to create a 2.3.staging branch so development can proceed. We did this with this 2.1 cycle. Alternatively, we could create a 2.2.0.fixes branch, from which 2.2.0 will be tagged, and you can have full control over that. Richard
Re: master is locked for 2.2.0rc1 preparation
On Mon, Apr 11, 2016 at 07:05:55PM -0400, Scott Kostyshak wrote: > Dear all, > > Please do not commit to master. I am doing some final compilation tests > and checks and will soon tag and tar 2.2.0rc1. Compilation tests and other checks went well. Commits have been pushed. Master branch is now "open". Scott signature.asc Description: PGP signature
master is locked for 2.2.0rc1 preparation
Dear all, Please do not commit to master. I am doing some final compilation tests and checks and will soon tag and tar 2.2.0rc1. Scott signature.asc Description: PGP signature
