On 22/03/15 19:07, Ian wrote: > On Sat, Mar 21, 2015 at 7:42 PM, Matthew Toseland <matt...@toselandcs.co.uk> > wrote: > > >> 0. Stupid stuff. E.g. committing jars to repositories. > Committing jars to repositories is kind of careless, don't people have > sensible .gitignore files? Can a .gitignore be committed to the repo? > > 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. Rewriting the history is *BAD*. It makes it impossible for a third party to follow what is going on. It makes life extremely difficult/messy for our own developers, breaking their unfinished work when they pull from master. >>>> 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. >> I agree that review capacity is potentially a bottleneck. There are >> different ways to solve this: >> - Have paid staff who review and merge stuff. > 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. I repeat my earlier point: If we allow everyone to commit without review, we will spend a lot of our time (and commit history) undoing stuff. This is one of the reasons behind the rise of distributed version control in the first place. Git, and Github, are specifically designed to support pull requests. The implication is that the person merging the changes is not the same as the person posting them, and that they should be signed-off, i.e. reviewed. >> - Don't accept pull requests if nobody can review them right now. > This will absolutely cause a severe bottleneck, causing development to > grind to a halt, and probably destroying morale in the process. Who wants > to work their ass of on some code only for it to sit in a branch > indefinitely? >> - Allow the reviewers to make reasonable demands for clear code. A pull >> request is a negotiation between the contributor and the maintainer. > Of course, reviewers can point out unclean code, and a conscientious > developer will want to commit good code so they'll fix it. If a coder is > ignoring reasonable code review feedback then that might be grounds for > removing commit access. We are not using SVN. We are not using CVS. NOBODY uses Git and then gives everyone push access. It just doesn't make sense. The correct, standard workflow used by just about everyone is to fork and post a pull request, which may or may not be merged. I will reply to your points about big changes separately.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Devl mailing list Devl@freenetproject.org https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
