Sid, I agree some design and requirement discussion needs to happen. My generally feeling with design doc is that it's good for stating high level goal but hard to track and discuss details (which I think pull request is a better place for this).
For instance, I have been trying to simplify class hierarchy for Timestamp, Date and Time, which I first stated in the Requirement 3 in the initial design doc: https://docs.google.com/document/d/1ysZ76zritBDwkeQz3C6-vhQwD32jEXd1kUF4T936G1U but we haven't been able to get too much discussion on that without having an PR. I feel sometimes the better place to discuss this is actually in PR itself. How do you feel about discuss requirement/design in the PR itself for such changes? I am certainly happy to change PR description to have more requirement/design. Li On Wed, Nov 29, 2017 at 2:30 PM, Siddharth Teotia <siddha...@dremio.com> wrote: > Folks, > > Over the last couple of weeks, we have had several changes (both merged and > in the pipeline) as follow-up work after ARROW-1463 was merged. > > I feel that refactoring suggestions are being proposed on-the-fly while the > developer is already in progress with the code changes and it's too late to > have an opinion on the changes. > > It doesn't give the reviewer enough time to understand the rationale behind > the proposed changes and assess its impact downstream and most importantly > have a clear idea of what all changes are being implemented so that > downstream consumers can understand what to expect when they rebase next > time. > > Two sets of such follow up changes are already merged to master. For the > ones in pipeline, I request people to send out a doc or spec highlighting > what we are proposing to change and rationale similar to how requirements > and design spec for ARROW-1463 was sent out prior to making any code > changes. > > Thanks, > Siddharth >
