[Midnight Commander] #3004: Pump up MC development using Plugins API
Ticket System
-----------------------------------+--------------------------------
Reporter: iwfmp | Owner:
Type: enhancement | Status: new
Priority: major | Milestone: Future Releases
Component: mc-core | Version: master
Keywords: | Blocked By:
Blocking: | Branch state: no branch
Votes for changeset: |
-----------------------------------+--------------------------------
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.
--
Ticket URL: <http://www.midnight-commander.org/ticket/3004>
Midnight Commander <http://www.midnight-commander.org>
Midnight Development Center
Ticket System
Reporter: iwfmp | Owner:
Type: enhancement | Status: new
Priority: major | Milestone: Future Releases
Component: mc-core | Version: master
Blocked By: | Blocking:
Branch state: no branch | Votes for changeset:
Changes (by szaszg):
* cc: szaszg@… (added)
--
Ticket URL: <http://www.midnight-commander.org/ticket/3004#comment:1>
Ticket System
Reporter: iwfmp | Owner:
Type: enhancement | Status: new
Priority: major | Milestone: Future Releases
Component: mc-core | Version: master
Blocked By: | Blocking:
Branch state: no branch | Votes for changeset:
Changes (by onlyjob):
* cc: onlyjob@… (added)
--
Ticket URL: <http://www.midnight-commander.org/ticket/3004#comment:2>
Ticket System
Reporter: iwfmp | Owner:
Type: enhancement | Status: new
Priority: major | Milestone: Future Releases
Component: mc-core | Version: master
Blocked By: | Blocking:
Branch state: no branch | Votes for changeset:
Changes (by gotar):
* cc: gotar@… (added)
Comment:
Replying to [ticket:3004 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!:)
--
Ticket URL: <http://www.midnight-commander.org/ticket/3004#comment:3>
Ticket System
Reporter: iwfmp | Owner:
Type: enhancement | Status: new
Priority: major | Milestone: Future Releases
Component: mc-core | Version: master
Blocked By: | Blocking:
Branch state: no branch | Votes for changeset:
Comment (by szaszg):
Replying to [comment:3 gotar]:
> Replying to [ticket:3004 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!:)
--
Ticket URL: <http://www.midnight-commander.org/ticket/3004#comment:4>
Ticket System
Reporter: iwfmp | Owner:
Type: enhancement | Status: new
Priority: major | Milestone: Future Releases
Component: mc-core | Version: master
Blocked By: | Blocking:
Branch state: no branch | Votes for changeset:
Comment (by gotar):
Replying to [comment:4 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.
--
Ticket URL: <http://www.midnight-commander.org/ticket/3004#comment:5>
Ticket System
Reporter: iwfmp | Owner:
Type: enhancement | Status: new
Priority: major | Milestone: Future Releases
Component: mc-core | Version: master
Blocked By: | Blocking:
Branch state: no branch | Votes for changeset:
Comment (by szaszg):
Replying to [comment:5 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 [ticket:3004 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 [comment:4 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 [ticket:3004 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 [ticket:3004 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 [ticket:3004 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 [ticket:3004 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
[ticket:3004 iwfmp] said:) '''delayed''' or just '''ignored''' ...
again the #2842: Sorry but i have to ask you: have you read comments?!
[ticket:2842#comment:2 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 [ticket:3004 iwfmp] agree with it) the fundamental
problem is not that there is no plugin system for MC. The problem is (as
[ticket:3004 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...
--
Ticket URL: <http://www.midnight-commander.org/ticket/3004#comment:6>
Ticket System
Reporter: iwfmp | Owner:
Type: enhancement | Status: new
Priority: major | Milestone: Future Releases
Component: mc-core | Version: master
Blocked By: | Blocking:
Branch state: no branch | Votes for changeset:
Comment (by 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.
--
Ticket URL: <http://www.midnight-commander.org/ticket/3004#comment:7>
Ticket System
Reporter: iwfmp | Owner:
Type: enhancement | Status: new
Priority: major | Milestone: Future Releases
Component: mc-core | Version: master
Blocked By: | Blocking:
Branch state: no branch | Votes for changeset:
Changes (by egmont):
* cc: egmont@… (added)
--
Ticket URL: <http://www.midnight-commander.org/ticket/3004#comment:8>