For the "kde4" branch: 08 - Update the synchronizer.docbook file because of the latest changes REVIEW: 124335
Needs ReviewPublic

Authored by asensi on Aug 7 2019, 3:12 PM.

Details

Reviewers
None
Group Reviewers
Krusader
Summary

I had to use the git version of Krusader 2.4.0 (from its "kde4" branch), and it was advantageous to backport some of the improvements that were made to the master branch of Krusader.

After some months of having used this backport, in case it may be helpful for someone, it can be also added to the "kde4" branch of Krusader.

Diff Detail

Repository
R167 Krusader
Lint
Lint Skipped
Unit
Unit Tests Skipped
asensi created this revision.Aug 7 2019, 3:12 PM
Restricted Application added a project: Documentation. · View Herald TranscriptAug 7 2019, 3:12 PM
Restricted Application added a subscriber: kde-doc-english. · View Herald Transcript
asensi requested review of this revision.Aug 7 2019, 3:12 PM

I'm not a Krusader developer, but from the global point of view, the kde4 branch is basically dead. It's not tracked for translations, it's not tracked by the sysadmin/repo-metadata repository.

We (as KDE community) are trying to phase out kdelibs 4.x stuff. Qt 4.x itself has been unmaintained for a long while.

asensi added a comment.Aug 7 2019, 3:40 PM

Hi, Luigi! Well, I was referring to the virtual machines running prior operating systems (and physical machines, I remember that the LTS support of Ubuntu 14.04 ended at the end of April and I still saw some of those machines). Sometimes the reason is that some programs do not run in recent versions of operating systems, other causes may exist.
There's also the case of Lliurex 16, an operating system installed in thousands of computers, I had to work with it and there I could only build the "kde4" version of Krusader.

The proposed «commits» don't mean that this version of Krusader is supported, it's just that they may be convenient for someone, it doesn't cause any harm having them available (they were useful for me, and may be for other people).

nmel added a subscriber: nmel.Sun, Aug 18, 6:21 AM

I have no problem when someone is trying to improve a dead branch. If the person finds this useful and wants to share their changes to others — he or she is welcome to do so. It's an Open Source after all. In the same time, I understand what Luigi is saying that it might send a wrong signal to users. In addition, commits we push to the official repo are reviewed and tested, and should be only pushed when approved by at least another dev and no objections from others (unfortunately, it's not enforced due to a weak infrastructure). It means someone needs to test the changes you propose in 10 code reviews. Personally, I have no interest in kde4 commits anymore and even have no environment to test it. I doubt you'll find another dev who has.

It doesn't mean you should abandon the idea of sharing the changes. For example, you can fork krusader on github or other platform, call it krusader-kde4 or alike and share your changes there. It might be a good idea to remove qt5/kde5 branches and keep current kde4 as master in the fork. What do you think about this idea, Toni?

For example, you can fork krusader on github or other platform [...]. What do you think about this idea, Toni?

I don't think people would find it, Nikita.

In addition, commits we push to the official repo are reviewed and tested, and should be only pushed when approved by at least another dev and no objections from others (unfortunately, it's not enforced due to a weak infrastructure). It means someone needs to test the changes you propose in 10 code reviews. Personally, I have no interest in kde4 commits anymore [...]

That is how it should be. But someone stopping improvements "because I am not going to review it"? The changes are visible in those code reviews. Later code can be changed, as the code is in a git repository.

Those proposed changes are only Krusader backports, the code was already reviewed. If I anyone needs it, I can look for the original commits and mention them in each patch.

The code has worked and was useful for my case, and may be useful for someone else.

nmel added a comment.Mon, Aug 19, 6:17 AM

For example, you can fork krusader on github or other platform [...]. What do you think about this idea, Toni?

I don't think people would find it, Nikita.

Personally, I find a lot of useful packages and tools using a search engine every week and most of those searches land on github. How do you think a person is going to search whether kde4 version of krusader is getting updates? Will she likely go to a search engine and type something like "krusader kde4" where the mentioned repo will be in top positions due to good naming? Or she'll likely considering to find the official repo, clone it, look at commits and try to find where v2.4 ended it's life? Just ask yourself.

In addition, commits we push to the official repo are reviewed and tested, and should be only pushed when approved by at least another dev and no objections from others (unfortunately, it's not enforced due to a weak infrastructure). It means someone needs to test the changes you propose in 10 code reviews. Personally, I have no interest in kde4 commits anymore [...]

That is how it should be. But someone stopping improvements "because I am not going to review it"? [...]

It's a pity that you understand my words this way. I'm not stopping you here and, actually, I can't stop you and you know it. Anyone who has a permission to commit can update any branch in Krusader repo and many other KDE repos without even asking (this won't be a wise thing to do though). I was just sharing my thoughts and tried to reason what the right thing to do is. It's just an opinion and I truly didn't mean to hurt your feelings. I'd like to see what other devs think on the subject.

How do you think a person is going to search whether kde4 version of krusader is getting updates? Will she likely go to a search engine and type something like "krusader kde4" where the mentioned repo will be in top positions due to good naming?

Personally, I find a lot of useful packages and tools using a search engine every week and most of those searches land on github.

Personally, I would go to Krusader's repository, instead of a fork. ¯\_(ツ)_/¯

If we think about it, with good naming the search she would perform would be e.g. Krusader Plasma 4.

I was talking about general cases (there are a lot of them), not only that particular case, but maybe I didn't understand your words, or you didn't understand my words, or you didn't express yourself as you would have liked, or I didn't express myself as I would have liked. Communication problems, sender, receiver, channel, message, etc. it's a pity :-(

I personally think that the original repo could be used, my perfect solution would be a scratch repo. But (this is a big but) the target of this set of patches shouldn't be a normal user but a distro packager, and we must show big warning saying that this does not mean that the developing is active and only trivial patches for critical bugs could be backported; sometime a single-line patch cannot be backported because all the logic around was changed, or the backport does not fix at all or even worse. Also, because the development is closed, no bugs should be reported because the first answer would be "can you try on a newer version?".

While some devs are planning the arrival of qt6/kf6, I would know why a distro is sticked to qt4/kde4 (and I use Slackware), I would check if there is a planned switch to plasma or if the distro packaging is abandoned or if exists a newer release of the distro.

That said, this set of patches is very short and they are an (almost) copy of the original commits but I would talk to the distro devs first.

I personally think that the original repo could be used, my perfect solution would be a scratch repo. But (this is a big but) the target of this set of patches shouldn't be a normal user but a distro packager, and we must show big warning saying that this does not mean that the developing is active and only trivial patches for critical bugs could be backported; sometime a single-line patch cannot be backported because all the logic around was changed, or the backport does not fix at all or even worse. Also, because the development is closed, no bugs should be reported because the first answer would be "can you try on a newer version?".

But distro packagers are not going to use that branch: all (de facto, but see below) distributions switched to the Qt 5 version of Krusader long ago:

https://repology.org/project/krusader/versions

Anything >= 2.5 is Frameworks- and Qt 5-based.

While some devs are planning the arrival of qt6/kf6, I would know why a distro is sticked to qt4/kde4 (and I use Slackware), I would check if there is a planned switch to plasma or if the distro packaging is abandoned or if exists a newer release of the distro.

Krusader is not related to Plasma at all.
Slackware is probably the only historical distribution which hasn't switched to Qt5 yet, and in that case I'd suggest the usage of the ktown repository from https://alien.slackbook.org ; and to be honest them using Qt 4 is not a reason to keep that old branch alive.

Let me reiterate this: Qt 4 is gone, and it has been gone for a good while.