Branch confusion

[Tom Pittenger]

The branching in our git repo is still using the svn model and it needs to be corrected. Master needs to be the current development branch and feature branch from there temporarily during the development and then get merged into master and then forgotten/deleted. They should not linger.

Helical branch needs to merge into master, or master needs to be erased and helical turns be renamed to master. That really really really needs to happen. I recommend a merge.

I'm on holiday right now without a laptop but I can slam through a merge if there's someone there to help with merge conflicts. Robert? Peter? Bill? Everyone on a big group call? This can probably happen in an hour.

-TomP

[William Premerlani]

Hi Tom,

I will not be available for several weeks. There is a lot going on in my world, including my wife is going to have knee replacement surgery. I am her "coach" to provide "support and comfort".

The rest of the team is welcome to proceed without me, I promise not to second guess any one.

Best regards,

Bill

--
You received this message because you are subscribed to the Google Groups "uavdevboard-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to uavdevboard-d...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Peter Hollands]

Tom,

Thanks for your post, insight and offer to help with a merge.

I think the best way forward would be a call between myself and Robert. You are also welcome.

Robert did a commit of Helical Turns into Master at this commit. ( This was not a git merge, but a new commit made by looking individually at the differences between MatrixPilot_wjp_helicalTurns and master (trunk).

I am grateful to Robert for a herculean effort. At the time Helical Turns was 128 commits beyond it's branch point with master. And master was 150 commits beyond the same branch point. 

I do have some issues with that approach:-

• It is not possible to track  that all the changes from helicalTurns were input into master. There is no commit record. 128 commits from the MatrixPilot_wjp_helicalTurns branch are not longer visible as commits in master. 
• The author of a given change has been lost; The commit shows as being authored by Robert. But I would like to be able to know which changes were made by Bill, myself and Robert. That helps with debugging.

At the time git was completely new to all of us. A proper git merge of helicalTurns into master would be better.

From my perspective, another issue  is that master has not been rigorously flight tested or reviewed for a long long time. The IMU test called RollPitchYaw demo, is working for the UDB4 in the helical Turns branch, but not for master at the point of merging the diffs from MatrixPilot_wjp_helicalTurns into master. The RollPitchYaw demo does not build at that commit. I have been investigating RollPitchYaw working history in master with great difficulty as it often does not work, or does not build for many commits.

My own base of trust is still in MatrixPilot_wjp_helicalTurns as I have flown that extensively and in HILSIM for over a year on the UDB5. But I have not tested it on the UDB4. So that branch also needs further testing.

I would like now to test the UDB4 and AUV3. If they work, then my own preference would be switch wjp_helicalTurns to be master, and then work with Robert to apply his commits (from the old master which would be relabelled as a branch), to the new master (a relabelling of MatrixPilot_wjp_helicalTurns).

At the end of the day, I think that Trust is the key quality for developers. Developers need to be able branch off of a trusted code base, carefully have their new feature tested and reviewed, and then merge that back into master. I can see lots of good work in master, but I personally don't trust it much at the moment. I have specific examples in mind; but we can get to them later.

At the end of the day, it's really about how we end up with a good trusted base of code from which to to branch. If others can show that master really is good to go, then lets go with that. Otherwise, my preference is to switch  MatrixPilot_wjp_helicalTurns as master. Lets see how the conversation evolves.

I would like to thank Robert for persevering with improving the organisation of the code, improving some of the MAVLink functionality, and attempting to put in place new build processes that support a wider variety of processors and platforms.

Best wishes, Pete

[Tom Pittenger]

Peter,

You are the master of political correctness.

[Tom Pittenger]

I'll just do it and submit a PR. You guys can discuss the conflicts in the comments.