Re: Project scheduling issues (was Re: Per tuple overhead,

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 ...