Policy question for the team re: C updates

[Matt Massie <ma...@cloudera.com>]

I've been quiet since I became an Avro committer and I'd like to change that
now.  Even though I've been distracted by non-Avro work, I've been able to
find some time to create a generic-style Avro schema parser on top of the
JSON parser.  In addition, my next three-week sprint has been cleared for me
to focus almost exclusively on Avro.

What is the process that you'd like me to follow when commiting over the
next three weeks?  To this point, it's been review then commit.  Is it
possible to relax that policy to commit-then-review temporarily to help
speed along C development?

For my part, I will:
* make sure that any checkin I make doesn't not break the build
* send an email to this list explaining the changes that I've made to the C
implementation
* make sure that new code has matching unit tests

Once I have the C code is more complete (and hopefully this will happen
quickly), I'll flip back to a more incremental review then commit mode.

Ultimately, this policy decision for the team to decide and I'll abide by
whatever is decided.

Looking forward to your feedback on this.

-Matt

Re: Policy question for the team re: C updates

[Sharad Agarwal <sh...@yahoo-inc.com>]

Doug Cutting wrote:
> Matt Massie wrote:
>> What is the process that you'd like me to follow when commiting over the
>> next three weeks?  To this point, it's been review then commit.  Is it
>> possible to relax that policy to commit-then-review temporarily to help
>> speed along C development?
>
> +1 I think this is fine.
>
> In my experience, as code evolves the appropriate commit policy changes.
>
> Until an area of code is complete and usable and while it's primarily 
> developed by a single committer, CTR is a reasonable policy.  As a 
> committer, you're trusted not to break the build, etc.  C and C++ are 
> still in this stage.
>
> When code is usable, but not yet widely used, and a single committer 
> still dominates a major area within it, then that committer can post 
> patches to that area for review, wait a bit, and, barring objections, 
> commit them without a formal review.
>
> Once an area of code is widely used, and/or multiple committers have 
> been involved in that area, then first permitting others to review 
> one's changes to that area is best.
>
> Does that sound reasonable to folks?
+1

Re: Policy question for the team re: C updates

[Doug Cutting <cu...@apache.org>]

Matt Massie wrote:
> What is the process that you'd like me to follow when commiting over the
> next three weeks?  To this point, it's been review then commit.  Is it
> possible to relax that policy to commit-then-review temporarily to help
> speed along C development?

+1 I think this is fine.

In my experience, as code evolves the appropriate commit policy changes.

Until an area of code is complete and usable and while it's primarily 
developed by a single committer, CTR is a reasonable policy.  As a 
committer, you're trusted not to break the build, etc.  C and C++ are 
still in this stage.

When code is usable, but not yet widely used, and a single committer 
still dominates a major area within it, then that committer can post 
patches to that area for review, wait a bit, and, barring objections, 
commit them without a formal review.

Once an area of code is widely used, and/or multiple committers have 
been involved in that area, then first permitting others to review one's 
changes to that area is best.

Does that sound reasonable to folks?

Doug