Re: "mc is over!?" - post by Ilia Maslakov on Russian-speaking IT site



Hello,

On Wed, 27 May 2015 21:04:33 +0200
"Yury V. Zaytsev" <yury shurup com> wrote:

[]

If you have been following the development, it would have been known
to you that, as a matter of fact, all relevant discussions to the
development of mc in the last 4-5 years were happening in Russian
speaking Jabber conference at mc-dev conference jabber ru .


[]

to show that the project wasn't usurped by Soviet Obkom.  

-25 points to adequacy

So, there's a bug tracker which doesn't get responses or even triaging,
actually for months it's not even possible to submit a ticket at all.
There's development mailing list, where it's barely possible to get a
response from maintainers either. And yet there's "Russian speaking
Jabber conference". Keep counting points on adequacy of such
maintainership, Yury. Keep suggesting people maintaining their own
forks, for years, like you did.

One of the problems mc projects has is all this "infrastructure". It's
stuck on the project model of 90ies. Gosh, it's hard, bloated,
time-consuming, inefficient, leading to frustration. But you clutch to
it and don't want to try the easy way, until people who support all
that Sisyphus work ran out of resources.

The last active committer was Andrew, but (unexpectedly to me) he
decided to resign as well.

Other people gave early warnings that not everything is right with
project maintainership, so one can only guess why it's unexpected to
you.

I have personally publicly asked Egmont to take over the
maintaintership multiple times, however, he is understandably
reluctant to do so, and no one can force him to do it, if he doesn't
want to. It's his decision.

Perhaps it should be done step by step, while simplifying
"infrastructure". Initial steps are very easy:

1. Switch development process to github. Nothing needs to be done,
except declaration - everything is already there. People should be just
encouraged to submit bugs to github bugtracker, patches - as github pull
requests.

2. People with mc experience should be given commit access to github
repo. Basic criteria should be patches already accepted from a
developer and presence of maintainership program (to be posted on the
list).

3. Encourage all interested people to triage new bugreports and
review patches.

4. Provide timely response to tickets/patches - point 3 should help
with that, but that's the main work of maintainers - communicate with
the community (not in the closed circle).  

5. Then the hard part is left - quality standards for a release, and
making a release. But this should come as natural step after all the
above, so hopefully won't be frightening to new maintainers any longer.
(But this step will require active involvement of old team, unlike the
steps above which are "automagic").


-- 
Best regards,
 Paul                          mailto:pmiscml gmail com


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]