Problem statement

The branch structure on g-d-p.git is getting a bit messy IMHO. The original idea was that users who want to build should select a branch for the hardware they have, and then get a reasonably working "latest" build for that hardware.

As I've said before I've always thought of GDP to be more of a continuous delivery "rolling release" than the current principles of firm betas, rc-1 etc. At the same time I understand the need for quality assured official releases – I just wonder can we find a reasonable balance here.

So currently we are looking at this:
20 hours ago chbae/raspberrypi2
3 days ago qemu-ci <- what is this exactly? experimental branch?
8 days ago tompollard/minnowivi9
2 weeks ago qemux86-64-ivi9-rc1
2 weeks ago qemux86-64-ivi9
2 weeks ago qemux86-64
3 weeks ago silk
3 weeks ago porter
3 weeks ago koelsch
4 weeks ago tompollard/raspi9
5 weeks ago qemux86-64-ivi9-beta
2 months ago minnowboard
2 months ago koelsch-aa

• is tompollard/raspi9 obsolete now due to chbae's branch?

• why does ivi9-beta and ivi9-rc1 (and even ivi-9 in the first place) require separate branches? Aren't they really just continuations of the same qemux86-64 branch?

Despite the project's focus on incremental releases Beta, RC-1 etc, I don't see any tags at all.
Basically I would recommend tagging releases more and branching less.

What do you think?

Task description

• Create a proof of concept for a single branch
• Test the PoC
• Approve the move towards a single branch: consensus
• Create a transtiion plan
• Execute the transition plan
• Analysis of the transition
• Document in the wiki the branch nomenclature and what they are for.