curator-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Luciano Resende <luckbr1...@gmail.com>
Subject Re: Jira Issues
Date Mon, 03 Jun 2013 23:56:09 GMT
First, I want to clarify the current scenario for Curator, we are talking
about a podling with pretty much ONE active committer.

Also, let me speak with my "Contributor"

On Mon, Jun 3, 2013 at 4:14 PM, Josh Elser <josh.elser@gmail.com> wrote:

> Speaking with my Apache Accumulo hat on:
>
> Contributors will typically attach the patch to the corresponding Jira
> issue or use review board [1]
>

+1, non committers without a CLA is required to attach a patch to JIRA to
properly give Apache the rights to use the contribution. Using review board
might be a plu as it has a more user friendly UI for reviewing the code.


>
> The patch, ignoring very trivial changes, will typically hang around for a
> while (probably due to the time until a committer has a moment to look at
> it -- I like to think this gives everyone a chance to look at the changes
> to give feedback despite us being a CTR [2] project). A committer who is
> comfortable with the changes will typically be the "champion" behind it to
> ensure it's up to snuff (matches code-style, no compiler warnings, works as
> intended, has tests, etc), apply it, and merge it to any other branches as
> necessary.
>

I think the "hang around for a while" is the biggest problem for a podling.
If I'm a new guy trying the project, find some issues and provide a fix,
and it hangs for awhile, I would either find another project that gives the
same thing, or fork the project and most likely take it to the direction I
want without caring about contributing the new changes Back.

I also think that, because of this, a lot of corporations that don't have a
lot of experience with OSS, might end up finding alternatives to handle the
slow turnaround of patches that they provide.


>
> The only time a patch has come up for review/vote for us (as far as I
> remember) is when the patch creates a controversial feature or there is
> strong disagreement on the implementation of the changes.
>

Yes, vote usually don't happen often. But I think the question was more
towards CTR versus RTC, and I'm definitely on the side of CTR. That's why
we should learn how to properly evaluate new committers, and make sure we
trust the new members of the project... once that relationship of trust is
stablished, you can review the new commits (usually more thoroughly at
the beginning)  and discuss them in case of
disagreement.... Establishing good design discussion best practices, where
medium to small features should be discussed on the dev list first, having
good test coverage, that can flag even style type of errors are also good,
particularly when these are triggered before merge (e.g. in a gerrit x
jenkins workflow)


>
> Hope that helps!
>
> [1] https://reviews.apache.org/**dashboard/<https://reviews.apache.org/dashboard/>
> [2] http://www.apache.org/**foundation/glossary.html#**CommitThenReview<http://www.apache.org/foundation/glossary.html#CommitThenReview>
>
>
> On 06/03/2013 05:08 PM, Jordan Zimmerman wrote:
>
>> ZooKeeper auto-applies patches. It's nice in that it does a first pass
>> validation automatically. It's worthwhile, IMO.
>>
>> On this subject, what should our policy be on patches? Should we vote on
>> every single one? How do other projects handle it?
>>
>> -JZ
>>
>
>


-- 
Luciano Resende
http://people.apache.org/~lresende
http://twitter.com/lresende1975
http://lresende.blogspot.com/

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message