if there's going to be more than one experimental downstream, I'd prefer we start voting on release artifacts (say, a tarball of our source checkout) so that we can get a release cadence going. I'd be fine with doing this while e.g. Hadoop's adoption is being driven in a branch.
For getting Hadoop working this weekend, I think a working commit-without-review branch is reasonable. I'd like there to be a yetus jira that tracks the branch's lifecycle, with the branch named for it. On Thu, Oct 15, 2015 at 10:18 PM, Stack <[email protected]> wrote: > Use hbase as your guinea pig? > St.Ack > > On Thu, Oct 15, 2015 at 6:30 PM, Allen Wittenauer <[email protected]> wrote: > >> >> On Oct 15, 2015, at 6:28 PM, Sean Busbey <[email protected]> wrote: >> >> > I presume the concern for just e.g. tagging master is turn around time >> > for reviewing changes needed? >> >> >> Yeah. I'd much rather move forward if the fixes are simple than have to >> back out (unless absolutely necessary, of course).
