Re: [HACKERS] Current sources? - Mailing list pgsql-hackers
From | The Hermit Hacker |
---|---|
Subject | Re: [HACKERS] Current sources? |
Date | |
Msg-id | Pine.BSF.3.96.980526081541.19802C-100000@hub.org Whole thread Raw |
In response to | Re: [HACKERS] Current sources? (dg@illustra.com (David Gould)) |
Responses |
Re: [HACKERS] Current sources?
|
List | pgsql-hackers |
On Mon, 25 May 1998, David Gould wrote: > Where I work we have had good success with the following: > > - every night a from scratch build and regression test is run. > > - if the build and regression is good, then a snapshot is made into a > "last known good" location. This lets someone find a good "recent" source > tree even if there is a problem that doesn't get solved for a few days. Actually, ummm...I've been considering removing the snapshot's altogether, now that anoncvs works. The only reason I was doing it before was that not everyone had access to CVSup for their particular platform...the snapshots are a terrible waste of resources, especially considering that you have to download all ~3.5Meg (and growing) .tar.gz file each time...whereas anoncvs/CVSup only updates those files requiring it... IMHO, the snapshot's are only important during the beta freeze period... > The other tool I believe to be very effective in improving code quality > is code review. My experience is that review is both more effective and > cheaper than testing in finding problems. To that end, I suggest we > create a group of volunteer reviewers, possibly with their own mailing > list. That's kinda what pgsql-patches is/was meant for...some ppl (I won't mention a name though) seems to get nervous if a patch isn't applied within a short period of time after being posted, but if we were to adopt a policy of leaving a patch unapplied for X days after posting, so that everyone gets a chance to see/comment on it... > I don't have strong preferences for the form of this, so ideas are welcome. > My initial concept supposes a group of maybe 5 to 10 people with some > experience in the code who would agree to review any patches within say two > days of submission and respond directly to the submitter. Perhaps somehow the > mailing list could be contrived to randomly pick (or allow reviewers to pick) > so that say two reviewers had a look at each patch. Also, I think it is > important to identify any reviewers in the changelog or checkin comments so > that if there is a problem and the author is unavailable, there are at least > the reviewers with knowledge of what the patch was about. This sounds reasonable to me...this is something that FreeBSD does right now...one of these days, I have to sit back and decode how they have their CVS setup. They have some things, as far as logs are concerned, that are slightly cleaner then I have currently setup :) > I would be even happier to know that next time I had a tricky patch that > some other heads would take the time to help me see what I had overlooked. You always have that...:)
pgsql-hackers by date: