Comprehensive reviews & when to do them?

[Rick Harding]

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 <
katherine.cox-buday at canonical.com> 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
> Juju-dev at lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju-dev/attachments/20151214/b520f754/attachment.html>