Pump up MC development using Plugins API

[iwfmp]

Let's face it -

Many feature requests are either delayed, ignored or just unaccepted.
This is due to a single main branch,
consisting of people with a certain idea of what MC should or should not be.
Many times I had the feeling that I'm just not being heard.

MC could be so much more, if it could just be plugged with the many features that might not at first seem good or efficient.
That could happen using an easy to use plugin API, or creating a database for people to add their patches.

That way, even if a patch is not added to the main development branch,
it can be still used, modified, enhanced and tweaked by those who do find their functionality useful.

Every program these days has the ability to be extended by the open source community, and encourages it - even if an idea wouldn't make it to the native app, it could still be added to a growing database of plugins, having people encouraged to contribute.

Which is, in my honest opinion, not the case here at the moment.
Sorry to be a breaker of a bad news;)
Hope this message won't be censored, anyway.
If it does, I guess it does say something about people's openness to new ideas.
Just saying.

[gotar]

Replying to iwfmp:

Many feature requests are either delayed, ignored or just unaccepted.
This is due to a single main branch,

No, this is usually due to appropriate code missing. Or the patch being too invasive, breaking others job flow, etc. Feature requests without patches attached will obviously be ignored unless someone thinks they are worth their time.

That way, even if a patch is not added to the main development branch,
it can be still used, modified, enhanced and tweaked by those who do find their functionality useful.

You can have multiple branches with git, you can have your own fork, but first of all you need the code. I don't say plugins are bad idea (even though I see no use for them in mc), but ...show the code!:)

[szaszg]

Replying to gotar:

Replying to iwfmp:

Many feature requests are either delayed, ignored or just unaccepted.
This is due to a single main branch,

No, this is usually due to appropriate code missing. Or the patch being too invasive, breaking others job flow, etc. Feature requests without patches attached will obviously be ignored unless someone thinks they are worth their time.

Hmm... #2979 #2986 #2842 ... #1988 #1542 #1480 I think none of them being too invasive, breaking others job flow ... just not so interesting for developers (or just fan the flames)...

That way, even if a patch is not added to the main development branch,
it can be still used, modified, enhanced and tweaked by those who do find their functionality useful.

You can have multiple branches with git, you can have your own fork, but first of all you need the code. I don't say plugins are bad idea (even though I see no use for them in mc), but ...show the code!:)

[gotar]

Replying to szaszg:

Hmm... #2979

Is it not good, not efficient or not useful? No, there is no reason to put this into some plugin, instead of core. Someone should simply point bugs to be fixed or commit.

Would this code be used with plugin API? No, there would be still noone to commit. It would be even worse, as plugins would be less interested in.

#2986

Current behaviour might be considered as a bug. I would change message to something simpler like "Replace existing bookmarks" (and maybe activate this option only when some are actually set) and proceed - such change is not suitable for plugin at all.

#2842 ...

These features don't serve the same purpose - you might edit a group of somehow connected files in single mcedit (#2261), while having something entirely different on different screen. Mixing this would cause nothing but clutter for anyone using this (consider them separate browser windows each having many tabs). If anyone doesn't open magnitude of files at once, simply open them as new screens and don't use #2261 feature at all (or use only this one).
Creating an option for this would be cluttering as well - and I see no reasonable way to make this pluggable.

#1988

Bugs should be fixed, again I see no solution in extra plugins API ...as entire VFS already is one! And as you see having trivial way to include your own perl/python/whatever code to handle this didn't magically make this feature working.

#1542

Again, wishlist without the code.

#1480 I think none of them being too invasive, breaking others job flow ...

This one (have you read comments?!) and #2842 are. #1988 and #1542 have code missing.

just not so interesting for developers (or just fan the flames)...

#2979 and #2986 being a plugin would not benefit much. Where would you put it? On a web page? contrib directory? Noone would compile them. Making them switchable from UI is even worse than creating new options (just imagine a few dozens of option switching 20-liners). Passive developers is not an issue to be solved by creating plugins. Push them, join them or fork. I put patches that are pending directly into PLD Linux distribution (mc and PPA), just contact your distro maintainer and make him include changes you're interested in. Let other users push their maintainers to force change upstream. That is community assisted development, not creating zillions of useless, broken and always outdated Firefox plugins (which ignores patches as well, even encouraged by other developer: ​https://bugzilla.mozilla.org/show_bug.cgi?id=436275). The best proof that plugins won't solve anything is #1988.

