Thanks, @tymond. If it's ok with you, I will summarize all the ideas for static analysis, both yours and mine, into a more concrete proposal that we then can refine together and implement.

Hi, @rbreu, thanks for joining in!

I'm adding an idea from @tymond: in preparation for the beta survey, developers would list of things that they changed and possible reasons it could break. This would give the beta testers ideas of where to focus while testing.

Another thing to look into: the 'Saving issues', https://phabricator.kde.org/T11194 (there are several issues mentioned, I think some of them are solved and other in progress)

Merged into documentation (https://invent.kde.org/websites/docs-krita-org/merge_requests/85).

I have briefly tested Krita on Galaxy Tab S6 (current git build with dependencies from the binary factory; I have disabled finger painting in the settings). Observations so far:

• The S-Pen draws fine even without the stabilizer. Pressure sensitivity works, tilt does not (I'm not sure about the hardware/software support of tilt for the device, though in Autodesk Sketchbook some brushes react to angle of the pen).
• Sometimes the pen stops drawing (it seems to be resolved with merge request 196, but I need more testing to confirm that).
• Sometimes the UI does not respond to the pen, only to touch (or maybe it is just too slow with the pen).
• I haven't find a way to access context menus (e.g. in layers or brush presets dockers).
• Upon creating new document nothing happens. After changing the device orientation, the UI redraws and the document shows up.
• The native title and navigation bars take too much space on the screen. Maybe we would be able to plug the main menu into a button in the toolbar and run Krita always on fullscreen and save space.
• For the popup palette (and possibly other actions), we might consider three-finger touch gestures/swipes.

May I close this as resolved? From what I have seen, the beta testing is quite successful so far and I'm not aware of something missing implementation-wise.

Points 1 and 2 are now in the contributor's manual. Point 3 will reincarnate in later documentation efforts.

I’m trying out a prototype in which I have decoupled the development build alert and new version notifications:

• When appimage updater is in use, there are also updates for dev builds. The area next to Start header is too crowded then.
• It makes more sense to me if the updater notification is under the “Check for updates” checkbox, not on the other side of the window.

What does the link do after it is done updating. The "To complete the update, run the new version". Does that restart Krita?

Current progress (still on localhost; the size of the appimage is not final, it's just my debug build). The core of the check and update process is done. I am not sure what to do with the UI part and reporting errors to users. I have added the update button and placeholder messages to the original area in the Start section, but it feels crowded and overall weird to me. Errors are logged to the usage log but not propagated to the user interface right now (apart from 'Error occurred' message). @scottpetrovic, may I ask you for a bit of your time to look at it with me?

It looks great :)

I think we should start with a short description of the survey, what is expected of the participants and point to our reporting bugs docs page, should the participant encounter a bug while testing.

I have drafted a more detailed analysis, based on the ideas discussed in this task. The high level outline is there, but a lot of important detail is missing.

I have converted points 1 and 2 into manual pages, draft here: https://invent.kde.org/websites/docs-krita-org/merge_requests/59

In T11320#193973, @rempt wrote:

Okay, that mail didn't work. I thought we might just put the survery link in the krita welcome page; that way people have to at least start the right version to do the survey.

Monthly development news is a good idea. I'm not sure that it will work for getting people to test, or that it will cover all the features. I thought that making it one feature/change at a time (we should hand pick the right one though) would make it seem more easy and quick and thus attract more testers.

Concerning the surveys themselves, can we use https://survey.kde.org/?

In T11194#191621, @rempt wrote:

Shouldn't a QIODevice::close() do the fsync already?