Temprary issue gripes(was:Re: cvs problem)

From: Lamar Owen <lamar(dot)owen(at)wgcr(dot)org>
To: John Summerfield <pgtest(at)os2(dot)ami(dot)com(dot)au>
Cc: John Summerfield <pgtest(at)os2(dot)ami(dot)com(dot)au>, Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Temprary issue gripes(was:Re: cvs problem)
Date: 2001-10-08 13:49:46
Message-ID: 200110081349.JAA13382@www.wgcr.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Friday 05 October 2001 07:48 pm, John Summerfield wrote:
> On Fri, 5 Oct 2001, Lamar Owen wrote:
> I made it clear I was getting frustrated. Read in that context, I think it
> was pretty mild;-)

But it was done in an uninformed way. Had you read the previous two-three
weeks of the archives, your questions mostly would have been answered. And I
think that's the thing that irritated me -- at least try to understand what
the culture of the project is before criticizing it. I am reminded of Tom
Lane's first post....(it's in the archives....)

> Especially considering the point I saw a project in disarray (and I don't
> think anyone's disputed that).

Temporary disarray only. But this project is a truly open project, where no
one person has final say. People will occassionally get upset and disagree
-- this is normal life in a true open source project. People here tend to
disagree in a much more mild way that with some other projects, though.

> I'm ingnorant. I don't see why CVSROOT would need to be changed. I thought
> Unix filesystems were flexible enough to allow CVS to see things as they
> really aren't, perhaps using symlinks.

Why introduce additional complexity into an already complex system? The next
time things need to be shuffled (in a few weeks, months, or years), having to
remember to un-dangle a symlink might cause another issue. The new CVSROOT
is shorter and simpler, and it is useless to mung in an unnecessary symlink.
PeterE had just posted how to get around it without a new checkout -- a
cursory half-hour browse through the last month's archives would have found
it.

> > Correction: Marc Fournier controls the entire disk layout, as it's his
> > server. It was his decision to change the layout.

> Is Marc part of the team?

Reference the developers listing on developer.postgresql.org.

> Instead of telling me how to go on with my affairs, there ensured a
> discussion about the documentation being wrong, about the devlopers corner
> shouldn't really be there and so on.

Because your report was a symptom of a larger problem -- that of the
automatically generated pages not generating properly. Fix the cause, not
the symptom.

> Now, I've always thought that the first thing to do when someone has a
> problem is to give them the solution to their problem if the solution is
> easily had.

The first thing that has to be done is to find the real problem. You may not
even know what the real problem is -- if CVS hadn't broken, something else
would have pointed out that the docs we're being autogenerated any more. And
a temporary fix for a symptom is not nearly as useful as is a cure for the
real problem. Once the problem has been found and fixed, the symptom will go
away.

> To be sure if the Postgresql itself is broken, that may take longer, but
> that wasn't the case. The procedures (from my point of view) or
> documentation (from yours) was wrong, and what I needed most was the
> knowledge of what actually works.

> And referring me to the incorrect documentation didn't serve to persuade me
> the project's running well.

If the documentation build procedure was broken (which it was), telling you
the correct incantation would have only fixed your individual problem.
Attempting to fix the doc build process, with your help in saying 'Yes, that
fixed it' or 'no that didn't' helps the whole userbase, not just you.

PostgreSQL's online documentation is derived from the very same SGML source
documentation that ships with the tarball -- to prevent duplication of
effort. As the autogen system has been in place for awhile, when a change in
the SGML source didn't propagate to the web pages, that problem had to be
found before it could be fixed. In the process a few feathers got ruffled,
but things are ok as of now, AFAIK.

Again, it's been a kindof rocky two-three weeks --but this is momentary. But
you have to have context to see its momentary nature -- and only by reading
the archives can you obtain proper context.

As to why things had to change, well, Marc is the person to answer that.
But, really, he is under no obligation to answer that, as he's providing his
servers and bandwidth to this project. They're his, and he can run them as
he sees fit. If he wants to justify his actions, then that's ok. If he
doesn't want to justify those actions, well, I can't really have a problem
with that either -- I'm not the one forking out the money for his bandwidth.
I'm too busy being thankful that he is taking the time and pouring out the
effort to keep things running. And things typically have run very well over
the last five-plus years that Marc has hosted the project. After all,` he
basically rescued the whole thing. But that's context.....

And speaking of context, even in my extra-busy state of the last three
months, I was able to follow what was going on, and prepared for it here.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Serge Sozonoff 2001-10-08 13:53:43 Patch for OSX 10.1 and Postgresql 7.3.1
Previous Message Jean-Michel POURE 2001-10-08 13:42:34 Re: [HACKERS] What about CREATE OR REPLACE FUNCTION?