Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Threaded View
Zookeeper >> mail # dev >> cleanup and subjective patches

Copy link to this message
Re: cleanup and subjective patches
that isn't really middle ground. adding new tests for code is added
functionality, so it would be a valid patch under the criteria i
suggested. changing an int to an enum is not adding functionality. the
later may be subjectively better and the former adds functionality.
the nice thing is that you can determine that objectively. :)


On Mon, Oct 31, 2011 at 4:08 PM, Ted Dunning <[EMAIL PROTECTED]> wrote:
> How about a middle ground being that aesthetic changes will only be
> considered if they bring significant new testing that helps mitigate the
> stability risk?
> On Mon, Oct 31, 2011 at 3:51 PM, Patrick Hunt <[EMAIL PROTECTED]> wrote:
>> EOD this is not a tool problem, it's a resource issue. We have limited
>> committer time available for reviews. IMO Thomas's changes have been
>> pretty mechanical so far, they are easy to review/commit. They do
>> result in some patch churn but I've been surprised it's been so little
>> so far and the code is improving as a result. However we've just
>> scratched the surface (the easy stuff), I do have some concerns as we
>> make more significant structural changes. Personally I think we need
>> to focus on beefing up testing prior to making more significant
>> changes.
>> Ben - We won't get new committers if we limit contributions. We'll
>> just dig a deeper hole for ourselves. Granted if we only review/accept
>> patches of a particular type (or from a particular person) we'll be in
>> a similar situation.
>> Thomas - Ben has highlighted some good points, if we don't discuss
>> these rationally, out in the open, we won't be able to make progress.
>> There are other patches from other contributors that we need to
>> balance the available resources against.
>> http://communityovercode.com/over/
>> Personally: my biggest concern is that we keep releasing solid high
>> quality code that works in production. I'm seeing patches go in that
>> break existing functionality and no one notices. To me the thing we
>> should be focusing on is adding testing. Refactoring and such to
>> improve/increase testing imo is a net positive.
>> Patrick
>> On Mon, Oct 31, 2011 at 2:39 PM, Ted Dunning <[EMAIL PROTECTED]>
>> wrote:
>> > Jumping over to Ben's side of the discussion,
>> >
>> > Git helps with this, but does not eliminate the problem.  At some point
>> > the
>> > changes become difficult to understand relative to the new code and may
>> > even collide in ways that are difficult to merge.
>> >
>> > It is true, however, that patches can be kept live using tools like git.
>> >  That is how I kept the multi stuff alive, but there was at least one
>> > tricky merge to be done.
>> >
>> > On Mon, Oct 31, 2011 at 2:35 PM, Thomas Koch <[EMAIL PROTECTED]> wrote:
>> >
>> >> Thanks to Ted for replying. I will save the mail I started in the
>> >> drafts
>> >> folder until I've calmed down again.
>> >>
>> >> Benjamin Reed:
>> >> > deprioritizing them doesn't help because the patches themselves bit
>> >> > rot. shortly they will not apply and then they will be worthless. the
>> >> > poor contributor would then be left with the task of maintaining a
>> >> > patch that would never commit.
>> >> You should really give GIT a try. I've kept a pipeline of half a
>> >> douzend
>> >> patches filled and current over the last two months while drinking my
>> >> morning
>> >> coffee.
>> >> Likewise have I updated my development branch of over a douzend commits
>> >> every
>> >> morning against the new ZK trunk.
>> >>
>> >> Regards,
>> >>
>> >> Thomas Koch, http://www.koch.ro
>> >>
>> >