[szaszg]

Replying to gotar:

Sorry i was being misleading... I do not think that any of these tickets is also to be implemented as a plugin.
I just tried to support iwfmp comment: "Many feature requests are either delayed, ignored or just unaccepted." ... and, of course, tried to refute your claims: "... appropriate code missing. Or the patch being too invasive, breaking others job flow ..."

So I will not repeat in every case, but for every case i do not think that any of these should be a plugin...

Replying to szaszg:

Hmm... #2979

Is it not good, not efficient or not useful? No, there is no reason to put this into some plugin, instead of core. Someone should simply point bugs to be fixed or commit.

Yes, it was eight months ago ... and since no one has posted any comment... as iwfmp said: delayed or just ignored...

Would this code be used with plugin API? No, there would be still noone to commit. It would be even worse, as plugins would be less interested in.

#2986

Current behaviour might be considered as a bug. I would change message to something simpler like "Replace existing bookmarks" (and maybe activate this option only when some are actually set) and proceed - such change is not suitable for plugin at all.

This ticket is 8 months old, and there is no any comment... Sorry, but why did you add your comments in here... ??
btw as iwfmp said: this ticket delayed or just ignored...

#2842 ...

These features don't serve the same purpose - you might edit a group of somehow connected files in single mcedit (#2261), while having something entirely different on different screen.

Sorry, unfortunately, it's totally unclear for me: What exactly is the two different purpose? What mean exactly: somehow connected files??? And why the "open multiple file in one mcedit instance" method better to edit somehow connected files than "open every file in different mcedit instances" method? From the user's perspective...? but never mind...

Mixing this would cause nothing but clutter for anyone using this (consider them separate browser windows each having many tabs). If anyone doesn't open magnitude of files at once, simply open them as new screens and don't use #2261 feature at all (or use only this one).

Creating an option for this would be cluttering as well - and I see no reasonable way to make this pluggable.

BTW, the patch only try to add a menupoint for a feature (ScreenList) to the editor, because only one component (filemanager) has this menupoint yet (i thought it was a small, not too invasive step, first step)... Sixteen months ago... as iwfmp said: delayed or just ignored...
Sorry, but why did you add your comments in here... ?? (no one commented this ticket really...) This ticket is 16 months old...

#1988

Bugs should be fixed, again I see no solution in extra plugins API ...as entire VFS already is one! And as you see having trivial way to include your own perl/python/whatever code to handle this didn't magically make this feature working.

Sorry, ... ??? This ticket just an example for a total disinteresting... This ticket is 4 years old.

#1542

Again, wishlist without the code.

Hmm... not really... There is a patch for this ticket:
-this patch was the #3155th ticket in savannah tracker.
-this patch dating from 2004.
-btw this patch included to an MC fork (mc-MP 4.1.40-pre9)
but (as iwfmp said:) delayed or just ignored ... and meanwhile "everything" changed in the underlaying code ... so i have to rewrite this patch totally to work again... but why? no one gave any sign: do it... just for big sleep again?

#1480 I think none of them being too invasive, breaking others job flow ...

This one (have you read comments?!) and #2842 are. #1988 and #1542 have code missing.

Hmm #1480... Sorry but i have to ask you: have you read comments?! This is an example for a "good" quarell between developers.
What code missing for this? I rewrote this patch in several time to meet the current requirements... but no one told me what would be a reasonable method ... evryone just said: is not good

• we need an option for...
• damn, we have to avoid an option for...
• find a way to restore the previouse one behaviour...

(what??? how an earth to not change a behaviour when i want to change a behaviour????)
btw i make a last try without new (micro) option, now the user can choose which is the best idea for her/his... and...(8 months ago)??? (as iwfmp said:) delayed or just ignored ...

again the #2842: Sorry but i have to ask you: have you read comments?! andrew_b wrote: Command menu is too high already. I make a note and ask something... but since no one answered it. (16 months ago...)

#1988: what code missing? the code is in the MC repo (o.k. the code is 4 years old...)... if you read comments, you have seen this "feature" run for a while... ??

just not so interesting for developers (or just fan the flames)...

