On Sun, Jan 17, 2010 at 01:52, Juha Manninen <[email protected]> wrote: >> If you have, say, 10 patches and each requires a week to get approved >> and committed, then you will spend 70 days on the whole feature. >> Instead, you can create a patch series in maybe a week or two, and then >> it may require a couple of weeks for review as a whole. >> Thus, total development time may be cut in half or more. > > Sorry, I still don't get your idea. > > The benefit of many intermediate commits is to allow other developers to test > my changes and give feedback, and also to prevent changes from deviating too > much from the main code-base thus making merging harder later. > I thought it is a central idea of such community driven projects.
As you have already experienced, waiting for review of every commit is very inefficient. This is even move true in an open-source project, where reviewers are volunteers who might, for example, have only one day per week available for the open-source project. So even if it only takes 10 minutes to review your patch, you might still have to wait a week for it. Obviously, batching patches makes sense in such an environment. > I don't see any benefit of creating 10 intermediate patches for some mirror > server if nobody tests them. > If the results are finally reviewed as a whole, then I could as well make one > big patch in the end. I don't want to do that. One big patch is hard or impossible to review. Look how it is done on LKML or git mailing list > I believe Git has good tools for branches but it doesn't help if nobody > "pulls" from my Git branch. No, you can export patches from git in a traditional format, so pulling from you is not necessary. -- Alexander S. Klenin -- _______________________________________________ Lazarus mailing list [email protected] http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
