We do have a donut-release branch internally, which only differs from
the donut branch by its version number.
As for your plan, this sounds like it should be workable, but it seems
to me that you're not benefiting from the distributed aspect of git -
pushing snaphots out and cherry-picking changes back in is in fact
very similar to what would happen with a non-distributed system.
Personally (and that's really just a personal opinion, YMMV), I prefer
processes where work across servers limits itself to fetching from one
server and pushing to another via a fast-forward, and where anything
more complex happens within the confines of a single server.
E.g. imports from the Android Open-Source Project are done in two
steps: mirroring the external tree on Google's internal server, and
merging the mirror into our work tree (we use merges instead of
cherry-picks as we actually take all changes in, and as it better
preserves the history and allows fast-forwards more often than not).
Similarly, pushes from Google's work tree to the Android Open-Source
Project are first staged on our internal server, and then pushed to
kernel.org (so that any specific work that needs to happen during
staging can happen behind closed doors).
JBQ