Daemon News article

At 11:07 AM -0700 5/29/99, Bruce Momjian wrote:

I have gotten the OK from Daemon News to publish the article I posted a
few days ago. The original is our web site. Any comments before I
release it. I will wait a few days.

The quote from Jolly Chen does not seem consistent with Eric Raymond's
analysis in "The Cathedral and the Bazzar." Since the latter is pretty
well known, I would expect it to provoke disagreement unless it can be
justified or explained a bit more.

Signature failed Preliminary Design Review.
Feasibility of a new signature is currently being evaluated.
h.b.hotz@jpl.nasa.gov, or hbhotz@oxy.edu

On Sat, 29 May 1999, Henry B. Hotz wrote:

The quote from Jolly Chen does not seem consistent with Eric Raymond's
analysis in "The Cathedral and the Bazzar." Since the latter is pretty
well known, I would expect it to provoke disagreement unless it can be
justified or explained a bit more.

Assuming that one finds the analysis in TCAB to be correct, which a lot
of people don't. There's no need to launch into an anti-ESR war because
of these, but there's certainly no reason not to voice honest opinions
just because Eric disagrees with them.

--
Todd Graham Lewis Postmaster, MindSpring Enterprises
tlewis@mindspring.net (800) 719-4664, x22804

"A pint of sweat will save a gallon of blood." -- George S. Patton

At 11:07 AM -0700 5/29/99, Bruce Momjian wrote:

I have gotten the OK from Daemon News to publish the article I posted a
few days ago. The original is our web site. Any comments before I
release it. I will wait a few days.

The quote from Jolly Chen does not seem consistent with Eric Raymond's
analysis in "The Cathedral and the Bazzar." Since the latter is pretty
well known, I would expect it to provoke disagreement unless it can be
justified or explained a bit more.

