Unfreeze changes post 4.0.0

[jongough]

Hi,
Do you know when the freeze period for OCPN 4.0.0 will end? I have some changes I would like to get into the next beta stream and some of them are getting a bit old now.

Thanks
Jon

[nohal]

Jon...
It is over, just post pull requests into the master, the stuff qualifying also as a 4.0.x fix should go to v4.0.x branch in separate pull request or at least should be very clearly marked as a candidate for backporting.
I just don't want to start merging the stuff until Dave returns from his well deserved vacation... But be warned, as I know him, the vacation will finish with a huge patch applied to the master as usually

Pavel

[bdbcat]

Jon/Pavel...

I'm listening, but not too closely.

No problem with merging pull requests into master whenever you think they are ready. I understand the staleness factor...

We should discuss what gets backported as it comes up. I don't see anything that is a critical backport candidate yet....


Are you expecting a big patch from me when when I re-surface? Well, maybe.....

Thanks
Dave

[nohal]

OK, I will start with it, hopefully tomorrow, to move the baseline and minimize the number of merging conflicts, which are already there now - don't expect any lightning speed though...

Pavel

[jongough]

Great! Some of the changes I have put in are being tested/used from windows installs I put up on drop box, but they are getting a bit stale now as well. I am happy to update the windows installs, but I would prefer that the changes get incorporated, particularly the 'boundary' one as it is big, before too many changes happen.

Thanks
Jon

[jongough]

Pavel,
I have just noticed a possible clash with your FS#1670 change and my FS#1533 boundary change. The boundary change makes quite a few modifications to chcanv.cpp and it may be easier to fit your change into my version of this file (there may be some extra areas you have to make the changes to) than me try and rework and add to your change. Is that possible?

Thanks
Jon

[nohal]

Jon...
Yes, I will first merge the pull requests and then forward-port my fixes from the v4.0.x branch - otherwise I would probably get crazy...

Thanks for cross-checking

Pavel

[nohal]

Jon...
Please, in the future try to use git rebase on upstream/master instead of git merge with upstream/master in the feature branches - it will avoid the "Merge remote-tracking branch 'upstream/master'" commits.
And I was wondering why pulling your repo took so loooong and stepped on https://github.com/jongough/OpenCPN/...aster/test-win - not exactly a good idea

Pavel

[jongough]

I will try the rebase thing with git. But being new to git I am using what seems to be working and slowly working out what is best. I am using SmartGit on my PC and one of the updates seems to have turned on a facility I was not expecting and some stuff got uploaded that was not supposed to go. I ment to delete test-win directory last night, but I was only in the office for about 15 mins and did the OpenGL fix then forgot to clean up git. Sorry about that. I will try and remember tonight. I don't know how to delete stuff using the web interface or I could do it now.

So in future I should do a
git pull upstream
then a
git rebase upstream/master
rather than a merge? Do I do this to my working branch or to the master branch?

[nohal]

Originally Posted by jongough

So in future I should do a
git pull upstream
then a
git rebase upstream/master
rather than a merge? Do I do this to my working branch or to the master branch?

To any branch you want to bring up to date, typically to your working branch, at least before creating a pull request (but of course you usually do it every now and then when you see changes in the upstream master).

Pavel