#2979 and #2986 being a plugin would not benefit much. Where would you put it? On a web page? contrib directory? Noone would compile them. Making them switchable from UI is even worse than creating new options (just imagine a few dozens of option switching 20-liners). Passive developers is not an issue to be solved by creating plugins. Push them, join them or fork. I put patches that are pending directly into PLD Linux distribution (mc and PPA), just contact your distro maintainer and make him include changes you're interested in. Let other users push their maintainers to force change upstream. That is community assisted development, not creating zillions of useless, broken and always outdated Firefox plugins (which ignores patches as well, even encouraged by other developer: ​https://bugzilla.mozilla.org/show_bug.cgi?id=436275). The best proof that plugins won't solve anything is #1988.

Once again: (and IMHO iwfmp agree with it) the fundamental problem is not that there is no plugin system for MC. The problem is (as iwfmp said): Many feature requests are either delayed, ignored or just unaccepted. This is due to a single main branch,consisting of people with a certain idea of what MC should or should not be.
I have to add: not just features, but bugs (of course fixing bugs) delayed, ignored or just unaccepted too...and (sorry but i have to say): the few developers did not care about users ideas at all...

Let's face it, MC is not a huge project (whit a quite limited user base), but there are 450 open ticket -- some of 10 years old -- of which 207 are marked as defect... About 280 ticket are more then 3 years old... !!!???
BTW: you say: Let other users push their maintainers to force change upstream. IMHO the ticketing system is the place where users can push their maintainers... but those tickets are just ignored...

At last: I did not want to offend anyone... Please, just look at the facts, and just jump through on everything else...

[egmont]

(Also replying to ticket:2977#comment:5)

I have a feeling that gotar perhaps mistook commenter szaszg for the original reporter iwfmp. Apparently gotar, szaszg and myself agree that plugin API would not be the right approach.

It also seems that iwfmp, szaszg and myself (not sure about gotar) agree that mc development is not as rapid as it could be, and maybe something could be improved in this process.

szaszg pointed to several tickets that have pending patches and yet progress there is stalled. I recommend not to discuss individual tickets here, as this only pollutes this ticket with no useful information. Seeing pointers (ticket numbers) here is useful, for details and discussions about them let's go to those individual tickets.

Let's face it, MC is not a huge project (whit a quite limited user base), but there are 450 open ticket

The number of open tickets sure correlates with the number of users (more users find more bugs), but the inverse correlation with developer resources is probably much stronger. (Btw, do we have any assumptions on the number of our users?)

Currently mc has maybe 2-3 core developers, every patch goes through them. I believe they all have their full time jobs and personal lives, and mc is a hobby project for them. I'm not sure if they are willing to extend this loop, or if anyone is happy to step up as a maintainer (that is, not only commit his pet peeves, but regularly take care of other people's reports).

I think the road to this position is via tons of valuable and good quality contributions, and not giving up on failures. I myself had quite some contributions, many of them were accepted, but some got rejected due to a different vision of the product. Just a couple of days ago I had a firm "no" vote for releasing 4.8.13, yet it was released. I could have just given up saying "screw you guys I'm going home", yet I decided to go ahead and fix its regression for the next release. Team work means it's never going to be exactly as you'd like it, you won't always fully agree with your teammates, you always have to make sacrifices/compromises. Or, everyone can just make their own fork (e.g. on github), then it's totally his/her project with whatever changes he/she wants to have, and then see how many people will rather use that fork instead of the mainstream version (as e.g. the fork of A'rpi (mplayer) was quite popular once) and how many features mainstream will integrate back from that fork upon seeing its success.

So, what could boost up development? More volunteers who are happy to assist, even with tickets they're not personally interested in? More contributors who don't give up when a patch is rejected or ignored? A "friendly ping" every once in a while if a ticket is forgotten? Git commit access to regular contributors? Getting some serious fundings to pay core developers? Having micro-payments (e.g. a ticket reporter can offer a small amount if the bug gets fixed)? I really don't know.

MC has seen way worse times when the project was unmaintained for years and almost died a few times. We should be thankful that it has maintainers nowadays. My 2 cents: we should think about ways to further improve, since we've already seen at least one contributor losing motivation, which is really not good, and this trend is likely to continue if main developers remain a bottleneck.