Re: Future of cons

[Timothee Besset]

Not much to say. I didn't even know the savannah SF tool existed. I see
that we have both the cons source repository and the web pages repository
there.

Going over some of the points:

> 1. unmaintainable code
> 2. monolithic nature of the code

Looks like it. I've been learning perl over the last months, but I know
I'm far from being able to understand what's in there. I restrict myself
to testing and writing test cases cause that's more or less all I can do
for now.

> 3. irregular (or no) release schedules
> 4. a general lack of development of the program
> 5. bad (or no) project management

Yep. All we need, is a new release / stable release of the 2.3.x stuff.
This is mainly:
- updating the web page
- building packages for a release

Issues with the current code .. I don't think there are many. Johan
Holmberg fixed a problem with the dependency scan recently, that's about
it. I have a bug against the parallell cons patch, but since this has
never been supported officially, it doesn't matter so much (At least not
when talking about a new release).

It doesn't take a huge amount of ressources to put out a new release.
Doing further developement (in terms of new features) would require a lot
more effort. So I guess that part is pretty much on hold till further
notice.

I don't think I can honestly say that I'm going to take care of a new
release. I maintain and release several other things already, I would
probably slap something together for cons, but it would be crappy. I had
hoped Johan Holmberg would be able to take the lead .. with our help of
course?

TTimo

On Mon, 5 Aug 2002 10:49:32 -0400
"Rajesh Vaidheeswarran" <address@hidden> wrote:

> [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
> 
> 
> 
> _______________________________________________
> address@hidden
> http://mail.gnu.org/mailman/listinfo/cons-discuss
> Cons URL: http://www.dsmit.com/cons/
>