Thread: Daemon News article
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. -- 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, Pennsylvania19026
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, Pennsylvania19026
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, Pennsylvania19026
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, Pennsylvania19026
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, Pennsylvania19026
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