What is the reasoning behind that? I think it makes sense for it to be
two commits, but there wasn't any more discussion once we figured out
how to solve the problem that motivated the new method. I could have
added another JIRA, but what would have been the value of it?
rb
On 05/12/2015 03:22 PM, Mike Drob wrote:
Ryan, I think that absolutely should have been two issues.
On Tue, May 12, 2015 at 5:20 PM, Ryan Blue <[email protected]> wrote:
On 05/11/2015 02:53 PM, Sean Busbey wrote:
On Mon, May 11, 2015 at 4:26 PM, Ryan Blue <[email protected]> wrote:
I disagree. I think we all agree there's value to having separate
commits,
but logical breakdown of a task often goes into detail that, when
mirrored
into JIRA without reason, is just busy work.
What value does an issue provide if there is no discussion and it is just
a box to tick when working on another issue?
rb
I don't think we all agree there's value to having separate commits. The
time when I think it's valuable is precisely when the sub-tasks are
actually something that might benefit from additional discussion or
reviews
on jira.
I guess that explains the difference in opinion then. I think that there
are cases where separating work across commits can make maintenance easier.
For example, I just had a case in Parquet where I extended an existing API
and added tests for a new method, then moved other parts of the codebase to
the new version to fix a performance regression. I think that logical
division makes sense, but I don't see value in separating them into two
issues.
rb
--
Ryan Blue
Software Engineer
Cloudera, Inc.
--
Ryan Blue
Software Engineer
Cloudera, Inc.
