On 22/03/15 21:39, Ian Clarke wrote: > On Sun, Mar 22, 2015 at 4:20 PM, Matthew Toseland <mj...@cam.ac.uk> wrote: >>> But regardless, nothing in the process I've outlined would inhibit >>> correcting problems like this. Ideally they'd be corrected at the code >>> review stage, but if they make it past that then they can be corrected >> with >>> a new branch, just like any other bugfix. >> No, they can't. >> >> Removing binaries (or worse, copyright-infringing files) requires >> rewriting the history. > Why would removing a binary require rewriting the history, Because we don't want those files in the repository at all. We don't want everyone to have to download jars which are many years out of date and aren't used anyway when they clone the repository. > and why would > anyone commit a copyright-infringing file? Can happen with installers. Can happen with people taking short-cuts, although that's less likely as Freenet is fairly specialised. Can happen as a deliberate attempt to disrupt. Can even happen by accident. > In my years of using Github I have never ever been in a situation that > necessitated rewriting history. > > The possibility that someone might do something really dumb and easily > avoidable should not dictate our code review policy. Everyone does this when they first use Git. For example, most of the members of my group project this year included multiple copies of huge third party javascript libraries, and even jars. Some of our contributors will be on that level - they won't initially know any better. This is simply because of lack of experience. If we have volunteers, many of them will have limited experience. This may also be true of paid developers, and certainly of most GSoC interns. >>>>> 2. Disruptive changes to APIs. >>>> This has also happened. Especially if the description is incomplete, >>>> there is a significant risk of refactoring breaking other code (e.g. >>>> plugins; this was part of the problem with Xor's changes), introducing >>>> new APIs that don't make sense etc. >>> Both code review and a decent continuous integration system should address >>> this. This is a good continuous integration service that is free for OSS >>> projects: https://travis-ci.org/ You can see how I use it on this other >>> OSS project of mine: http://quickml.org/ >> Not all problems can be detected by automated tools. >> >> Sometimes it is necessary to change classes that are used by plugins, >> and some of those plugins are unofficial, i.e. third party. > Yes, just like any other software project. What would make us any > different, and why would that necessitate deviating from the process I've > proposed (which is pretty-much standard practice among well-run dev teams > already)? Your point was that continuous integration can detect all problems, so advance code review is unnecessary. This is not true. CI is worth a lot, but it doesn't solve all the problems being addressed here.
And it is certainly not true that all well-run development teams accept unreviewed code! Wine doesn't, Linux doesn't, Steve's company doesn't, and I'd be pretty amazed if Google did. As for the rest, I will not be drawn into personal attacks. I care about Freenet and would like it to succeed, regardless of whether I am paid to work for it. Some of its goals may be naive in the modern world, but there is much potential here. Sadly I don't have time to volunteer at the moment; I'm only involved now because a major crisis has erupted and I had hoped I could contribute something.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Devl mailing list Devl@freenetproject.org https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
