Plans for Midnight Commander development

["Yury V. Zaytsev" <yury shurup com>]

Hi there,

It seems that I'm the only member of the current team left who still
wants to go on with the project, so here is my current plan.

* Ilia's private post on a Russian blog site stating that Andrew decided
to resign as a maintainer caused a lot of drama, but in reality, not
much has actually changed since the last half a year; the situation that
has been slowly deteriorating for quite awhile.

* Midnight Commander is not going away; even if commits completely
cease, I'm still up to maintaining the website and all thirds-party
services, as we've been doing for the last 5-6 years for as long as I
can; if this changes, a proper public announcement will be made as early
as possible.

* I want to make a new 4.8.15 release in the coming months (actually, as
soon as possible) from what has accumulated in the current master. It's
stupid to let it rot, and besides, I can check that all the knowledge
required to make a release is documented, and someone other than Slava
can do it as well.

* I want to use the release announcement to call for volunteers to join
the team as maintainers to contribute to bug triaging and code review.
Hopefully, this helps attract the attention of distro maintainers /
packagers and downstream users that do not follow the mailing lists.

* After 4.8.15 release, I want to go through the current tickets and try
to commit as much of trivial and/or uncontroversial patches as possible;
this might form the basis for a new 4.8.16 release.

* I'll be giving FTBFS bugs and fixes a priority, so as to at least keep
mc build-able with current kernels, libraries and compilers.

* Regarding mc^2 fork, I would like to review the code and get it
merged. After that, we can make a major 5.0.0 release, which may take
some time to stabilize. I would need help with code review to make this
happen in finite time though.

* I'm doing important and long overdue firmware / os maintenance on the
builders right now, which will allow them to function for quite some
time. After that, I want to migrate to Travis and integrate it with
Github as a priority.

* Similarly, I want to service the Trac server; I hope that I can find
out what's the problem with ticket posting delays.

* Whomever wants to help, or to join the team as a new maintainer,
please familiarize yourself with current state of the art by exploring
the repository and documentation on wiki. The least hand-holding you
require, the more convincing you look.

* You can pick tickets that need a review, rebase the patches, do a
proper review, and after you've done quite some of them, I'll be happy
to commit it for you. After demonstrating sanity and perseverance for
some time, we can talk about the commit bit. I think these requirements
are reasonable, and not much different from any other project.

* If you want to invest a large amount of work into something to prove
yourself, but are unsure about it, ask on the list. If you want to tell
me (or anyone) what and how we should do, but aren't ready to invest
large amounts of work yourself, then please don't.

* Regarding the infrastructure & the development process that we have
set up and followed while still being active: nothing is set in stone.
I'd like to believe that I'm not crazy and can be convinced by
reasonable arguments.

However, keep in mind that the best way to convince me is to actually do
the work, e.g. if someone has been triaging Trac for some time, and can
explain why it's been painful, and how a proper migration to service X
that he is ready to prepare will solve all the problems and make him
über productive, I'm likely to fall for this argument.

In the same vein, I'm unlikely to fall for the argument that all
hipsters are on Github, so if we ditch Trac immediately and move to
Github issues, then suddenly there will appear a bunch of dedicated
maintainers out of nowhere and start reviewing patches like crazy.

* On the subject of arguments: replying to emails, while actually
_thinking_ of what you are writing takes a huge amount of time. I have
very little time. This email took me more than an hour to write. Think
of how these three facts interact.

* Regarding time, I can consistently make about 1 hour per week, up to 5
hours in bursts, but that's quite a bit of stress. I'll see whether I
can figure something out, but in any case expect delays in
communication.

I will try to answer as much other emails that need to be answered from
the recent threads, but I have now about 2 hours left. I hope that these
points cover the most important issues though.

-- 
Sincerely yours,
Yury V. Zaytsev