But would a combined test + aesthetic patch fly in your mind? On Mon, Oct 31, 2011 at 4:28 PM, Benjamin Reed <br...@apache.org> wrote:
> 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. :) > > ben > > On Mon, Oct 31, 2011 at 4:08 PM, Ted Dunning <ted.dunn...@gmail.com> > 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 <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 > >> >> > >> > > > > > >
