Re: Project scheduling issues (was Re: Per tuple overhead, - Mailing list pgsql-hackers
From | Marc G. Fournier |
---|---|
Subject | Re: Project scheduling issues (was Re: Per tuple overhead, |
Date | |
Msg-id | 20020611061020.D11817-100000@mail1.hub.org Whole thread Raw |
In response to | Re: Project scheduling issues (was Re: Per tuple overhead, (Tom Lane <tgl@sss.pgh.pa.us>) |
List | pgsql-hackers |
On Mon, 10 Jun 2002, Tom Lane wrote: > There is a downside to changing away from that approach. Bruce > mentioned it but didn't really give it the prominence I think it > deserves: beta mode encourages developers to work on testing, debugging, > and oh yes documenting. Without that forced "non development" time, > some folks will just never get around to the mop-up stages of their > projects; they'll be off in new-feature-land all the time. I won't name > names, but there are more than a couple around here ;-) Well, in alot of ways we have control over this ... we have a very limited number of committers ... start requiring that any patches that come through, instead of "just being applied and worry about documentation later", require the documentation to be included at the same time ... would definitely save alot of headaches down the road chasing down that documentation ... I think we've actually done thta a few times in the past, where we've held up a patch waiting for the documentation, but its never been a real requirement, but I don't think its an unreasonable one ... > I think our develop mode/beta mode pattern has done a great deal to > contribute to the stability of our releases. If we go over to the same > approach that everyone else uses, you can bet your last dollar that our > releases will be no better than everyone else's. How many people here > run dot-zero releases of the Linux kernel, or gcc? Anyone find them > trustworthy? Anyone really eager to have to maintain old releases for > several years, because no sane DBA will touch the latest release? Again, we do have alot of control over this ... the only ppl that we *really* have to worry about "not mopping up" their code are those with committers access ... everyone else has to go through us, which means that we can always "stale" a patch from a developer due to requirements for bug fixes ... ... but, quite honestly, have we ever truly had a problem with this even during development period? How many *large* OSS projects out there have? My experience(s) with FreeBSD, for an example, are that most developers take pride in their code ... if someone reports a bug, and its recreateable, its generally fixed quite quickly ... its only the "hard to recreate" bugs that take a long time to fix ... wasn't that just the case with us with the sequences bug? You yourself, if I recall, admitted that its always been there, but it obviously wasn't the easiest to re-create/trigger, else we would have had more ppl yelling about it ... once someone was able to narrow down the problem and how to re-create it consistently, it was fixed ... We've never really run "a tight ship" as far as code has gone ... Bruce has been known to helter-skelter apply patches, even a couple that I recall so obviously shouldn't have been that we beat him for it, but that has never prevented us (or even slowed us down) from having *solid* releases ... everyone that I've meet so far working on this project, IMHO, have been *passionate* about what they do ... and, in some way or another, *rely* on it being rock-solid ...
pgsql-hackers by date: