Re: New Maintainer for MC Project

[Fudoki Wilkinson <fudoki wilkinson gmail com>]

Hello, Terry!

Now I see you actually understand me better than many mc contributors
and better than I initially thought.  Maybe I was too harsh in my
initial e-mail.  There was a significant "fallout" in my inbox caused by

the recent discussions, and I had to deal with it while being very
pressed with work and family duties.

I agree that the project needs a fresh start.  I mean something like
what Subversion is to CVS - a new codebase, new technology, new

protocol, but similar interface for the end user.  And most importantly,
the developers from the old project who don't want to repeat old design
flaws.

Speaking of the design flaws, these are some key issues I'd like to see

addressed:

1) Unicode and wide chars everywhere.  No more strlen().

2) No more targeting obsolete platforms.  Portability fixes are applied
only if they are reasonably maintainable.

3) Object oriented design from ground up.  Using an object oriented

language (e.g. C++) to enforce the design.  This is highly debatable,
but I don't think C would be good enough, with all my love to low-level
programming.  Other languages are fine as long as they bind easily to

libraries in C.

4) Reduce the number of --with and --enable.  One screen library (I
suggest ncurses), mandatory VFS (one could disable some methods but not
the whole VFS layer), dynamically load optional libraries.


5) Internal terminal and internal subshell from the beginning.  Whiners
are free to use the old mc.  Maintaining 4 combinations of
shell/terminal capabilities (with/without subshell, with/without screen
saving) should no longer be needed.  I'm fine with sharing code with

screen and bash.

6) Reuse externally maintained libraries whenever possible.  Immediate
portability to ancient OSes should not be an issue.  Quality of code and

_potential_ portability should be considered instead.  We need a
portability layer (either glib2 or APR), a fullscreen graphic library
(maybe ncurses forms) and a library for settings.


7) The viewer should be a special read-only mode of the editor.  It
could share a library with the file manager, but I would prefer it to be
a separate project with a separate maintainer and maybe a separate

mailing list.

8) We need a modular configuration for file associations with a
mechanism to find the best application for the environment.

I'm ready to post the above publicly, but right now I'd like to keep the

communication channels open for 4.6.1 release.

I have absolutely no problem with you writing to the mailing list
directly.

Unfortunately, I don't see myself the maintainer of the new project.  I
have realized over the years of work with free software that I'm much

more effective as a contributor than as a maintainer.

Once people start expecting me to deal with issues I'm not interested in
or to write responses in timely manner, contributing to the project
stops being interesting for me.  Once I even had to stop participating

in a project after my activity in the mailing list caused a wave of
"free support" requests over the private e-mail.  At some point I was
even thinking of closing my e-mail addresses and assuming a new identity

just to get rid of the expectations.

I'm ready to help with my experience, but my experience with mc was
mostly fixing and reorganizing the code, not implementing new
functionality.  That's why I'm asking you to look for a better

maintainer.

By the way, I think the new project shouldn't be called "Midnight
Commander".  Maybe something with "Commander" at the end and a
distinctive two letter command name, e.g. "Zivisus Commander" - zc,

where Zivisus is "Zivisus Is VISUal Shell  :-) 

-- 
Regards,
Pavel Roskin