Welcome back! I think we do need some direction on the administrative side.
What kind of bridge did you have in mind?
Well, we already have installers and standalone(ish) bundles built for Windows on every commit. Combining that with the automated appimage builds, we could easily set something up that either uploads the files to a rolling github release (tagged nightly/continuous or something like that) or just have an automatically updated set of links that point to the most recent builds at their respective source (currently github and appveyor for appimages and bundles respectively).
Are the linux instances as slow as the windows instances on Appveyor? The travis test suite builds and runs the tests for both py2 and py3 in less than a third of the time it takes for appveyor to build and test with only py2 (to some extent this might be down to MSYS2).
Additionally, if we run the builds only on Appveyor, can we easily set it up to run builds/tests in parallell for Windows/Linux respectively? That is another advantage of dividing the ci between travis and appveyor.
-
Get some new out on the twitter account so that we can get people to test the new features and get a higher chance to act on problems before the next release.
-
Check in on our distribution methods; why flatpack is not working, what needs to be done
on the pip/setuptools side of things, and how we can make things easier for packagers in general. Not sure if this falls under general administration.
-
Find out if there are any showstoppers that need to be dealt with before moving into the beta phase for the next release. The last non-bugfix release is almost four years old after all, so if at all possible I think we should push for a feature freeze within the next month before too long and a release in late January early 2020.
On the note of showstoppers, I’m currently working on adding an accessible “legacy colors” (or something like that) switch so that older files can be made to look the same as they did in the version they were created in* (mostly done, PR next week sometime in November).
That, and allowing users to turn pigment off by default are afaic see the only things that need to be added to not break old behavior.
* This is technically possible now, but requires manually changing a non-gui-exposed setting, and restarting every time you need to make the switch between old and new. (or indeed, ora’s created in krita, don’t know how much of a niche case that would be).