I totally agree that it is inconsistent, but I have never felt Rayond
was 100% correct. While I don't believe developers should have a
'holier than thow' attitude (and I don't think we have), most patches
from people who did not take the time to figure out how things worked
were a disaster if applied. If we don't have reliability, we have
nothing in the db world, and a bazzar is not reliable.

Perhaps I should add some text in there to address this. Good point.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  maillist@candle.pha.pa.us            |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

At 3:15 PM -0700 5/29/99, Todd Graham Lewis wrote:

On Sat, 29 May 1999, Henry B. Hotz wrote:

The quote from Jolly Chen does not seem consistent with Eric Raymond's
analysis in "The Cathedral and the Bazzar." Since the latter is pretty
well known, I would expect it to provoke disagreement unless it can be
justified or explained a bit more.

Assuming that one finds the analysis in TCAB to be correct, which a lot
of people don't. There's no need to launch into an anti-ESR war because
of these, but there's certainly no reason not to voice honest opinions
just because Eric disagrees with them.

My focus was wrong, sorry. The real point is that there is an obvious
inconsistancy with a current hot viewpoint. If one wants to publish a
conflicting viewpoint it should probably be explained more or else the
resulting discussion will generate more heat than light.

I suspect that if you got Jolly and Eric in a real conversation about what
they really meant then they might not disagree as much as it first
appeared. Eric himself points out that the need to make something that
actually works requires some kind of coordination and filtering of patches.
If the coordination is too rigid then either the project languishes (*BSD
vice Linux) or a new project splits off (egcs vice gcc). (Does MySQL vice
mSQL constitute another example in this space?) If the coordination is
too free then the reliability of the product suffers. (Can't think of a
good example, but then the good examples are probably projects that have
died and been forgotten.)

Signature failed Preliminary Design Review.
Feasibility of a new signature is currently being evaluated.
h.b.hotz@jpl.nasa.gov, or hbhotz@oxy.edu

On Sat, 29 May 1999, Henry B. Hotz wrote:

The quote from Jolly Chen does not seem consistent with Eric Raymond's
analysis in "The Cathedral and the Bazzar." Since the latter is pretty
well known, I would expect it to provoke disagreement unless it can be
justified or explained a bit more.

Assuming that one finds the analysis in TCAB to be correct, which a lot
of people don't. There's no need to launch into an anti-ESR war because
of these, but there's certainly no reason not to voice honest opinions
just because Eric disagrees with them.

Let me address this again.

People have asked why we don't follow the Linux model, where development
is continuous(no beta) and stable releases are odd (or even?). The
reason is that this type of development model has a tendency to follow a
"it works, it's broken, it works, it's broken again" style, that spends
lots of time trying to clean up improper fixes that were applied in
previous releases. This reminds me of gcc development, where the
compilers were riddled with bugs and certain releases where ok, but
later ones were not, and there was no way to tell them apart. You got
to wondering whether they were going forward or backward in their
development.

Now, I know we have done that sometimes, but that certainly would happen
much more without a development/beta/final release cycle, where
experienced developers review all patches that get applied. The
development finally becomes stable, but there is a tremendous amount of
wasted energy getting there.

Now, I will also say that I have seen software companies that do this
too, and they burden their customers with "beta of the week" while it is
labeled as an official release. They cram features into that software
much faster that way, but is it worth the grief the customer endures?

Now, if people want to disagree with me on this, let's discuss it.

Also, I need advise on whether I should bring up such a hot issue in the
paper, or just leave the statement by Jolly as a "given" for our group.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  maillist@candle.pha.pa.us            |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

At 3:28 PM -0700 5/29/99, Bruce Momjian wrote:

The quote from Jolly Chen does not seem consistent with Eric Raymond's

I totally agree that it is inconsistent, but I have never felt Rayond
was 100% correct. While I don't believe developers should have a
'holier than thow' attitude (and I don't think we have), most patches
from people who did not take the time to figure out how things worked
were a disaster if applied. If we don't have reliability, we have
nothing in the db world, and a bazzar is not reliable.

I don't think Eric is claiming that a bazzar is ideal, just that there are
enormous advantages to going ahead and releasing code which isn't quite
done. Once you have a good framework set up an awful lot of people can
help with the detail debugging. A really good test case is 90% of a
complete fix.

25 years ago I observed that part of the IBM monopoly was based on how
*bad* their stuff was. It was so difficult to get things working that by
the time you did you were afraid to do it over with another company. And
you were kind of proud of the fact that you *did* get it working in the end
after all.

In my opinion, Microsoft has done a similarly masterful job of making
things just good enough that the competition wasn't obviously better, while
making their stuff bad enough to maximize the required custommer
commitment. This paragraph is intended as a side observation, not flame
bait.

Perhaps the point to make in the paper is just that we have chosen a
particular development cycle/philosophy. It doesn't happen to coincide
precisely with Eric Raymond's recommendations, but we're not exactly a
cathedral either.

---------------

Responding to what Bruce wrote while I was writing this note: I don't
entirely agree with the comment about gcc. Before egcs they generally had
a "stable" release, e.g. 2.5.8, or 2.6.3, or 2.7.2.x that was being widely
used while there was also a "current" release like 2.6.1, or 2.7.1, or
2.8.0. In their case there was also an internal-only alpha/beta version
which we never saw. Coming from this background I found it difficult to
evaluate the stability of various Postgres versions because there was no
parallel maintenance of a "stable patched" version independent of the
"development" version.

I still feel it is unfair to expect all developers to "switch gears"
between just fixing bugs and just developing new stuff in order to conform
to a single release cycle. Some people are better at one than the other.
Likewise I think our users would welcome a choice between a known stable
version and a more featureful current version. I'm not sure our beta
versions quite provide this kind of distinction.

But at this point I am commenting randomly on actual deveopment policy
rather than on the article.

Signature failed Preliminary Design Review.
Feasibility of a new signature is currently being evaluated.
h.b.hotz@jpl.nasa.gov, or hbhotz@oxy.edu

Responding to what Bruce wrote while I was writing this note: I don't
entirely agree with the comment about gcc. Before egcs they generally had
a "stable" release, e.g. 2.5.8, or 2.6.3, or 2.7.2.x that was being widely
used while there was also a "current" release like 2.6.1, or 2.7.1, or
2.8.0. In their case there was also an internal-only alpha/beta version
which we never saw. Coming from this background I found it difficult to
evaluate the stability of various Postgres versions because there was no
parallel maintenance of a "stable patched" version independent of the
"development" version.

I am thinking of the earlier 2.x releases, and even the 1.x releases.
It was very fluid for quite a while.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  maillist@candle.pha.pa.us            |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

OK, I can't resist adding my two cents worth ...

"Henry B. Hotz" <hotz@jpl.nasa.gov> writes:

I don't think Eric is claiming that a bazzar is ideal, just that there are
enormous advantages to going ahead and releasing code which isn't quite
done. Once you have a good framework set up an awful lot of people can
help with the detail debugging.

Actually, I think we are closer to the bazaar model than you say; we
just don't use some of the terminology that has been popularized by
Linux etc. For example, we *do* release current code --- anyone can
pull the current sources from the CVS server, or grab a nightly
snapshot. And we do accept patches from anyone, subject to review by
one or more of the "inner circle"; I doubt that Linus allows world
write access on his kernel sources either ;-).

There is a difference in emphasis, which I think comes from the agreed
need for *all* Postgres releases to be as stable as we can make them.
But that's really not much more than a difference in naming conventions.
Postgres major releases (6.4, 6.5, etc) seem to me to correspond to
the start of a "stable version" series in the Linux scheme, whereas the
current sources are always the equivalent of the "unstable version".
We don't normally make very many releases in a "stable version" series,
but that's partially due to having a strong emphasis on getting it right
before the major release. (Also, I believe that one focus of the new
commercial-support effort will be on improving maintenance of past
releases, ie, back-patching more bugs.)

I'll close by saying that both Jolly and Eric are right, and that what
is really working well for Postgres is a core group of people with a
heavy commitment (Marc, Bruce, Vadim, Thomas) and a much larger group
of people with smaller amounts of time to contribute. I don't think
that's so much different from what other open-source projects are doing.

regards, tom lane

I'll close by saying that both Jolly and Eric are right, and that what
is really working well for Postgres is a core group of people with a
heavy commitment (Marc, Bruce, Vadim, Thomas) and a much larger group
of people with smaller amounts of time to contribute. I don't think
that's so much different from what other open-source projects are doing.

Tom, I totally agree with you, though I will say you are moving into
that first group pretty rapidly. :-)

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  maillist@candle.pha.pa.us            |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

