On Sun, Mar 22, 2015 at 6:44 AM, Arne Babenhauserheide <arne_...@web.de> wrote:
> Am Samstag, 21. März 2015, 12:45:39 schrieb Ian Clarke: > > It sounds like people are trying to use commits for code review, whereas > > they should be using Github pull requests. > > For huge changes we are using commits as a second level hierarchy: > When the diff is too big to understand on its own, then the commits > have to form an easy to follow story which allows understanding the > change step by step. > I think you've misidentified the problem and therefore the solution. The problem is that diffs would ever be too big to understand on their own, therefore the solution is that the diff should never be too big to understand on it's own. A branch/pull-request should rarely represent more than a few days of work, and thus should rarely take more than a few minutes to review. > As such they unpaid devs cannot just sit down for 6 hours and read > through a huge diff to understand it in its entirety. They need the > diff more structured. > A 6 hour code review is insane, and should never be necessary. > > - For any isolatable feature or bugfix, create a new branch just for > > that feature or bug request (perhaps put the bug id # in the name of > the > > branch). *Do not combine multiple features or bugfixes into a single > > branch.* If it can be merged independently, it should have it's own > > branch. > > We get into a problem with this, when the changes get too extensive > without being ready for merging into a release. > It should never be necessary for changes to be that extensive. In my day-job we're working on a far more complex codebase than Freenet, and yet a branch/pull-request almost *never* represents more than 4 days of work, and therefore code reviews rarely require more than 10-20 minutes. > Your scheme provides fast development of individual features, but does > not provide information spread within the group: Only one person has > seen the current version of the code. > I don't understand that, anyone that wants to is free to look at the code/pull-requests. > Longterm this needs to a situation where no one can understand the > whole code well enough to change it efficiently, which in turn leads > to pseudo-ownership over certain sub-sections of the code. > If we're producing code that isn't comprehensible without external explanation, then we're not producing good code. Well written code shouldn't require an explanation, it should be self-explanatory. This book lays out some excellent guidelines for this kind of code, every programmer should read it: http://amzn.com/0132350882 Ian. -- Ian Clarke Founder, The Freenet Project Email: i...@freenetproject.org _______________________________________________ Devl mailing list Devl@freenetproject.org https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
