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, and why would anyone commit a copyright-infringing file? 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. >>>> 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)? I'm not sure I understand your point. > > That seems very unlikely to happen, we barely have budget for actual > > developers, let alone dedicated QA people. And really, who'd want that > job > > anyway? > > > > Even setting aside budget and finding suitable people, coders should have > > primary responsibility for ensuring that their code is good. It's > > unhealthy to have a situation where coders think that ensuring their code > > is clean and robust is someone else's problem. > That is precisely how every mature project works. Just because neither > your business ventures nor your involvement in open source are mature > doesn't mean there aren't projects out there - both open source (Linux, > Wine) and businesses (Steve's employer, presumably Google, etc) - which > care about code quality. > Wow. Why would you say something so stupid in a forum where future employers could potentially see it? You forget that I've seen your code, it wouldn't come anywhere close to passing a code review by even the least experienced developer on my company's engineering team, so please don't presume to lecture me about code quality, or how mature software projects work. I really hope they teach you how to be less of an asshole during your computer science course, or you'll have a very hard time getting or keeping a job, either commercial or in academia. Your previous paragraph would be a firing offense at most companies. Professional engineering teams simply don't tolerate asshole behavior any more. 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