On Sun, 30 May 1999, Tom Lane wrote:

OK, I can't resist adding my two cents worth ...

"Henry B. Hotz" <hotz@jpl.nasa.gov> writes:

I don't think Eric is claiming that a bazzar is ideal, just that there are
enormous advantages to going ahead and releasing code which isn't quite
done. Once you have a good framework set up an awful lot of people can
help with the detail debugging.

Actually, I think we are closer to the bazaar model than you say; we
just don't use some of the terminology that has been popularized by
Linux etc. For example, we *do* release current code --- anyone can
pull the current sources from the CVS server, or grab a nightly
snapshot. And we do accept patches from anyone, subject to review by
one or more of the "inner circle"; I doubt that Linus allows world
write access on his kernel sources either ;-).

There is a difference in emphasis, which I think comes from the agreed
need for *all* Postgres releases to be as stable as we can make them.
But that's really not much more than a difference in naming conventions.
Postgres major releases (6.4, 6.5, etc) seem to me to correspond to
the start of a "stable version" series in the Linux scheme, whereas the
current sources are always the equivalent of the "unstable version".
We don't normally make very many releases in a "stable version" series,
but that's partially due to having a strong emphasis on getting it right
before the major release. (Also, I believe that one focus of the new
commercial-support effort will be on improving maintenance of past
releases, ie, back-patching more bugs.)

Which pretty much sums up the *BSD model of development vs the Linux one
:)

Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org