If this has been abandoned by oscarpilote
OldSubSailor opened this issue · comments
Does anyone have ownership? Did he turn it over to anyone? A fearless leader perhaps?
Who can pull all this together and perhaps update what can be updated
The owner is @oscarpilote - he's still the one and only person that can manage this repo's settings including managing direct write access permissions. Judging from my last personal email correspondence with him he has abandoned public development of Ortho4XP due partly to shift in interests and also because it had become "a very heavy backpack that [he] had to wear all the time".
However, there are a number of users (including myself) that were given direct write access as contributors and which are able to commit to the repo directly (including approving and merging of open pull requests). Other users with the same privileges may include @girotobial, @artesim, @stackTom, @marcfsx, @higginsdragon @pierredavidbelanger and @jaromaz (maybe others - at least this is what I think can be concluded from the commit history).
For my part I simply lack the required in-depth Python knowledge (I only understand a small fraction of the codebase) and overall experience in managing open source projects of this magnitude - that's why so far I held myself back from approving/rejecting most open pull requests even though I would be technically allowed to...
Besides, it should be mentioned that there are numerous forks, so one possible way forward would be to jump onto the most active "bandwagon" so to speak :) See also this discussion. However, there is a high risk of increased fragmentation which would make matters worse for end users I guess...
Ok, thank you. So far the only "pythonish" fix that I know is line edit in Ortho4XP/src/04_DEM_Utils.py. That gets GDAL properly called again. Although that does not take us to a working source for 1/3", but does for 1" USGS.
https://github.com/OldSubSailor/Ortho4XP/blob/master/src/O4_DEM_Utils.py
I don't know what will happen when all those warnings stop becoming warnings and become real barriers.
@d41k4n I'd hate to see this project die. If help is needed in maintaining the repo and such, I'd be happy to lend a hand. I know my way around python and git, but haven't dug into the codebase, yet.
Also happy to help out. I've familiar with both Python and git. Just started looking through the codebase myself.
At the risk of sounding like a scratched record. It sure looks like we have a lot of smart folks on board now. I am guessing that we have a co-ordinator and things are being put together along with all the fragmentation being eliminated. I was looking at a post by @d41k4n and there looks like some machine specific things being generated out there. This I personally see to be a very bad thing, and if nothing else they should be booted to a different project and title all together.
The idea of a single downloadable file sure sounds like a great and awesome thing; however; that also sounds like a truly heavy and long term commitment.
Would hate to see this project stagnate as well. Although it is magnificent already...
@OldSubSailor I started some work on my fork. Mostly around doing some code tidying against the dev branch. I've taken a little break while I sort out my CPL. I may have some time over winter to look into this.
I don't know if this page will still be used though, as no pull requests are being merged, and it seems Oscar is no longer maintaining this repository.
@d41k4n Then someone needs to scoop/merge all this up into one pile and put up a notice sign for everyone to work out of it, dontya think? It feels like this is a bonsai tree wildly branching out all over the place. Or perhaps I have missed the merging? I have had several unplanned trips lately. It looks like 30 issues, 29 pull requests.
I also feel that Oscar " he has abandoned public development of Ortho4XP due partly to shift in interests and also because it had become "a very heavy backpack that [he] had to wear all the time"."should be convinced to turn this project completely over to another responsible person if he had walked away.
I suppose that I can close this one.
For my fork, I haven't added any improvements to Ortho4XP (except 1 minor bug fix that Oscar already merged).
My fork is basically a port of Ortho4XP to support fsx and p3d. So if the forks end up getting merged into one, I am not sure if mine should be merged in. I am fine with pulling in improvements from the main branch as I used to do when Oscar was actively developing it.
However, if the community decides they want support for fsx and p3d in the main Ortho4XP, I'm perfectly okay with merging my fork as well.
Just out of curiosity: Is anyone here besides me reading this who is able to merge PR's? If so, can you speak up please?
I had a quick look through the open PR's and while there's a few older ones that are over my head I guess I could at least merge my own with reasonable confidence (as I've tested them on my end) and maybe a couple of simpler ones with no (or little/trivial) changes to the code. But I don't want to screw things up for others or create a new baseline that's unusable and therefore it would help to get feedback on the open PR's (a simple "tested and works for me" would already be great...).
Besides, I currently don't have time to test each of them and therefore deciding which ones are keepers and how they would behave against other (newer) PR's is not something I feel terribly comfortable with doing on my own...
The only thing that I've done is tag the current head with "v1.31" as it is a few commits ahead of the "Windows binary package for v130" that was made available by Oscar via Google Drive sometime in mid-October 2018...
Hi everyone,
@d41k4n: back in the days when I was still active, he gave me the same rights as you on his repository, and I confirm that I can still merge Pull Requests.
Sorry for not speaking up until now : I haven't used X-Plane and Ortho4XP in a while, but I still have a soft spot for this project, which litterally changed the face of X-Plane.
I think that given the number of motivated people in this discussion alone, there is still hope to keep this project alive.
The mantle is heavy indeed, so I can understand that no one has really jumped in yet... but it doesn't have to be a single person.
Github has something called "Organizations". I've never used it, but from what I can gather here, an Organization is its own Github account, and just like your own account, it can host repositories.
The main advantage I see here is that the organization can have multiple owners.
So the organization repository could become the new official one (and with oscarpilote's permission, README.md could be modified in his repository to announce that, along with a post on xplane.org), and the responsibility would then be shared.
Now, this would only help with part of the problem, which is sharing the mantle's weight and ensuring that the official repository is no longer owned by a single person.
But there are currently 29 issues and 30 pull requests. And just like @d41k4n, I don't want to screw things up by merging them without testing. And I can't realistically commit to testing them all.
So my suggestion would be to introduce a dev branch alongside master (or re-introduce it, I thing we had one at some point).
The pull requests could then be merged in that branch instead of master, where it could be either fixed or reverted in case of a regression.
When the dev branch is deemed stable enough, a "release" branch could be opened where only a few last bugfixes would be committed, before being finally merged in master (and back in dev), with a new version tag.
What do you think ?
I guess that I should reopen this then.
@artesim @d41k4n @girotobial @meznak
The Organization concept sounds like a step in the right direction; and for sure a new branch would be in order regardless.
However, I still feel that it would be nice to have a person with a solid foundation in whatever the "Organization" could decide are key subject* areas as a coordinator of sorts.
Things are just too shotgunned all over the place now, but I have seen some truly great ideas out there. Ultimately, that final binary for all Operating Systems being one of them.
Just for starters, and I think that we have some already, we need experts in what?:
- Python
- Windows
- macOS: Legacy & Non-Legacy (A new version was just released) & Security
- Linux
- Homebrew
- Python Packages
- OSM
- The wonderful world of Map Graphics, complicated beyond belief
- *Github itself
- Is 1/3" for USGS ever going to be a reality again?
- For those of you who have been in them, Brainstorm group throwout question: would LISP be a better candidate than Python?
I am sure that you smart people can think of more subject areas.
Hi everyone,
@d41k4n: back in the days when I was still active, he gave me the same rights as you on his repository, and I confirm that I can still merge Pull Requests.
Sorry for not speaking up until now : I haven't used X-Plane and Ortho4XP in a while, but I still have a soft spot for this project, which litterally changed the face of X-Plane.
I think that given the number of motivated people in this discussion alone, there is still hope to keep this project alive.
The mantle is heavy indeed, so I can understand that no one has really jumped in yet... but it doesn't have to be a single person.
Github has something called "Organizations". I've never used it, but from what I can gather here, an Organization is its own Github account, and just like your own account, it can host repositories.
The main advantage I see here is that the organization can have multiple owners.
So the organization repository could become the new official one (and with oscarpilote's permission, README.md could be modified in his repository to announce that, along with a post on xplane.org), and the responsibility would then be shared.
Now, this would only help with part of the problem, which is sharing the mantle's weight and ensuring that the official repository is no longer owned by a single person.
But there are currently 29 issues and 30 pull requests. And just like @d41k4n, I don't want to screw things up by merging them without testing. And I can't realistically commit to testing them all.
So my suggestion would be to introduce a dev branch alongside master (or re-introduce it, I thing we had one at some point).
The pull requests could then be merged in that branch instead of master, where it could be either fixed or reverted in case of a regression.
When the dev branch is deemed stable enough, a "release" branch could be opened where only a few last bugfixes would be committed, before being finally merged in master (and back in dev), with a new version tag.
What do you think ?
An organisation does sound like the right approach. I'm happy to help set that up if needed.
Well, I went ahead and created one, just so you can see how it works, what you can do with it... in short, so you can see if it's the right answer or not :)
I invited you as owners, but you should be able to leave at any time if you want (there is also a "member" role where you can still contribute to the code).
Things are just too shotgunned all over the place now
Have a look at the "projects" tab, I created two kanban that we could use for triaging issues, and organizing the feature pull requests.
Edit: better with the link : https://github.com/orgs/Ortho4XP
@artesim @d41k4n @girotobial @meznak The Organization concept sounds like a step in the right direction; and for sure a new branch would be in order regardless. However, I still feel that it would be nice to have a person with a solid foundation in whatever the "Organization" could decide are key subject* areas as a coordinator of sorts. Things are just too shotgunned all over the place now, but I have seen some truly great ideas out there. Ultimately, that final binary for all Operating Systems being one of them. Just for starters, and I think that we have some already, we need experts in what?:
snip
I am sure that you smart people can think of more subject areas.
I think out of that list the most important ones are
- Python, as this is what the bulk of the logic is written in. This should include packaging to binaries.
- OSM and map graphics, obviously this is what the program mains feature is. (I'm working through learning this atm).
- C, there are a couple of key modules written in C that Ortho4XP [seems to] depends on.
- Github
I quite like the roadmap that @artesim has laid out. Along with setting up the Organisation and updating this repo, I think we should focus intially on:
- Getting any warnings and errors fixed against the current master branch. Even if this is not ideal it would get a working version out there.
- Recovering the dev branch, there is a lot of good work in there which would be a shame if we lost.
- Code cleanup, there is a lot of janky code in there right now. E.g bare excepts, that could be masking issues. Along with bringing the code format more line with Python standards
- Getting any warnings and errors fixed against the current master branch. Even if this is not ideal it would get a working version out there.
- Code cleanup, there is a lot of janky code in there right now. E.g bare excepts, that could be masking issues. Along with bringing the code format more line with Python standards
Yes, and yes. I had a look at your repo earlier, and I can see that you already started to scratch that same itch I had when I last worked on the code :) For what it's worth, on other projects I use pycharm and its builtin code inspector, and the "reformat" function. The only thing I disregard completely in PEP8 is the line width (80 column is an outdated requirement IMHO).
=> this could make for a couple of new cards in the kanban, if you want to add them
I would add one more subject to your cleanup list : separating the "core" code from the GUI stuff, but I'd say it slightly lower priority compared to getting the project started again.
For those of you who have been in them, Brainstorm group throwout question: would LISP be a better candidate than Python?
I've played a lot with Common Lisp : it was more than a decade ago but I don't think the situation has changed much. IMHO, it's a beautiful language but it was nowhere near Python in terms of available libraries. And this would mean a complete rewrite... So I'm pretty sure it's not the right way to go, but it's cool to see Lisp still mentioned today :)
Apart from that, I agree with your list of skills, and I would add one more : tkinter (the currently used GUI toolkit) (or maybe wxWidget or Qt if someone wants to have a go at modernizing it, but let's not digress too much...).
Yes, and yes. I had a look at your repo earlier, and I can see that you already started to scratch that same itch I had when I last worked on the code :) For what it's worth, on other projects I use pycharm and its builtin code inspector, and the "reformat" function. The only thing I disregard completely in PEP8 is the line width (80 column is an outdated requirement IMHO).
this could make for a couple of new cards in the kanban, if you want to add them
I will be adding them, by default I use the black formatter which defaults to 88 per line. I'm not too fussed re: line length as long as it's consistent (and not really long).
We could setup a pre-commit hook and CI to monitor for formatting / linting.
I would add one more subject to your cleanup list : separating the "core" code from the GUI stuff, but I'd say it slightly
lower priority compared to getting the project started again.
Yes yes yes and yes, that and the config. The config is driving my crazy atm with how much it is hooked into everything, and make the application import order dependant.
Maybe we could use PySimpleGUI to help with the UI issues. I'm also fairly happy with QT
I just piddled (copied into BBEdit, saved as a .py file and ran it) with one of the Interactive Window samples from the PySimpleGUI. Very interesting.
I wonder why PEP8 remains so firm on the 80 column requirement? I tried looking it up, and saw things about monitors, printers, readability on one line etc. Actually, I could see that justification. I mean heck I don't like turning my head all the way around like someone in the Exorcist to read a line of text.
I know that PyCharm flags it, but if memory serves, they actually set their limit at 120 or so and call it a PEP 8 violation. I kinda jumped them and asked them to either set the limit at 80 if they are gonna call it a PEP8 or else call it a PyCharm violation. It stirred the pot.
I am trying to learn Python in an effort to understand what you folks are saying and doing, among other things. I started with PyCharm, but now it seems for learning, an IDE is not the way to go.
This all sounds great - creating the Ortho4XP org is a great idea - as is the reviving of a dev branch where we can try out stuff without the fear of breaking the master branch... I'm really happy this is starting to move along!
Although my time is severely limited I will try to help where I can. It seems I already have a lot of catch up to do regarding the possibilities Github offers for managing cases like this...
Hi all,
After changing my Github e-mail to something I really use lately I started receiving quite a number of notifications...
Abandoned may be exagerated, although it is true that I haven't touched X-Plane and/or Ortho4XP for quite some time now.
In my dreamed world it would have continued it's life like a child after leaving the family nest. I'm glad it happens!
For that reason there are two things that I can certainly do if it helps:
- give further write permissions to this repo (but if there's a community repo I will consider it the official one now and would gladly delete mine if it may avoid confusion).
- give some insights to some math parts of the code (given that the comments in the source files are somewhat lacking... actually I'd better do taking care of those first).
My main interest in the project as always been the meshing part, and I sort of pushed it as much as I could given the static nature of X-Plane's mesh. A key step that would open a new play ground would be a dynamic multi resolution mesh (one that Laminar could easily fit into their own code base, which probably means one that they would adopt for their own).
Hi !
Well, I for one, am not that much into math, so I wouldn't be able to help the community in that regard :)
As for the community repo, it's still just a suggestion but the idea seems to have been well received so far, and could be a good place to organize future evolutions (I'm thinking about the project tab, which could help managing pull requests and bug reports).
The only thing missing is a place for the kind of discussion we have here : the xplane.org forum seems better suited for that... and by the way... maybe we should continue this discussion there ? ;-)
Anyway, nice to read you !
@oscarpilote Glad you are back 😄
2. give some insights to some math parts of the code (given that the comments in the source files are somewhat lacking... actually I'd better do taking care of those first).
I would leave this up, purely because all the existing releases reference this repository. Just change the README.md to point to the new repository.
Hi !
Well, I for one, am not that much into math, so I wouldn't be able to help the community in that regard :) As for the community repo, it's still just a suggestion but the idea seems to have been well received so far, and could be a good place to organize future evolutions (I'm thinking about the project tab, which could help managing pull requests and bug reports).
The only thing missing is a place for the kind of discussion we have here : the xplane.org forum seems better suited for that... and by the way... maybe we should continue this discussion there ? ;-)
Anyway, nice to read you !
I've created a discussions page for the new repo here It should serve nicely as a forum. We can use the X-Plane forum as well. I would anticipate the discussions page would be more orientated towards development topics.
The only thing missing is a place for the kind of discussion we have here
Ok, the only thing missing are my glasses, apparently :)
I AM NOW WEARING MY GLASSES DISCUSSIONS HERE
we can forget about X-Plane Forums then, if we can't get a private topic area. I have macOS instal instruction topic and it has been a true pain with regard to no one wanting to actually read the instructions completely etc.
Like everyone else in the world, I was looking up whether O4XP did already get the necessary XP12 changes. The most relevant org-Forum thread regarding this issue[1] leaves people in the open basically hoping that @oscarpilote will just deliver at some point. Now to me it is quite obvious that @oscarpilote`s focus has shifted during the last years (no criticism, pretty much all dev's including me do this all the time).
Now when coming into this GitHub repo, it look "somewhat active" because 20 or so PRs were merged in September. On the other side this very thread here kind of confirms that in fact this Repo is somewhat abandoned given @oscarpilote`s post and the Repository+Org which @artesim started at https://github.com/Ortho4XP/Ortho4XP. As far as I can tell the fork has had a phase with considerable work done as in refactoring and using GitHub features like discussions and actual feature issues etc, but activity also ceased at some point.
So that is the state I found when looking into the current state of O4XP. I did not check any of the other forks but I assume other people looking for a XP12 fork will eventually come up at the same conclusion.
Given that O4XP is a hugely popular tool for XP I have no doubt that a XP12 version will come up eventually, but I see some problems with the current situation:
- It is not clear whether @oscarpilote will actually work on the necessary XP12 changes. Other people just starting on their own might lead to duplicate or even conflicting work. This should be transparent and somewhat coordinated
- The fork over at @artesim's repo has received refactoring and all work based on this original codebase will need extra work for merging.
If @artesim's fork is actually in better shape than this original repo, all further work should go there and this repo should go into the GitHub archive mode. Usually a last commit is done which explains the situation and points to the successor Repo via the README.md. The 20s or so PR which got merged in September would need to be merged into the fork. This might be quite some work.
[1] https://forums.x-plane.org/index.php?/forums/topic/268914-updating-existing-ortho-for-xp12/&page=3
FYI Oscar's last public statement can be found here:
https://forums.x-plane.org/index.php?/forums/topic/268914-updating-existing-ortho-for-xp12/&do=findComment&comment=2417062
@maxhille for the most part development on artesim's fork has come to a halt partly, due to my lack of time. Partly because the code base is clearly quite organic having grown from a colleciton of script files. The downside is it can be hard to seperate responsibilities in the code, which can make it tougher to refactor. (For example the config is dependant on all other modules being loaded first).
In addition there is a steep learning curve about rasterization and a heavy dependency on triangle.c which is not a language I'm well versed in.
If Oscar is making compatibility for XP12, it may be better to wait and see what changes happen first.