For the sake of argument here, let's assume we choose a unit of review-and-test that contains one-or-more significant patches (worth releasing) plus zero-or-more trivial patches.
Julian Foad wrote: > These two things [double voting, automatable process] seem to > be the two main burdens we could reduce. To spell out the relationship between those two: if there's quickly and magically a release-candidate tarball produced for each proposed backport, then what we review and test for backport is assured to be exactly what we would be reviewing and testing for a release. Following on your tagging idea: Perhaps the tarball creation would be triggered by each successive backport proposal (cumulatively) on the branch; those that fail test/review are ignored; and when we make the tag, the tagging triggers the later parts of the release process (essentially, making the tarballs public). - Julian
