To sum up my proposal:
- master
- no review, anything can be committed / merged into it
- as long as the author did her / his best to make sure it
builds / does not break the tests)
- libreoffice-A-X
- branch created with the first beta
- only fixes go in, no features
- exception for the late features: 2 additional reviews, from
people with different affiliation than the original author
- no review until the last beta, libreoffice-A-(X-1) can be merged
into it when in the "no review" mode
- such a merge depends on TSC recommendation
- 1 review after the last beta, no merging into the branch any more
- any source of the patch goes - be it a patch sent to the mailing
list, pasted via pastebin, a cherry-pick from master, or
cherry-pick from any other branch
- the reviewer pushes to the branch [unless the reviewer and
author agree on something else ;-)] with the appropriate
Signed-off-by: tag [use the "-s" option of git commit or git
cherry-pick ;-)]
- regularly [Q: once a week? or when a tag appears?], all
libreoffice-A-* merged into master
- of course a no-op when there are no changes in a particular
release branch
- libreoffice-A-X-Y
- branch created with the "semifinal" RC (see the release plan)
- 2 additional reviews [Q: wouldn't actually just 1 additional be
enough?]
- only cherry-picking from libreoffice-3-X, the 2nd reviewer pushes
- no merges back to anything
I believe this fits most of the needs - people can work either on
master, and let others cherry-pick, or work on the release branch,
being sure that the fix will appear in master in up to one week /
when a tag appears, so that the timeframe for duplication is minimal.
How does that sound?