I don't have the stone of ultimate wisdom, so these are just my thoughts.
Csantucci, on 08 December 2021 - 01:58 AM, said:
- thanks to the support of Peter, yesterday I could merge into the official OR version the Distributed Power feature, because there was an approved blueprint for it; this is an example that, when possible and simple and fast, features migrate to the official OR
- at the moment I have three unapproved blueprints for features already present in ORNYMG (2D-cabview controls for side views, cabview controls for generic items and multiple screen pages); I could read a general statement suggesting not to proceed with official PRs before the related blueprints were approved
One might interpret this rule a bit differently too: The PR could be filed in a Draft state regardless whether the blueprint is approved: this way we would be one step closer to the goal. And when the blueprint is approved, the Draft flag can be removed. My comprehension is that the above rule/statement's goal is to possibly prevent people from doing unnecessary coding work by working on a feature not willing to be approved. But for existing coded features you are not doing anything wrong with filing the PR, in my opinion. And there will be the big forefinger in the form of the PR for the approvers, to do the approving work. This might be a possible speed-up in my opinion.
Csantucci, on 08 December 2021 - 01:58 AM, said:
- some features present in ORNYMG have been fully developed by other people, and IMHO it's more appropriate if the blueprint and the following PR are managed by them
Probably the coders of these features are satisfied with their code is included to your release, and they think they are done. This is absolutely not your fault. However, because the code flows through your fingers, you might have an opportunity to intervene in the future to move things into the right direction ( – provided that you also think this kind of thing is currently moving into the wrong direction). You might set a condition to the coders, that you are not willing to include their code changes into your distribution until they file a PR into the official version as well (as draft), no matter how tempting their code changes are. And with this we have traced this point back to the previous, the approval one. (Not sure what to do with the existing changes though, probably it might be worth to go back to the original authors to ask to file the PR, and if they refuse, we must do the work by ourselves. I don't see any other way.)
Csantucci, on 08 December 2021 - 01:58 AM, said:
- someone has declared he would cope with the development of an official 64 bit OR
Honestly, this is unclear to me too. I think all of us have a 64 bit version already. I also have made the necessary changes privatly on my own version to run OR on 64 bit dotnet core YEARS ago (minus winforms, but now that also works, so is out of picture). All of the "forks" are running 64 bit, what holds the official version back?
Csantucci, on 08 December 2021 - 01:58 AM, said:
- some features aren't accepted in the official OR
Are they useful, technically correct, but despite of this not accepted? I think a list would be good of these to double-check, if they are really important.
Csantucci, on 08 December 2021 - 01:58 AM, said:
- approval times for blueprints and PRs are often not very fast
- Cruise Control is a particular case: it has been developed by Jindrich, which has then gone his own way with the czech-slowak OR fork. Basing on his work, I have expanded the feature to cope with further real cases, leaving structure and hearth unaltered; so it's me that could generate a blueprint and a PR for the official OR; however there have been cases where I had to spend significant time modifying code and retesting to get approval for the official OR, and I am not a person who likes rewriting things that work; therefore I am rather reluctant to enter the official approval path for this feature, also because maybe it hasn't an architecture and an implementation that match with the OR standards; if however official reviewers examine the actual ORNYMG code for Cruise Control and declare a committment to approve it, I can proceed in migrating that feature.
I think a PR of this would be good to see of this too, because otherwise there is nothing specific there to talk about. Given that the original developers are – let's say – not here anymore, it won't change much. And Github provides a good platform for discussing the code even line-by-line, if necessary. Pointing on what's wrong.
I think something should be changed, because there is a chance that the ship beside the dolphin swims just gets smaller and smaller, until it is not visible at all. And when also the dolphin bores swimming, there will be nothing just the sea.
Log In
Register Now!
Help
