On Sun 11 Feb 2018 at 19:18, Robert Scholte <[email protected]> wrote:
> 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. I am fine with that, I just am happier if everyone understands they why and how. I don’t want people thinking “stephen shoved this in and it’s here to stay because Stephen” >From my PoV it was a necessary evil for the big reset. We are well post reset now, if the majority still see value in the practice over and above the cost of that practice... let’s keep doing it ;-) > > > 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] > > -- Sent from my phone
