Dear Saros developers,
In yesterday's team meeting we lively discussed an aspect of our release
process. The question at hand: "How do we want to deal with open reviews in a
release branch?"
** Why now? **
This question did not present itself in this clear form yet because the
previously used Reviewboard was not aware of branches. The newly imposed strong
connection between reviews and commits (through Git and Gerrit) brought this
issue up.
** What were our thoughts? **
The first natural thought on this topic might be something like: "There are no
open reviews in a release branch after the release, because otherwise the
release would not have been complete!"
But as it happens to be the current situation, we *do* have an open review on a
freshly closed release branch (it was the dry release of May).
** What we agreed on: **
- During the release week the two Test Managers (TM+ATM) include a
prioritization of the discovered bugs on a two-level scale in their testing
report. The two values would be: "No release without a fix!" (critical) and "A
release would be fine, even without a fix" (non-critical).
- This rating is then open for discussion; the Release Manager has the final
word on this subject.
- The release is postponed until the critical bugs are fixed; if there are
only non-critical ones or no bugs at all the release will be rolled out on
Friday evening (as described in our Release Process [1]).
- After the roll-out any open reviews from the release branch will be moved
to the master branch by their authors. (Sebastian: As you already relocated
your open review to the master branch, I'd ask you to describe the required
steps for our Wiki.)
- After the release week the release branch can be technically closed to new
patches, thus avoiding unnecessary pitfalls. This can be performed in Gerrit
and will be done by the Release Manager (Holger: Please prepare a step-by-step
instruction for our Wiki). Until now there was no need for a re-release
("hotfix") in the history of Saros, but in order to keep that door open I
propose a 72-hour period of time in which the branch remains open. (Which would
be consistent with the current Re-Release Procedure [2]).
Please feel free to comment on this proposal. If we reach a steady state by
Friday -- and I do no doubt that we will -- I'll adapt our Release Process
documentation where necessary.
Best regards,
Franz
Links:
[1] https://www.inf.fu-berlin.de/w/SE/DPPReleaseProcess
[2]
https://www.inf.fu-berlin.de/w/SE/DPPReleaseProcess#How_to_make_a_re_release
PS: Personally I'm not fully satisfied with this approach. The reason is as
follows: We already *have* a bug tracker with a rather fine-grained, nine-level
prioritization of bug entries. In order to open up the development of Saros to
the world, the Test Managers should use this tool and mark the "release
threatening bugs" with priority 9. But since our tracker is currently somewhat
decayed, I'm afraid that this might go unheard. What do you think?
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Dpp-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/dpp-devel
