Do we already have consensus on what the merge looks like? Personally, I'm fine treating it like a normal patch. That is, +1 required from any contributor (N.B. "contributor" rather than "committer"). I see no reason to require more work from folks than we'd require if Allen wasn't trying to make it easier to see the work in pieces.
On Tue, Mar 29, 2016 at 1:04 PM, Sean Busbey <[email protected]> wrote: > a branch for commit-then-review-before-merge sounds good to me. > > On Tue, Mar 29, 2016 at 11:25 AM, Allen Wittenauer <[email protected]> wrote: >> >> Hey gang. >> >> YETUS-156’s purpose is to give Yetus the ability to act as >> daily/nightly/whateverly build driver for CI systems. This way, Yetus’ >> reporting could be part of the CI process rather than just digging through >> mountains of logs looking for errors. The vast majority of changes are >> purely cosmetic [yay!] but there are quite a few of them to clean up. >> >> >> Given: >> >> * that we don’t have a branch policy (at least, that I’m >> aware of….) >> * YETUS-156 is working well enough in my tests for people to >> start playing with it >> * YETUS-156 is probably reaching the point where it is ‘too >> big to review’ (~40k at last rebase) >> >> I think it might be useful to setup a branch for YETUS-156, >> preferably with a CTRTM (commit then review then merge)-type policy. This >> would give others a chance to play, break it up into a reviewable state, >> give me a chance to fix bugs quickly while still providing protection to >> master if the 0.3.0 train decides to leave before this is ready. >> >> In the mean time, I’ve changed YETUS-156 to be an umbrella, if just >> for my own sanity. >> >> Any thoughts? >> >> Thanks!
