On Sat, Mar 28, 2015 at 7:18 PM, Arne Babenhauserheide <arne_...@web.de> wrote:
> Am Samstag, 28. März 2015, 11:32:30 schrieb Ian: > > > I agree with Bombe that it’s not nice to lose the history, but with > > > git that’s the best we can do. It’s a limitation of the tool. > > > > It's not a limitation of the tool, it's a limitation created by your > desire > > to misuse the tool. > > We have a need, we use a tool. To fulfil the need with the tool we > have to misuse the tool. Consequently the tool is too limited for our > usecase. > > There are several hacks around that - including merge commits with > explanations and only ever looking at merge commits (hiding all > non-merges) - and that these hacks are used by others shows that we > aren’t the only ones with these needs, but git offers no clean > solution. > > Sadly there also isn’t a clean way forward: Git users tend to be > pretty defensive of their tool, and as such I expect that moving to a > different tool would hurt more than it would help. So we’re stuck with > the hacks. > There is a clear way forward, we can use Github for code review the way that it was clearly intended to be used, and the way 95% of competent development teams use it. That is to review pull requests, not commits. > > It certainly works very well for my team (with a larger codebase > > than Freenet). We've never had any of the problems you guys seem to > > be so concerned about. > > Do you run a free software community with vastly differing amount of > worktime per week? > No, but I see nothing about Freenet that would make this work any less well. > > We cannot expect people to be able to review every 4 days. Yes we can, that is how code review is supposed to happen. If people can't be bothered to review code then that is unfortunate, but we can't allow development to grind to a halt because of it. The complaints I've seen are not that reviews are too frequent, but rather that when they do occur people are required to review massive changes. A code review should only require a few minutes. > This is a > reality we cannot change without having more paid > developers. Different from a company, we have to structure our > workflow in a way which keeps review from becoming a bottleneck while > ensuring that all code is reviewed. > Nothing you are advocating will change anything if we simply don't have enough people willing to do code reviews. At least with my proposal it will be a much less painful process than it appears to be today. Ian. _______________________________________________ Devl mailing list Devl@freenetproject.org https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
