Re: Temprary issue gripes(was:Re: cvs problem) - Mailing list pgsql-hackers

On Mon, 8 Oct 2001, Lamar Owen wrote:


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


I've spend years helping people (for free, just like you people here), first with OS/2 and then with Linux,
specificallyRed Hat.
 

I understand and accept that many questions are asked over and over.

Where possible I have referred people to existing documentation, often
with a shortened explanation.

Often I illustrate answers with clippings from a terminal window.


If I can't test an answer, I give a clue that it's untested.
>
> > 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

Someone said it had been the old way for five years. It caused me no
inconveniece - I simply copied and pasted the lengthy name from the web page.

I don't see for whom the long name would be a problem; certainly if
it has been that way for five years, it couldn't have been a serious
problem.




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

The symlink could be used the other way - leave CVSROOT alone so it works
the way it 'always has,' create the symlink as a convenience for whoever
wants 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.

yes or no? I don't have web access at present. He contributes to discussions,
so I guess in at least some sense he is.

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

No reason at all to make people wait for thich incantation. Someone had the
correct information. Probably a minute to find it and incorproate it
in a response.


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

Fix my problem so I can go on looking for more. Then fix the real problem.

I went to the CVS version because I had problems with the most recent
release. I try not to report fixed problems.

However, I do need reasonable support from the developers, and I was only
seeking a a modest amount of support.


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

Anyone can verify that the page I mentioned contains correct (or incorrect)
information. Doesn't need a say-so from me.



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

I don't ordinarily have web access. Archives are inconvenient. And, in
my experience, somewhat hard to use. It can be hard to find a specific topic
- too many synomyms - and often they're too voluminous, and unless you have
a high-bandwidth service (I don't) slow.