For the record, this is what I did as release manager:
1. take a bunch of tickets with positive_review, make a private Sage
release with them, test them on the buildbot.
2a. if there are buildbot failures and it's clear which ticket caused
them: set the ticket to needs_work and GOTO 1.
2b. if there are buildbot failures and it's NOT clear which ticket
caused them: take a different set of tickets with positive_review and
GOTO 1.
2c. as long as the set of chosen tickets is too small to merit a new
beta/rc or it is missing a ticket which certainly should be included,
GOTO 1.
3. Close all chosen tickets on Trac.
4. Make a new private release with the chosen closed tickets.
5. If any of the merged tickets do not correspond to the tested tickets
(easy to check: in steps 1 and 4, store the hash of the tickets; now
just compare those), there are several actions I could take:
* The change is minor (for example, a typo in the documentation): assume
that buildbot tests still pass and just accept the change.
* The change is major and we want a new release soon: re-open the ticket
on Trac and GOTO 4 (postponing the ticket to the next beta).
* The change is major but we really want the ticket in this release:
GOTO 1 to test it again (keeping the tickets closed).
6. Make the release from step 4 public as new Sage release.
For me, this worked well enough in practice. I know the release
management scripts would have to be adjusted to store the hashes, but
it's not really difficult either.
Jeroen.
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.
