This is the mail archive of the
mailing list for the Java project.
Re: Up-to-date News on GCJ
-----BEGIN PGP SIGNED MESSAGE-----
[CC-ing Gerald Pfeifer.]
Tom Tromey wrote:
>>> I guess if we had an RSS feed for gcj news and another for classpath
>>> news, interested folks could subscribe to both, or we could subscribe
>>> the gcj news page to the classpath feed.
> Ranjit> Good idea. I like whatever it is that you use for your own
> Ranjit> blog - perhaps we can install something like that for propagating
> Ranjit> GCJ/GCC/Classpath news?
> I'll ask around. I'm using blosxom... it is ok but perhaps there's
> something a bit more user-friendly for gcc.gnu.org.
Note that the current GCC wiki software lets you have an
RSS feed for the page history of a particular wiki page.
So we can perhaps create a "GCJ News" page and interested
people can just subscribe to the RSS feed of its history.
> Ranjit> In a similar vein, can you please look at the main content of
> Ranjit> the page and suggest changes? For example, now that GNU Classpath
> Ranjit> is completely merged into GCJ, the status pages for the libgcj-
> Ranjit> Classpath merge and the GUI branch merge are not needed. I also
> Ranjit> do not know if the comments about GNU Crypto and Jessie are still
> Ranjit> valid. Lastly, rhug itself proclaims that it does not need to
> Ranjit> exist any more now that the BC-ABI is fully functional.
> Yes, all of those things should be changed.
I'll try to come up with some appropriate text "soon".
> * The gcj main page is nice web design from 1998... look at mono's web
> pages to get an idea of what it should look like in 2006. In
> particular, we could have more useful information in less space, so
> that visitors can get a decent overview without having to scroll.
We should do it in tandem with the rest of the GCC web pages.
(I personally consider GCC/GCJ pages to be fairly decent-looking,
especially if you consider the web pages of other FSF projects.
But I'm known to have a sometimes-weird sense of aesthetics
compared to "normal" people.)
We can perhaps use one of the designs posted on OSWD:
or raise an RFH on the GCC/GCJ mailing lists for volunteers
with the necessary CSS and web-design skills.
> * Any content on the gcj page which is not fairly static over time
> has rotted -- the FAQ, the "done with gcj" page (Gerald's nemesis
> :-), the status page, etc. These should be deleted and moved to
> the wiki, where we at least have some chance of getting folks to
> update them.
I have imported the FAQ, the "Done with GCJ" and the status pages
into the GCC Wiki:
Perhaps we can remove (or prominently display a deprecation notice
on) the corresponding web pages. I've not tried to clean up the FAQ
and the status or update them for the latest state of affairsyet,
but a quick glance shows that *quite a bit* needs to be updated. :-(
(Newbie question: How do I change the left side bar on the GCJ
pages? Where is the text for this thing picked up from?)
We should be a bit careful while moving relatively-important
pages to the wiki. The problems I personally have with wikis
in general are:
1. As Bryce pointed out, wiki pages are generally aesthetically
less appealing compared to "normal" web pages.
2. There is ample scope for vandalism or other forms of abuse.
(The GCC wiki itself was the target of some online casino
promoting bot abusing the AddComment plug-in.) GCC has high-
ranked pages for search engines, so there's every chance that
the wiki will be abused to promote the web sites of unscrupulous
3. Without peer review (unless people are subscribed to the
RSS feeds of the relevant pages and actively scrutinise changes),
there is a greater chance of well-intentioned but still wrong
information making it to crucial pages.
4. The licence for such documentation is not clear to me. If
the FSF wants to incorporate anything in the wiki into the
manuals for GCC/GCJ, what can it do besides tracking down the
author(s) of the relevant bits and getting an agreement for
5. There is no standardised wiki markup, so it's a pain to
migrate from one wiki software to another.
All that aside however, wikis *significantly* lower the barrier
for people to help us out. It also helps that wiki markup is
usually simpler than HTML and the editing/previewing/submitting
cycle is much better with a wiki. So we might not have much of
a choice except to move to the wiki if we want to keep the
information up-to-date and relevant.
> * The "main" text should say what our goals are and a bit about what
> gcj can do. Mentioning things like missing AWT support is both
> anti-PR and a waste of time and effort -- these days this stuff is
> changing all the time.
> * It should be simpler to navigate to useful things... how to get
> involved, reading the documentation, etc.
> * We should have javadoc for libgcj online, by release.
Can we get by by linking to the GNU Classpath API documentation
(That seems to be for the latest Classpath release, which might
not be imported immediately into GCJ.)
> * We should have a separate "developer's home" that lists things
> useful to gcj developers... typical bugzilla queries, links to the
> auto-builder, whatever else is useful.
The wiki seems to be a more appropriate place for such things.
Thanks a lot for your suggestions.
Ranjit Mathew Email: rmathew AT gmail DOT com
Bangalore, INDIA. Web: http://rmathew.com/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v220.127.116.11 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----