On Sat, 3 Jun 2000, Jeremy Hylton wrote: >... > Sorry for the excuses. I think better tools would help a lot, but > we'll have to get more people checkin privileges regardless. There are several issues with expanded checkin privs: 1) trust: will the person make sure it is Right And Proper to do the checkin? (have they reviewed the code? is a a Good Change? etc) The counter here is that we don't want people that will simply take stuff arriving at patches@ and checking them in. 2) more people reviewing changes on the -checkins mailing list. Assuming that you want more than one pair of eyeballs looking at patches/code, that more people with commit privs increases the rate of commits, then you need more reviewers to keep up (because the reviewers probably are not going to review ALL checkins) 3) increasing dependence on -checkins means that patches MUST be smaller chunks. they MUST be single-purpose patches. practically nobody will review a 200k patch, or patches that fix N different things at once. A small, focused patch is easily reviewed. For example: Trent has recently mailed a bunch of patches to the patches list. This is Goodness: each one is focused and can be individually reviewed. Since they are not a single, giant blob, it also keeps them short and reviewable... each can have a +1/-1 independent of the others. Cheers, -g -- Greg Stein, http://www.lyra.org/
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4