Sorry I’ve been out of the loop for so long, but I think I’m ready to start tackling the admin side of the MyPaint community. So what do you guys need for me to do or track down? I know we need to sort out our domain stuff since which I hope @achadwick helps out with. One thing I want to do is add an issue tracker bridge between github and our Discourse forums. Next thing is to create an automated build system to provide builds that people can test out on Linux and Windows( and possibly Mac just need to know where we can do it). I honestly thing we should drop travis ci and use appveyor since it stays mostly up-to-date. Then lastly we need to address the website which needs a serious upgrade. If some is willing to work with me with web design that would be awesome.
What other things do you guys thing we need to address with the admin side of MyPaint?
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).
Is there any good way to distribute control over things like this? It would really be a shame to lose control of the mypaint.org (and have it start spreading malware!), but it sounds like Jon will renew it or xfer it to someone else. It looks like some domain providers allow you to share administration with other users, but I’m not sure if the one he used can do that.
Likewise, maybe we should look at the same for twitter and discourse even:
In other words, we should probably have some succession planning for all our bits and pieces.
I’m also wondering how we might use FMV (function multi-versioning:
Intel made a neat little script to automatically update your code, but I’m worried it won’t work on windows. Maybe we can manually target a few platforms; a “generic” build, and maybe two more for newish and bleeding edge processors. It might be a bit confusing to choose which to download, but the performance improvements would be worth it, I think.
