On Fri, Jun 5, 2009 at 12:18 AM, ant elder <[email protected]> wrote: > On Thu, Jun 4, 2009 at 2:34 PM, Simon Laws<[email protected]> wrote: >> ...snip >> >>> It would be much more burdensome >>> to do multiple commits so that a tailored comment can be used for each >>> separate change. >> >> I'm not for a moment suggesting that the number of commits made should >> be dictated by the commit comments. >> > > I am ;) Well ok not "dictate" but it should be a consideration. > > Apache projects and Commit-Then-Review only work when others know and > understand whats going on, easy to grok commits helps get that group > understanding. If a change is hard to understand people don't bother > trying, so we miss out on that initial review that may catch some > bugs, but also as others start getting out of touch they are less > likely to help maintain that bit of code which results in bugs not > getting fixed promptly, mailing lists questions going unanswered, > documentation not getting updated etc. In the extreme eventually > circumstance will require that that bit of function must be updated > but as others don't really understand it instead of improving the > existing code it gets ripped out and rewritten. Thats a very > inefficient way to develop the project and also will likely make the > original coder less likely to continue contributing. > > Of course there are no hard rules on this and it depends on the change > and the preferences and style of the person making the change but IMHO > it is worth for the greater good spending a little extra time to try > and see if a big change can be broken up into several smaller easy to > understand commits. > > ...ant >
It looks like we all understand what each other issues and preferences are by now. How about we watch the behavior in the commit notifications for the next two or three weeks and see if we all make improvements... -- Luciano Resende Apache Tuscany, Apache PhotArk http://people.apache.org/~lresende http://lresende.blogspot.com/
