>>>>> "GS" == Greg Stein <gstein@lyra.org> writes: GS> 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. GS> There are several issues with expanded checkin privs: GS> 1) trust: will the person make sure it is Right And Proper to do GS> the checkin? (have they reviewed the code? is a a Good Change? GS> etc) The counter here is that we don't want people that will GS> simply take stuff arriving at patches@ and checking them in. Many of the people who ultimately have checkin privileges should limit themselves to their particular domains. There are a bunch of modules that are owned by other people, e.g. Eric's netrc module, your new httplib, MAL for Unicode, etc. We'll probably develop a second group of developers who have broader privileges to make changes, but they'll know how they are. Ultimately, I think I agree with Mark's suggestion that we be a little more liberal with changes and risk backing out the occasional changes. (For some definition of "a little more" :-). GS> 2) more people reviewing changes on the -checkins mailing GS> list. Assuming that you want more than one pair of eyeballs GS> looking at patches/code, that more people with commit privs GS> increases the rate of commits, then you need more reviewers to GS> keep up (because the reviewers probably are not going to review GS> ALL checkins) You're doing a great job so far. We'll just have to get you to spend more time on it <0.8 wink>. GS> 3) increasing dependence on -checkins means that patches MUST be GS> smaller chunks. they MUST be single-purpose patches. practically GS> nobody will review a 200k patch, or patches that fix N different GS> things at once. A small, focused patch is easily reviewed. GS> For example: Trent has recently mailed a bunch of patches to GS> the patches list. This is Goodness: each one is focused and can GS> be individually reviewed. Since they are not a single, giant GS> blob, it also keeps them short and reviewable... each can have a GS> +1/-1 independent of the others. I agree in principle, but there are times when it will make more sense to commit a set of changes as one big patch. The GC patches are going to affect a bunch of files, but probably ought to be done as one big commit. Jeremy
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