From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27688 invoked by alias); 3 Sep 2014 16:12:35 -0000 Mailing-List: contact java-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: java-owner@gcc.gnu.org Received: (qmail 27674 invoked by uid 89); 3 Sep 2014 16:12:33 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.2 required=5.0 tests=AWL,BAYES_20,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-oa0-f53.google.com Received: from mail-oa0-f53.google.com (HELO mail-oa0-f53.google.com) (209.85.219.53) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Wed, 03 Sep 2014 16:12:30 +0000 Received: by mail-oa0-f53.google.com with SMTP id eb12so6149086oac.40 for ; Wed, 03 Sep 2014 09:12:28 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.182.33.33 with SMTP id o1mr40156021obi.24.1409760748244; Wed, 03 Sep 2014 09:12:28 -0700 (PDT) Received: by 10.202.105.20 with HTTP; Wed, 3 Sep 2014 09:12:28 -0700 (PDT) In-Reply-To: <1409568429.4242.1.camel@nirvana.localdomain> References: <540034B0.4010701@redhat.com> <1409306247.25913.21.camel@nirvana.localdomain> <54043670.4070908@redhat.com> <1409568429.4242.1.camel@nirvana.localdomain> Date: Wed, 03 Sep 2014 16:12:00 -0000 Message-ID: Subject: Re: GCJ ------ file type not supported by system From: Guillermo Rodriguez Garcia To: Mario Torre Cc: Andrew Haley , "classpath@gnu.org" , kgy , "java@gcc.gnu.org" Content-Type: text/plain; charset=UTF-8 X-SW-Source: 2014-09/txt/msg00006.txt.bz2 Hi Mario, 2014-09-01 12:47 GMT+02:00 Mario Torre : [...] >> 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). 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. 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.") 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"). Best, -- Guillermo Rodriguez Garcia guille.rodriguez@gmail.com