I don't think it's a good idea to add old issues to the project board. It will just create a lot of noise. I think the original 20 issues are more than enough to occupy the current dev team for years to come so little point in adding things that no one will have any time to look at unless you're putting yourself forward to go through all those old PRs and test them (eg. the FOV one is from 2015 and the code has changed since then).
I cannot even tell if a merge is reasonable, yet test if all would still work with the merge.
Also I do not want to get everything merged blindly, but I'd like to have an educated response on the PRs, even if we reject them. And I will need help on that.
If it works out, we'd be more managing community-provided PRs that developing our own.
I can't tell either. Some of them seem to have discussions about them already, but then progress stopped. All you could do is invite the original author to bring it up to date.
I guess this is as good a time as any to let you know that I will be taking a break from coding. With 1.92.1 out of the way and the project rolling nicely, this is a good opportunity for me to unplug for a while as I have done already a few times after similar milestones in the past. Not going away, I am still around and can still provide help if there are questions about stuff I am familiar with, but will just be mostly inactive.and follow from a bit further away as time permits. I also won't be reviewing PRs as this is a sure-fire way to not be able to relax.
I agree with first and closed it with comment "Agreed, also if we support Mac in future, the XCode project would be generated from Meson or CMake so any settings would go in the corresponding configuration file not directly in XCode."
The second, I don't know as I haven't looked at the js code before.
I can't tell either. Some of them seem to have discussions about them already, but then progress stopped. All you could do is invite the original author to bring it up to date.
I agree. #557 is a good example. Since we never saw it build successfully and assume it was never tested such a PR should not go to our master branch.
Either we run it towards a separate feature branch or merge to master, then do some branching magic to make it appear on a feature branch. When tested to satisfaction we can still merge.
It feels wrong to have to destroy an abandoned ship just to be awarded the kill.
EDIT :
the 2 commits from #378 apply cleanly to master, but give a warning and an error when compiling .
Posted in the PR.
Thank you for checking the build. I guess no-one has checked whether Oolite is changed in the way announced and in no other way.
How can we achieve that? I would not like this to go into master without being tested.
I guess this is as good a time as any to let you know that I will be taking a break from coding. With 1.92.1 out of the way and the project rolling nicely, this is a good opportunity for me to unplug for a while as I have done already a few times after similar milestones in the past. Not going away, I am still around and can still provide help if there are questions about stuff I am familiar with, but will just be mostly inactive.and follow from a bit further away as time permits. I also won't be reviewing PRs as this is a sure-fire way to not be able to relax.
Keep going strong fellas.
Have a good break and well done for getting the Windows Store version out!
