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 > >> > > >
