Plugin headache + bug hunt + release

[Gengis Dave]

Hi guys,

it seems I have a bad timing to resume to develop Krusader (or the opposite, who knows...).

First point: there are some troubles with all the plugin system, I've done some investigation and it shouldn't be hard to fix, but it will require many testing on different distros. Also, I'm fixing all the deprecations introduced in the last releases of KF5.

Second point: I propose to do another run on bugzilla to close all the oldest bugs that are not referring to a 2.7.x version.

Third point: fixing the plugin could be a good opportunity to the 2.8.0 release. I have just one MR open and no other big changes (some bugs could be closed, though).

Opinion? I don't have a straight plan, consider this mail as a "call to arms".

Thanks all.
Davide

[Toni Asensi Esteve]

Davide wrote:

> [...]

> Opinion? I don't have a straight plan, consider this mail as
> a "call to arms".

My opinion is that in the present situation those points look very good to me.

Greetings!
Toni

[Nikita Melnichenko]

Hi folks,

Thanks Davide for bringing this up. I think the 2.8.0 release is long
waited by many people. We have many issues fixed on the master branch,
however lots of users are hesitant to compile from sources, and we see
many bugs are closed as dups these days. BTW, thanks Davide and Toni for
being active with regards to bug reports!

I agree with all points, however I don't have much spare time to
actively collaborate on this effort. I can help with the release when
the time comes and sweeping the bugs a little.

As for the plan, what you propose already looks like a good plan to me. ;)

Nikita.

[Gengis Dave]

On martedì 24 agosto 2021 09:01:12 CEST Nikita Melnichenko wrote:
> Hi folks,
>
> Thanks Davide for bringing this up. I think the 2.8.0 release is long
> waited by many people. We have many issues fixed on the master branch,
> however lots of users are hesitant to compile from sources, and we see
> many bugs are closed as dups these days. BTW, thanks Davide and Toni for
> being active with regards to bug reports!

Starting from the third step: should we raise the minimal requirements for the
next release?

ATM, I'm checking repology.org to get the distros' status. My idea is to "ignore"
the distros that does not ship 2.7.2 (2.7.x is fine too).

Direct example (with a used distro): Ubuntu 18.04 ships Qt 5.9.5 and Frameworks
5.44 but it does use Krusader 2.6.0; unless the packagers won't raise the build,
I would ignore it. This is almost similar to when we dropped the KDE4 Krusader
version.

---
This is my personal opinion, I use a rolling release / bleeding edge distro since
ten years and the number of regressions is low. While I can understand that
upgrading a distro could be difficult for some users, I don't understand why
packages are not updated in non-LTS distros.
---

Back again, I propose to raise to the Ubuntu 20.04 versions: Qt 5.12 and KF5 5.68;
this should covers all other active distros.

Davide

[Toni Asensi Esteve]

Davide wrote:

> Starting from the third step: should we raise the minimal requirements for
> the next release?

> [...] I propose to raise to the Ubuntu 20.04 versions: Qt 5.12 and KF5 5.68;
> this should cover all other active distros.

I suppose that's better that way, thanks for proposing it.

Note: On
https://launchpad.net/~rikmills/+archive/ubuntu/experimental/+packages it's
seen that the git version of Krusader is still compiled for people who want to
use it under (K)Ubuntu 18.04 LTS and other ones. In the end I could email Rik
Mills (the PPA is maintained by him) and tell him that the minimal
requirements have been raised.

Best regards,
Toni

[Nikita Melnichenko]

Bumping this thread. I have some time to work on Krusader in December and would like to do a release. Please let me know if you'd have time to do code reviews or/and help to fix outstanding issues. The plan is the following:

1. Next week I'm going to sweep bugzilla and brush up on recently reported issues.
2. Let's highlight the problems we'd like to address before the release. Davide, you mentioned the plugin problem - can you elaborate? Once I have more info, I can help looking into that. Any other things we'd like to address from top of your mind, everybody?
   
3. Then, let's decide which issues we'll attempt to fix and the timeframe (I suggest, no more than 10-14 days).
4. After the PRs are merged, I'll use the latest commit as a branching point for v2.8 and follow the release guide that I maintain. I'm sure some of the steps have changed since the last release, so I prefer to do this in December as much as possible.

ATM, I'm checking repology.org to get the distros' status. My idea is to "ignore"
the distros that does not ship 2.7.2 (2.7.x is fine too).

Yes, the v2.6 won't be supported. In fact, we don't have resources to support anything beyond master and stable branches, i.e. v2.8 going forward. However, we'll do the best to repro an issue reported on v2.7.2 to see if it's not fixed in maintained branches yet.

Back again, I propose to raise to the Ubuntu 20.04 versions: Qt 5.12 and KF5 5.68;
this should covers all other active distros.

I completely agree. We actually discussed this on some PR in 2020 but decided to wait till late 2020, AFAIR. I can do this as a part of the release prep.

While I can understand that
upgrading a distro could be difficult for some users, I don't understand why
packages are not updated in non-LTS distros.

Lack of maintainers, I guess.

Thanks,
Nikita.

[Toni Asensi Esteve]

> Please let me know if you'd have time to do code reviews or/and help to fix
> outstanding issues.

Work doesn't allow me to have much time, and pending tasks are awaiting to be
done on Christmas, although I can try to do what I can.

> Any other things we'd like to address from top of your mind, everybody?

