Hi Ralph,

On Sat, Mar 3, 2012 at 12:07 AM, Ralph Goers <[email protected]> wrote:
> Actually, I meant to post a few days ago as I very much dislike the email 
> traffic in this list.  In all the projects I participate on I separate Jira 
> messages out and place them in their own folder so that I can more easily 
> follow the human generated traffic. Unfortunately, it seems that I can't 
> really do that in this list because the review messages show up such that 
> they are indistinguishable from a normal reply. In fact, once I replied 
> before I realized I needed to go into the review to make the comment. In 
> addition, I believe all of these also appear in the Jira issue and email.  
> The end result is I end up deleting a lot of emails without reading them but 
> I'm unsure if I'm missing something I should have looked at. Also, the review 
> tool seems to cause way more emails than I am used to from other projects.
>

Not sure if you are suggesting that the excessive email traffic comes
in the way of you participating in code reviews. If so, how do you
suggest we fix it?

> Just to put this in perspective, I follow over 30 mailing lists plus my 
> normal work email.  I get several hundred emails a day from the ASF so 
> anything that can be done to improve this is a big help.
>

I am sure many of us are in the same boat and have worked out
solutions that cater to individual needs. Personally, I use filters a
lot but that may or may not work for all.

Thanks,
Arvind



> Ralph
>
>
>
>
> On Mar 2, 2012, at 10:42 PM, Arvind Prabhakar wrote:
>
>> Hi Eric,
>>
>>> I just checked out Flume and the build is broken.
>>
>> Are you sure the build is broken? It seems to work fine for me at
>> revision 1296578 - which is the last revision based on my commit of
>> FLUME-978. See the build log below:
>>
>> http://pastebin.com/RNq4gFGX
>>
>>> ... The hudson job seems to
>>> be largely ignored.
>>
>> I disagree. It is on our list of things to do and there is a jira to
>> track it. See:
>> https://issues.apache.org/jira/browse/FLUME-974
>>
>>> ... I want to stress that code reviews aren't just for
>>> show; we should actually review the code.
>>
>> +1 on the idea that code reviews aren't just for show. -1 for the
>> implied accusation that we are not doing it. I don't think any one of
>> us in this community takes it lightly. As with anything, we can
>> overlook something at times - and that is why the reviews are public
>> so that others can jump in and help out. If you find something being
>> overlooked, please point it out.
>>
>>> Some classes were removed (I
>>> don't necessarily think it was a great idea, but that's another story) and
>>> tests weren't updated and now they fail to compile.
>>
>> I am not sure why you are seeing this. Look at the build log above - I
>> did a fresh checkout and everything compiles and tests correctly. Are
>> you trying to compile a previous revision? If so - note that when I
>> was committing FLUME-865, I accidentally did not checkin the newly
>> added files (revision 1291612); realized the mistake in a few minutes
>> and added the missing files (revision 1291613). I guess the only point
>> where the build can break is if you checkout the earlier of these two
>> revisions. If there are more places at various commits, please let me
>> know.
>>
>> Thanks,
>> Arvind
>>
>> On Fri, Mar 2, 2012 at 7:42 PM, Eric Sammer <[email protected]> wrote:
>>> All:
>>>
>>> I just checked out Flume and the build is broken. The hudson job seems to
>>> be largely ignored. I want to stress that code reviews aren't just for
>>> show; we should actually review the code. Some classes were removed (I
>>> don't necessarily think it was a great idea, but that's another story) and
>>> tests weren't updated and now they fail to compile. What bugs me more is
>>> that this happend about 5 commits ago which means people aren't running the
>>> tests at all nor are they validating the patches they commit.
>>>
>>> If you make a change to the code base and you only run the tests you care
>>> about, you're defeating one of the main purposes of unit testing; to ensure
>>> there are no unintended consequences of the changes.
>>>
>>> Please be vigilant. People trust their data to Flume and we shouldn't take
>>> that lightly. It's critical that with all the new committers joining the
>>> project and the pace of development that we not go feature crazy and get
>>> right back to where the 0.9.x branch was. I will continue to be a pain the
>>> ass about this. :)
>>>
>>> Thanks.
>>> --
>>> Eric Sammer
>>> twitter: esammer
>>> data: www.cloudera.com
>

Reply via email to