To me the most important reason for seconding is to have at least some
kind of consensus per issue before merging to master.
I don't want to get in the same situation again and if that means
seconding, then I'm fine with that even if it slows down the process.
Quality is much more important.
thanks,
Robert
On Sat, 10 Feb 2018 19:09:33 +0100, Stephen Connolly
<[email protected]> wrote:
When we had the “big reset” I asked for seconding before merging as the
priority was to get a functioning release out.
IMHO outside of burndown towards a release, a successful CI build of the
branch, providing the branch is fast-forward mergable (not that we
actually
do a fast forward merge - merge policy being a separate topic, just that
all commits are on top of master without rebasing) should be all that is
required to merge (the release manager, ie whoever steps up to do a
release, may revert any problematic merges when time comes to actually
release)
Once a release manager has stepped up and declared the start of a
burn-down... in that case seconding should apply.
Wdyt?
(Ps I haven’t declared burn down for core *yet*, but I will in the next
week or two)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
