Given this is a bug fix and thus should also go to 5.3 branch. could you try a version with no new strings that need translation? Is there a chance existing strings can be reused (from the same catalog, thus used elsewhere in the plugin)?
Otherwise we need to ask the translators for a string freeze exception.

Not yet looked at actual code, no clue about launcher/execute system, needs me more time.

New version also checks launch configuration type and starts analysis only for native applications.

Is there a chance those aspects could be split out into separate patches?

Also still hoping for a variant of the bug fix patch which does not need a string freeze break, if possible.

Is there a chance those aspects could be split out into separate patches?
Also still hoping for a variant of the bug fix patch which does not need a string freeze break, if possible.

Hi, Friedrich, sorry for delay. I think we should push it as is. Since current (wrong) logic of plugin controller we can have execute plugin unloaded with heaptrack loaded in same time. But execute plugin is really needed for plugin work so to don't break strings freeze we can only silently stop heaptrack analysis which is wrong and ugly. I think user should receive normal feedback.

So I suggest wait for 5.3 release and push this after. The patch will be available at 5.3.1 correcting release. Your opinion?

In D15565#333756, @antonanikin wrote:

Is there a chance those aspects could be split out into separate patches?
Also still hoping for a variant of the bug fix patch which does not need a string freeze break, if possible.

Hi, Friedrich, sorry for delay. I think we should push it as is. Since current (wrong) logic of plugin controller we can have execute plugin unloaded with heaptrack loaded in same time. But execute plugin is really needed for plugin work so to don't break strings freeze we can only silently stop heaptrack analysis which is wrong and ugly. I think user should receive normal feedback.

So I suggest wait for 5.3 release and push this after. The patch will be available at 5.3.1 correcting release. Your opinion?

String freeze holds for the full time in the release branch. What usually is done in such a case where a bug fix really needs to break string freeze, is to ask translators for an exception. Usually a formality, but done at least to show respect to translators and their work.

Cmp. e.g. https://marc.info/?l=kde-i18n-doc&m=151092571015821&w=2 . Once two or more representatives of language teams have okayed (and no-one objected), exception is granted (that is documented somewhere, but could not find that quickly).

So if you see no way around, ask the translators now by emailing such a request to kde-i18n-doc@kde.org Will see to start reviewing in parallel then this WE.

Different solution: Push the patch in 5.3 with i18n() replaced by plain QString() and only in master use i18n() again? Sounds like this patch should rather hit 5.3.0, otherwise the plugin is unusable?

In D15565#333758, @kossebau wrote:

In D15565#333756, @antonanikin wrote:

Is there a chance those aspects could be split out into separate patches?
Also still hoping for a variant of the bug fix patch which does not need a string freeze break, if possible.

Hi, Friedrich, sorry for delay. I think we should push it as is. Since current (wrong) logic of plugin controller we can have execute plugin unloaded with heaptrack loaded in same time. But execute plugin is really needed for plugin work so to don't break strings freeze we can only silently stop heaptrack analysis which is wrong and ugly. I think user should receive normal feedback.

So I suggest wait for 5.3 release and push this after. The patch will be available at 5.3.1 correcting release. Your opinion?

String freeze holds for the full time in the release branch. What usually is done in such a case where a bug fix really needs to break string freeze, is to ask translators for an exception. Usually a formality, but done at least to show respect to translators and their work.

Cmp. e.g. https://marc.info/?l=kde-i18n-doc&m=151092571015821&w=2 . Once two or more representatives of language teams have okayed (and no-one objected), exception is granted (that is documented somewhere, but could not find that quickly).

So if you see no way around, ask the translators now by emailing such a request to kde-i18n-doc@kde.org Will see to start reviewing in parallel then this WE.

So to get this patch moving again I just sent an email asking for string freeze exception. Should be a formality, and hopefully in a day we might have green light from the translators at least. Will see to give the actual code some review as well in the upcoming week.

Since 5.3.1 was released, can we get this in?