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!
