Sounds good to me. --Chris Nauroth
On 3/29/16, 11:06 AM, "Sean Busbey" <[email protected]> wrote: >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! >
