On Tue, Nov 1, 2011 at 7:21 AM, Fournier, Camille F. <camille.fourn...@gs.com> wrote: > Personally, I have no problems with refactorings, but we seem to be spending > much of our time dealing with them right now when we really need to get 3.4 > out the door. It's been months that this release has been going on and > splitting the committer attention between 3.4 and refactoring changes feels > counterproductive to the needs of the community at this moment.
I second that. There are a few 3.4 blocker issues pending that need review -- not to mention Mahadev hasn't gotten much feedback on the release candidate. There are 35 patch available issues at this moment, most of which are _not_ refactoring issues. Plenty of patches for committers to review if they are uninterested in aesthetic issues. Patrick > > -----Original Message----- > From: Ted Dunning [mailto:ted.dunn...@gmail.com] > Sent: Monday, October 31, 2011 7:08 PM > To: dev@zookeeper.apache.org > Cc: tho...@koch.ro; Benjamin Reed > Subject: Re: cleanup and subjective patches > > 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 <ph...@apache.org> 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 <ted.dunn...@gmail.com> >> 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 <tho...@koch.ro> 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 >> >> >> > >> >
