I think this is a bit of a difference in code review and feature QA. Doing something big at the end misses all the knowledge share, keeps things in silos for longer lengths of time without understanding the history, etc. Hey, maybe someone sees an obvious way to suggest doing those shortcuts/stubs!
However, I do think there's room for folks to really help validate the feature branch is a complete solid feature before getting rubber stamped. I'd think of this more as a feature review/QA though vs expecting anyone to do a big code review of an entire feature branch to master. On Mon, Dec 14, 2015 at 10:39 AM Katherine Cox-Buday < [email protected]> wrote: > Hey All, > > I think we have a mis-alignment in how we currently do reviews and > feature branches. > > We've switched over to feature-branches which is great and has allowed > Moonstone to land "good enough" code into our feature branch to support > a bi-weekly demo and solicit feedback. At the same time, I feel like > we're wasting people's time asking for a +1 on code that is not intended > to be landed into master. Often this code will take shortcuts or stub > out some code, and as the lead I'll make a judgment call to circle-back > later. Reviewers don't necessarily know this. > > Conversely, when we go to land the feature branch into master, these PRs > are generally rubber-stamped. > > I feel like maybe we have this backwards? > > - > Katherine > > -- > Juju-dev mailing list > [email protected] > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/juju-dev >
-- Juju-dev mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
