Re: GCJ ------ file type not supported by system

[Guillermo Rodriguez <guille dot rodriguez at gmail dot com>]

El 04/09/2014 14:14, AndÃÃ escribiÃ:
> On 3 September 2014 17:12, Guillermo Rodriguez Garcia
> <guille.rodriguez@gmail.com> wrote:
>>
>> Hi Mario,
>>
>> 2014-09-01 12:47 GMT+02:00 Mario Torre <neugens@redhat.com>:
>> [...]
>>>> Yes I am sure about this, but that is not my point. What I am saying
>>>> is that it would be very good for the project to be maintained by a
>>>> team who really wants to move things forward.
>>>>
>>>
>>> I understand what you mean, but the current maintainer has always
>>> integrated patches and done releases, I think the problem is not the
>>> lack of one maintainer willing to move forward, is lack of manpower to
>>> do it.
>>
>> Well,part of the job of the maintainer for an OSS project, perhaps the
>> most important one, is to attract and motivate other developers. This
>> is how the 'lack of manpower' problem is solved.
>>
>> Just as an example: 0.99 is now over 2 years old, yet the official
>> Classpath site still lists 0.98 (2009) as "current". 0.99 is not even
>> listed in the downloads page. If the first thing a developer sees is
>> that the latest release is more than 5 years old, that does not
>> exactly help. I already mentioned this in this list, by the way
>> (https://www.mail-archive.com/classpath@gnu.org/msg15456.html).
> 
> 
> I'm aware of this and I see your point. The issue is that the web pages
> rely on a tool called wml that seems to be no longer maintained and
> I've simply not had chance to look at fixing it up myself or doing away
> with it.
> 
> If you want to do so, feel free. I can point you in the right direction.

I was going to send a set of patches against the CVS repository that
Mark Wielaard posted (http://web.cvs.savannah.gnu.org/viewvc/classpath/?root=classpath)

I don't really see the point of "fixing" an obsolete tool that is no
longer maintained. Can't we update the HTML pages directly (short term
solution) and then later decide on what to do with WML ?

If patching the HTML files is OK (that's what I understood from Mark's
e-mail) I will do that.

>>
>> Also I am not the first one to raise these concerns. Pekka Enberg
>> wrote an excellent post about "the future of GNU Classpath" in Dec
>> 2010, and the situation has not changed a lot since then. I cannot
>> find the original post anymore (the blog was hosted at posterous
>> spaces, which is no longer available), but the thread in the ML
>> remains (http://www.spinics.net/lists/gnu-classpath/msg03027.html).
>> But you already know this of course, since you took part in that
>> conversation.
>>
>>>
>>> As I said, anyone can step in, if patches start to flow (including bug
>>> fixes) I'm sure they'll be integrated correctly and quickly.
>>>
>>> If someone wants to take the project, the best thing to do is to start
>>> contributing patches. After all, how can the maintainer know if someone
>>> is seriously willing to take his role if there lack of a serious and
>>> recent contribution flow?
>>>
>>
>> Of course if someone wanted to take on the project, then that would be
>> the process. I completely agree with you.
>>
> 
> There have been three changes made this year already:
> 
> http://git.savannah.gnu.org/cgit/classpath.git/log/
> 
> They were included pretty much as soon as they were posted.
> 
> I also have some stuff I'm working on, but it has to take second place
> to maintaining three (soon four) major versions of OpenJDK/IcedTea.
> 
>> At the end what I am saying is that:
>>
>> 1. Development of GNU Classpath seems to be stalled now (quoting from
>> an earlier post from Andrew Haley: "I have to tell you that Classpath
>> is not being actively developed, so your problem is unlikely to be
>> fixed.")
> 
> Sorry, but that's simply nonsense,

Sorry, but it wasn't me who said "Classpath is not being actively developed".

> as can be seen by what I've said above.
> It's slow, because there aren't many people with the time and interest, but
> it's certainly not 'stalled'.

That's a very subtle difference, if any.

> 
>>
>> 2. This is due to the lack of manpower, which in turn is probably due
>> to the lack of interested developers, but also to the fact that most
>> of the development effort of the current team is going to OpenJDK
>> instead.
>>
>> 3. Given the above, perhaps the current maintainers should consider
>> switching priorities and start actively looking for a "competent
>> successor" (as in lesson #5 of ESR's "The Cathedral and the Bazaar").
> 
> Maybe rather than complaining and telling us what we already know, you
> could help by providing patches?

I think that asking to "help rather than complain" is a bit unfair.

First of all I am not "complaining", I am trying to suggest that perhaps,
if time and resources are limited, the best way to spend them would be to
look for a successor.

Second, I am willing to help in any way I can, and already stated that. 
Yes I can submit patches (and will do) although in my opinion this does
not address the underlying problem. I think that updating the website
(to help raise awareness and attract developers) would be much more
useful than sending patches to fix bugs or issues.

> 
> I'm sorry if that sounds harsh, but this is really quite unhelpful to someone
> who's trying to do what they can for the project with the limited resources
> available.

It is not my intent to be unhelpful, rather on the contrary. Anyway I am
sorry if it came across that way.

Guillermo