mc^2 news (january 2016)
Yury V. Zaytsev
yury at shurup.com
Wed Mar 9 21:30:13 UTC 2016
On Sun, 6 Mar 2016, Andrey Gursky wrote:
> Since 2+ months my patch hasn't got an owner. Does it mean the only
> owner it could get is you, Yury?
Hmmm, let me have a look at the facts... 1) There are two committers that
are currently more alive than dead. 2) I'm one of the two. 3) There was no
reaction to the patch in several months by anyone other than me.
Congratulations, Sherlock, you've nailed it! It seems that I'm currently
the only one who cares enough to keep a tab on this particular patch.
> And just to commit and let people using mc from git run with a patch
> (and test it in background) is not a way to go by mc? Are alpha, beta,
> rc,... not for this?
If you are asking for my personal opinion, then the answer is that the
patch doesn't look too bad, but I am not comfortable with pushing this
into a minor bugfix release without at least some minimal testing & having
another look at what it does. Given the acumen that you've demonstrated,
however, you could have as well guessed it by now.
Since there were no further comments (reviews, reports that anyone has
tested it on Linux / mc is still working fine on BSD, nothing!) on this
bug, neither from users, nor from the developers, it seems that it's not
*that* urgent after all.
Nevertheless, as I said, I think that it would be generally a good thing
to commit it, and I had the misfortune to indicate, that I want to try to
find some time to do it for 4.8.17, but I can't tell when I will manage.
> Yeah, too bad for mc users. And if they are not aware of such problems,
> (and mc developers don't consider them as important) it doesn't save
> users from a fault. Once they discover them, it could be too late
> (e.g., all timestamps would be already truncated).
>
> Why am I disappointed? We all do it as hobby. Fixing something can be
> treated as my wish to invest time. Clear. But cleanup of such a fix:
> using upstream code style, commenting, error handling, autotools
> checks,.. is not such important for me, but especially for upstream. I
> had to spent additional time to do it, thus expecting that in such case
> the upstream will take time to take care of the patch. Is it not fair?
> (Especially in light of many other commits during all that time the
> patch has been submitted?)
>
> OK, this was a dramatical part. But there is also a technical
> consideration. For a patch submitting one is required to rebase it
> against current (at the time of submission) master. Thus it is
> important to handle patches timely. Or at least one should not accept
> patches submitted later that touch the same code. However this is
> problematic, since other people could be unaware that there is
> somewhere a patch and have based their code also on the visible master.
> Then some submitter must be asked to rebase his/her patch. But on the
> hobby basis it seems to me not the way to go. Though, if mc developers
> would do this in such cases, it would be, of course, OK for submitters.
> What is the mc policy about that?
>
> I'd say, that git and trac are just not enough. There must be some
> mechanism to make code from all submitted patches visible at one place.
> However it is still not clear what code one should base against when
> writing a new patch.
So now that you've imparted to the world how heartbroken and demotivated
you are because of the unfair treatment that you had to endure for your
submission, what kind of reaction are you actually expecting from me?
Maybe I should take the drama queen stage too and declare that I'm sick
and tired of reading all this stuff, as no matter what you do, you'll
never ever get any compassion or even at least some sort of respectful
treatment as a committer on this list? People mostly just keep whining how
their favorite patch didn't get committed yet, and tell you how you should
be better spending your time. Oh well...
--
Sincerely yours,
Yury V. Zaytsev
More information about the mc-devel
mailing list