Re: mc^2 news (january 2016)

[Andrey Gursky <andrey gursky e-mail ua>]

On Sat, 27 Feb 2016 17:58:12 +0100 (CET)
"Yury V. Zaytsev" <yury shurup com> wrote:

> On Sat, 27 Feb 2016, Andrey Gursky wrote:
>
> > Yury, do you plan to close all tickets with milestone 4.8.16 for the
> > release?
>
> I can't tell; if I get time, then yes, I hope to, if not, then I'll just 
> move them to the next one. My point was that some things actually got 
> done, and it doesn't make sense to delay them forever, so March sounds 
> like a good target for the next release.

> #3575: [PATCH] copying files: timestamps with nanosecond precision not preserved
> * milestone:  4.8.16 => 4.8.17

Since 2+ months my patch hasn't got an owner. Does it mean the only
owner it could get is you, Yury?

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?

> > I'm planning to submit a new patch, but because I had no substantial 
> > feedback about my already submitted patches (2+ months) I'm feeling 
> > discouraged and postponed a cleanup.
>
> Too bad.

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.

Regards,
Andrey