Re: mc^2 news (january 2016)

[Yury V. Zaytsev]

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
___
mc-devel mailing list
https://mail.gnome.org/mailman/listinfo/mc-devel

Re: mc^2 news (january 2016)

[Andrey Gursky]

On Sat, 27 Feb 2016 17:58:12 +0100 (CET)
"Yury V. Zaytsev"  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
___
mc-devel mailing list
https://mail.gnome.org/mailman/listinfo/mc-devel

Re: mc^2 news (january 2016)

[Yury V. Zaytsev]

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.


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.

--
Sincerely yours,
Yury V. Zaytsev
___
mc-devel mailing list
https://mail.gnome.org/mailman/listinfo/mc-devel

Re: mc^2 news (january 2016)

[Andrey Gursky]

On Thu, 25 Feb 2016 22:17:33 +0100
"Yury V. Zaytsev"  wrote:

> On a related note, I think we (or, rather, I) should start thinking
> about releasing 4.8.16 sometime soon. There is quite a bit of good stuff
> accumulated in master already.

Yury, do you plan to close all tickets with milestone 4.8.16 for the
release?

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.

--
Andrey
___
mc-devel mailing list
https://mail.gnome.org/mailman/listinfo/mc-devel

About 4.8.16 (was: Re: mc^2 news (january 2016))

[Andrew Borodin]

On Thu, 25 Feb 2016 22:17:33 +0100 "Yury V. Zaytsev" wrote:
> On a related note, I think we (or, rather, I) should start thinking
> about releasing 4.8.16 sometime soon. There is quite a bit of good stuff
> accumulated in master already.

I agree.

> The biggest problem now is that the cleanup branch again has became quite 
> huge.

The cleanup branch contains about 50 commits. Most of them are small and clean.

> But I can always tell to myself that I trust Andrew's good judgment :-)

Thanks!

> Andrew, what do you think of this? Do you have any personal plans as to
> what do you want to get done before 4.8.16?

No, I don't. We can release 4.8.16 after review and merge of #3566 and #3547.

IIRC, we don't have tickets that are so critical to be included in release.
But I can mistake because we have 540 open tickets and I can forget something.

-- 
Andrew
___
mc-devel mailing list
https://mail.gnome.org/mailman/listinfo/mc-devel

Re: mc^2 news (january 2016)

[Yury V. Zaytsev]

Hi,

Too bad I'm only answering now...

On Tue, 2016-01-12 at 07:40 +0200, Mooffie wrote:
> 
> * The git commit history was rewritten. It now consists of around 90
>   commits that go from genesis to today.

Awesome!!!11 That'd make reviewing it a lot easier.

> * New users can get an impression of mc^2 instantly: just run it and
>   a dialog will pop up asking you if you want to enable some "factory
>   defaults" goodies.

Very cool, is the tip now rebased against 4.8.15? Now that there is a
friendly first start screen, maybe I should give it a try on my work
laptop. The screenshots look really mindblowing, in particular, the
spellchecker. I always wanted to have something like this in mcedit!

Just wondering, do you have any kind of internal roadmap of where you
want to go now? Any ideas on how you'd like to get it merged? ~90
smaller commits is definitively better than few huge commits, but that's
still quite a lot. I haven't looked at the commits themselves yet, but
do you think you can try to push them in batches making the patchset
against vanilla smaller and smaller, until we just go ahead and merge
the remaining stuff?

On a related note, I think we (or, rather, I) should start thinking
about releasing 4.8.16 sometime soon. There is quite a bit of good stuff
accumulated in master already. The biggest problem now is that the
cleanup branch again has became quite huge. But I can always tell to
myself that I trust Andrew's good judgment :-)

Andrew, what do you think of this? Do you have any personal plans as to
what do you want to get done before 4.8.16?

-- 
Sincerely yours,
Yury V. Zaytsev


___
mc-devel mailing list
https://mail.gnome.org/mailman/listinfo/mc-devel