[Openmcl-devel] OSX install difficulties
dankna at accela.net
Fri Oct 1 03:23:47 UTC 2004
> The main web page is an out-of-data, static FAQ. The "news" page
> should probably be the first page (and should be updated more often!),
> and should probably link to a more dynamic, user-extensible FAQ.
> (There's a package called "FAQ-O-Matic" that I'm thinking of, there
> may be other things that're easier to use or maintain.)
Yeah, you know, I noticed yesterday that release 0.14.2 isn't even
on the news page, heh. And I agree that news belongs on the front page.
Actually, I think it would be nice to come up with a layout that
the news and the static FAQ on a single front page. After all, there
much information in the static FAQ, so it doesn't take up much space now
and could be condensed further.
Of course, there's the question of where the news updates will come
from. I suppose the appropriate content would be a description of what
the active developers are working on at the moment. It doesn't need to
get into a chatty, blog-style description of the specific issues being
encountered; that might be nice, but it would probably be an
unreasonable drain on developers' time.
Stuff like the crt1.o issue is ideal for presenting in a separate
troubleshooting section. It comes up rarely; if it affects you, you
it; and it's easy to search on. I'm not sure - and won't be until I
see it - how well that'll work for problems which manifest in less
The dynamic FAQ will work well if developers are in the habit of
reading it and looking for unanswered questions. I've seen some where
the same questions just sit there, which makes those projects look bad.
So, I think we should do it, with that proviso. A partial substitute
be to simply make a strong effort to update the FAQ frequently in
response to questions on the dev list.
> Another approach (which may or may not be helpful to Dan): the PHP
> website (the website for the PHP server-side scripting language)
Hmm, yes, I see. Sort of like a webboard at the bottom of the page.
You can see an example at:
The ability to annotate is very nice; it does raise the same concern
that things posted in that manner might not get prompt responses
because it would be hard to know about them. If, say, there were
a mailing list that all new annotations got mirrored to, that would
solve that problem. That way, if somebody posts that the docs for
the function don't match the implementation, we can be sure we'll
hear about it and have a chance to fix the implementation if it's
> Sorry to ramble; I don't like the thought that someone who might do
> great things with OpenMCL would be discouraged from doing so because
> the web site didn't warn them against using Stuffit and they couldn't
> get things installed and working. I also think that it'd be even
Absolutely; that's what this is all about.
> harder to present the circular-boostrapping issues and other
> domain-specific stuff without keeping that and the metainformation
> ("these are Unix text files, lines are terminated with LF and that's
> sometimes very important.") separate.
-- Dan Knapp
More information about the Openmcl-devel