This is inspired by recent discussion of Reef factory branch strategy.

Currently we allow two different strategies for getting test image for factory process -
 use the one from factory branch, or
 use the one from release branch (same as FSI).

There are always pros and cons for each decision.

[factory branch]
pros:
 Can be really stabilized. can add any hacks or workarounds.

cons:
 For new projects sharing same factory branch, they usually find it pretty hard to figure out what's missing on factory branch because most work are done on ToT & release branch.
 Sometimes developers will keep saying "why are you using a very old image?"
 The recommended way to support new projects is using "fast-forward kernel". However sometimes the dependency in userland may cause new builds fail to work -- and this did happened before.

[release branch]
pros:
 Same as FSI. Believed to be stable without problem.
 Less cherry-pick work.
 If we always use release branch in future, factory branch can stop building test images and would be blazing fast (only need to build toolkit) just like firmware branch.

cons:
 No way to add dirty hacks or workarounds since release images are restricted.
 Builder will stop building old release branches and hard to get new builds.


I personally believe having a "working factory branch" is still the better model, but just like what we've seen on Reef, that can be pretty difficult to maintain, especially that partners will keep saying "these issues must be caused by missing CLs between factory branch and release branch".
And according to Bernie, (1) Infra team prefers to prevent cutting new branches if possible, that each chipset family should share same factory branch (2) There's no way to fast-forward all repos.

Any thoughts for how to deal with that?

Or should we just split factory branches to factory-$BOARD-toolkit-XXX and factory-$BOARD-test-XXX ? (or factory-$BOARD-XXX and test-$BOARD-XXX)