Future of cons

[Rajesh Vaidheeswarran]

[long mail]

Consers,

For the past few months, cons development and release cycles have been
a generally dormant despite active participation and request for features
from the user community.

Part of this has been due to my inability to devote the kind of time
that is required to support cons as its only release tester, having
to test it on multiple platforms before I felt it stable enough for a
general release.

Part of this has also been due to the fact that, despite calls for
help from the user community, we have really only three or four active
developers of cons, and really only a couple of committers to the cons
cvs tree.

There are those in the user community who are keen to see a change of
the state of things in cons, but are not willing to part with their
time for cons, or perform any role other than that of a critic.

Overall, it is clear that this model requires to change for cons to
continue to flourish as a free software project.

As I had mentioned in a previous mail to the user community, I would
like to see a team of cons developers taking the lead on the project,
and making sure that the lack of time for one doesn't impact the
development and general availability schedule for cons.

Among the many things that I have been told are wrong with cons and
how this project has gone are (listed in no particular order)

1. unmaintainable code
2. monolithic nature of the code
3. irregular (or no) release schedules
4. a general lack of development of the program
5. bad (or no) project management

I believe all of these are remediable, and I'll list some of the steps
that we, as the user community, can do to achieve these.

1. We need more maintainers. Apart from a handful that I can list, there
   has literally been no effort from anyone else to improve cons. If the
   code is monolithic or "unmaintainable", I would encourage users who
   can also be developers to take active part in developing cons.

   The one important difference between cons being run under the FSF, which
   now owns the copyright to cons, and being run as a project under another
   open source organization like sourceforge is the paperwork involved for
   would-be developers to fill out before their work is accepted into the
   program.

   While we can argue the merits and demerits of the approach the FSF takes
   in maintaining the freedom of the program, that is not the point of
   this email, and I would encourage people from avoiding wasting time and
   bandwidth on those.

   The point is, once you send in the papers, you will be given access to
   machines in the FSF to do cons work.

   If there is sufficient interest in people wanting to be cons developers,
   we can then create a separate cons-developers list to co-ordinate the
   development activity of cons, and all policies and practices that should
   be put into place.

2. Cons must move to FSF resources.

   The fact that cons has been released on dsmit.com has been historical.
   Despite having multiple mirrors, the point of mirroring has been moot
   since I was (again) the only release manager, and no one else had the
   keys to dsmit.com, which was the main site.

   The GNU project has a very powerful presence across the world, in terms,
   of web and ftp mirrors, and also in terms of multi-lingual reach. Cons
   has certainly not taken advantage of that aspect of the GNU project.

   I am in the process of moving cons out of dsmit.com into a completely
   GNU driven mechanism.

   First - The cons project already has a site on savannah.gnu.org and
           has been mostly unused for a variety of reasons. This site offers
           the same rich user interface that sourceforge offers. I would
           encourage users and testers to using this site to log bugs, etc.

           http://savannah.gnu.org/projects/cons

   Second- The main cons web site will be http://www.gnu.org/software/cons/
           Unfortunately, the reason that this was never the site of choice
           for cons was the lack of server-side scripting support that make
           up our web pages. This would mean that the cons pages need to be
           redone to be in keeping with the static nature of the GNU site.

           But, that certainly beats having bad software on
not-so-up-to-date
           PHP-enabled mirrors!

3. Lastly, once I see a good team in place, with various people taking over
   the various functions that I was in charge of (testing/release/web/some
   dev/admin), I would like to abdicate charge of cons to that able body
   and move to the side lines, since cons requires more of me than I
   can currently afford to give.

I would like to thank everyone for being very patient with me, despite
all the frustrations that you might have gone through with this project.

rv