I'd like to suggest we capture work that needs to be done such that we do not forget and everybody can see what is pending. Hopefully that would encourage more people to actively contribute.
Github already has a ticket system that seems to be looked at sporadically only but which at the same time can do more than that.
Github Issues can be organized into tables or views through use of Github Projects.
https://docs.github.com/en/issues/plann ... t-projects
Any other ideas or objections?
Streamline development effort : Backlog capture and planning
Moderators: another_commander, winston
-
hiran
- Theorethicist
- Posts: 2625
- Joined: Fri Mar 26, 2021 1:39 pm
- Location: a parallel world I created for myself. Some call it a singularity...
Streamline development effort : Backlog capture and planning
Sunshine - Moonlight - Good Times - Oolite
Re: Streamline development effort : Backlog capture and planning
I can give brain dump of some ideas I have in mind not necessarily in this order and not necessarily feasible (at least from point 5 onwards):
1. Currently, I'm working on removing all downloading from happening during builds, so that once you have run the initial setup steps, you could do a build without requiring anything else to be pulled over the network. This was initially in response to another_commander's concerns about the downloading of pdfs during NSIS generation but I realised that it could be considered as a broader design philosophy. I am moving away from downloading things like linuxdeploy during builds instead setting them up in the initial setup stages. It also requires making things optional like some might not need to build the documentation so don't need to have LibreOffice or some might not care about building flatpak etc.
2. Switch Linux Clang build to be like Windows and use lld (a trivial change now I've rebuilt the JavaScript library on Linux on Ubuntu 22)
3. AnyLinux AppImage possibly built with the Flatpak builder (but separately from the Flatpak itself as requirements would probably be very different) enabling the use of the exact same library versions in both
4. Build with Meson (which has GNUstep support) or CMake (which I already got working before on Linux) and pass the Oolite version from Git rather than hardcoding them.
5. Update to SDL3
6. Update JavaScript
7. HDR on Linux
8. Get build working again on Mac
1. Currently, I'm working on removing all downloading from happening during builds, so that once you have run the initial setup steps, you could do a build without requiring anything else to be pulled over the network. This was initially in response to another_commander's concerns about the downloading of pdfs during NSIS generation but I realised that it could be considered as a broader design philosophy. I am moving away from downloading things like linuxdeploy during builds instead setting them up in the initial setup stages. It also requires making things optional like some might not need to build the documentation so don't need to have LibreOffice or some might not care about building flatpak etc.
2. Switch Linux Clang build to be like Windows and use lld (a trivial change now I've rebuilt the JavaScript library on Linux on Ubuntu 22)
3. AnyLinux AppImage possibly built with the Flatpak builder (but separately from the Flatpak itself as requirements would probably be very different) enabling the use of the exact same library versions in both
4. Build with Meson (which has GNUstep support) or CMake (which I already got working before on Linux) and pass the Oolite version from Git rather than hardcoding them.
5. Update to SDL3
6. Update JavaScript
7. HDR on Linux
8. Get build working again on Mac