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