I have reported about [The size of the krusaderrc file gets too big]
(https://bugs.kde.org/show_bug.cgi?id=447197), if it may help.

Best regards,
Toni

[Nikita Melnichenko]

Thanks for your reply, Toni! I got it, Davide seems to be busy as well,
so I'll try to limit the number of changes and we can address more
issues in v2.8.1. I will try to repro your bug too. Beside this, master
branch build shows 34 warnings on my system, I will be fixing those
before release.

Best,
Nikita.

[Gengis Dave]

Hi guys, sorry for the delay, AWS studies are draining my free time, anyway:

- the plugin problem was solved in https://invent.kde.org/utilities/krusader/-/merge_requests/73, with a little problem with Ark that should be solved with 22.04 release (https://invent.kde.org/utilities/ark/-/merge_requests/80);

- I've one open MR (https://invent.kde.org/utilities/krusader/-/merge_requests/27) that should still work - there are some changes in Solid to check, though;

- I haven't compiled Krusader with the new Qt / KDE for a while, there colud be more deprecations to be fixed; as discussed in https://invent.kde.org/utilities/krusader/-/merge_requests/68, compat.h guards should prefer the new method rather than the deprecated one by checking the version that introduced the new method rather than the one that it deprecated the old one;

- in the next days I'll do some runs on bugzilla to see if some report could be easily closed, I will assign to myself tasks if I can open a MR

Regards,
Davide

[Nikita Melnichenko]

Hi folks,

Let me give some updates.

1. I raised versions of the requirements as discussed. We didn't have KF version req, so I added it and used it for ECM too as they are in sync these days. Please check the MR. I'll clean up compat.h and other inline version checks once this MR is merged.
   
2. I went through the deprecations and fixed them. There are more than 10 different types. Please check the MR.
3. Updated copyright years and dev lists. Please check the MRs.
4. Looked at bugzilla, addressed some bugs, found some issues we should fix before the release. I listed them in the summary below.
5. Haven't reviewed and tested the MRs yet, will do soon.
6. Refreshed my memory on the release process.

Let me summarize what's needed for the release and we can use it as a checklist later.

1. Bugs:
1. #447394: Regression: New Tab actions perform a tab duplication instead of opening a fresh tab
   
2. #388678: Newly added or changed actions are missing in menu - @Nikita (MR created)
3. #447197: The size of the krusaderrc file gets too big - @Toni (as he assigned to himself)
2. Merge requests:
1. #27: Unmount devices from external action
2. #61: Clone the Tab by click Ctrl+LMB [Proposal]
3. #72: Make a '%' translatable. Use 'formatByteSize()' to convert to MiB
4. #74: Set requirements for Qt and KF versions, refactored root cmake file
5. #75: Fixed various deprecation warnings from Qt5 and KF5
6. #76: Updated copyright years (2021)
7. #77: Updated contributor status per activity last year
8. #78: Fixed krusaderui.rc update issue when user opens a new build (fixes bug#388678)
9. Cleanup version checks (depends on #74) - @Nikita
   
10. Update copyright years (2022) - @Nikita
11. Update docs for new features - @Toni, @Yuri, please let us know if it's done earlier.
12. For release: version update in Documentation and AppStream files - @Nikita
13. For release: ChangeLog and NEWS update - @Nikita
14. For release: Version bump - @Nikita
15. For release: Website update - @Nikita
3. Agree on release name. I propose "Rock Solid" (implying it's stable). Let us know your ideas and suggestions.
   
4. Release prep and release procedures - @Nikita

Let me know if I forgot anything.

Another high priority (IMO) bug #425070: Krusader crashes when right-clicking on a file which being externally updated is not included, since it needs a bigger change and more testing afterwards. It's better to do it after release, so we have time to fix any regressions.

Happy Holidays!

Thanks,
Nikita.

[Gengis Dave]

Hi, Distrowatch published the version update (at the moment, only Arch ships newer version).

In the next days, I will check the open bugs.

My idea is to ask the user to check if the new version solves the issue (even if we are really sure it does) and put the bug in NEEDSINFO state.

Also, should we deprecate older versions of Krusader? For example, the only distro that ships 2.6 is Ubuntu 18.04 that will be deprecated on April 2023.

I would ask the user to update to 2.8.0 or 2.7.2 (if not available, check on repology).

I'm fine to change this behaviours, even close the bug directly saying that the bug it's fixed in the last version.

Davide

[Nikita Melnichenko]

Hi Davide,

Yes, NEEDSINFO is a good idea, especially if there is no clear way to repro.

Keep in mind, we have tags for bugs we confirmed:
https://bugs.kde.org/buglist.cgi?bug_severity=critical&bug_severity=grave&bug_severity=major&bug_severity=crash&bug_severity=normal&bug_severity=minor&bug_status=UNCONFIRMED&bug_status=CONFIRMED&bug_status=ASSIGNED&bug_status=REOPENED&keywords=triaged%2C%20&keywords_type=allwords&known_name=Krusader%3A%20triaged&list_id=2214603&product=krusader&query_based_on=Krusader%3A%20triaged&query_format=advanced

For these we know they are not fixed (unless we forgot to update some).

I think we don't support 2.6 for a long time already. 2.7.2 is around for more than 3 years, so it's reasonable to ask to upgrade at least to 2.7.2.

We close bugs once they are fixed in master.

Nikita.