flathub / community.pathofbuilding.PathOfBuilding

https://flathub.org/apps/details/community.pathofbuilding.PathOfBuilding
8 stars 4 forks source link

Pass off to PoB Community devs #36

Closed Thorinori closed 1 year ago

Thorinori commented 1 year ago

Seems like it wouldn't be a bad idea to pass this repo over to Localidentity or someone from the community branch team so the update merges can be done whenever they update as well. Thanks for setting this up though in general, it is definitely convenient especially with the bot updating stuff.

ernstp commented 1 year ago

I'm not sure what you envision here really, but I don't think they are interested, are running Linux, or have time for that matter. If you think upstream should provide Linux support you can take it up there. You can search in their GitHub issues to see the history of it. I mentioned my project here: https://github.com/PathOfBuildingCommunity/PathOfBuilding/issues/4003

Thorinori commented 8 months ago

So the flatpak ending up behind the community fork for potential days is why I was suggesting this. I am not expecting any additional development or anything, just would like the rollout to be handled by the dev team too so we don't end up days out of date particularly during times when it is being updated frequently. Either handing it off or streamlining the build process would be nice since the bot seems to keep failing the automerges recently.

ernstp commented 8 months ago

Are you speaking for the dev team?

Thorinori commented 8 months ago

Nope, in the issue you linked originally you only ever notified them you made it rather than having any indication of being willing to hand it to them if they wanted or anything. The builds breaking for the recent updates again (and previous leagues having the build be several days behind at a few points) is what brought me back to bring this up again though.

EDIT: Also wanted to mention that Linux compatibility IS something they do have in mind though as evident by their comments about new prereqs to run it under Wine with their most recent updates today.

SECOND EDIT: Also to be clear, this isn't anything about problems with you maintaining it or anything (in fact I appreciate you having made it in the first place), the thought process is more to reduce moving parts so to speak, so if/when there are build issues like today, it could be more directly handled with the actual release for each version of PoB, as opposed to having to potentially wait for if you are busy and something comes up for example. The other solution of course would be finding a way to get the auto-updating working within the flatpak version as well, but that seems like a much bigger chore on the surface at least.

zao commented 4 months ago

I'm a bit late to this issue, but here's some incoherent thoughts as a SimpleGraphic developer.

On Linux compatibility of the Windows runtime, my approach is to make the new runtime solve the fundamental problems and advance the tech on Windows while aiming to not make it worse if possible on other OSes when run under Wine and its variants.

On first party support of other OSes in general, we don't really have the maintainer bandwidth to build, test and ship for Linux or macOS. This holds both for external runtimes like the pobfrontend that powers the AUR/Flatpak and our own runtime. Much like localization, we can't really test and support something we don't use or understand.

SimpleGraphic technically builds and runs on other OSes with a reduced feature set. Even though I've got proof-of-concept builds, they're far from being something we could ship. Even if we polish them up enough to ship them, we don't have hardware or personnel to test and support it over time as the program and engine evolves.

The current informal stance is pretty much to try to not break running under Wine; and expect third party runtimes to keep up with runtime/program changes.

While the pace is glacial, we aim to eventually improve our runtime around Unicode support, text rendering, vector shapes and richer drawing primitives like meshes. This may need runtimes like pobfrontend to keep up, as we really can't be hampered by their lack of implementations. The risk there is that such improvements may come as a surprise at release time and delay the package greatly while catching up.

At some point in time, it may make sense for a packager to evaluate if it makes sense to base a Flatpak build on SimpleGraphic instead of pobfrontend and take on the support burden for that, but the value of that proposition is probably low currently. I've tried packaging it in the past with both Flatpak and one of the competition (AppImage?) but found it miserable to troubleshoot and deploy.