Howto talk:Start core development

From FlightGear wiki
Jump to navigation Jump to search

Open questions

  • merge requests (post follow-up to mailing list and file review via issue tracker)

Planned improvements

  • navigating the source trees (FG + SG)
  • FG entry point (bootstrap.cxx)
  • the FG main loop
  • FG subsystems
  • adding new fgcommands
  • adding new network protocols
  • adding new telnet/props commands
  • adding new startup options (options.cxx)
  • adding new subsystems
  • networking
  • scripting
  • GUI code
  • instruments
  • list of FG related projects (URLs, type of software)
  • list of FG related websites
  • list of FG related people (i.e. developers)
  • gdb, valgrind, gprof, gcov

Use of "repo" links in wiki pages.

I'm not sure there's much advantage to using the "repo" link system. It's an abstraction that protects us against something that happens extremely rarely (changing of the main git repositories) at the cost of an obscure macro-like thing in the wiki text. Personally i'm with the Python philosophy of "Explicit is better than implicit" in this case. Apart from anything else, the most likely change to repositories is not a simple move to different location, but a merging of flightgear and simgear into a single repository, for which the repo macro is useless. Cgdae (talk) 10:34, 22 November 2020 (EST)

It was agreed on by the people involved in updating the wiki after the last migration, and given that another migration is currently being discussed, it might not be such a bad idea. I do think that the existing macros could be adapted to reflect a merged repository (if the need arises). If in doubt, Johan and bugman were primarily involved in establishing these "link templates", but it seemed other wiki admins were also convinced it's a good idea, here's the original context: http://wiki.flightgear.org/index.php?title=FlightGear_wiki:Village_pump&oldid=87148#Repository_link_templates --Hooray (talk) 11:09, 22 November 2020 (EST)
I manually did the large part of that migration myself. The pain is insane! The changes could not be scripted - my attempts ended in a large proportion of dead links. There is too much variability and redundancy in the PHP query strings. I dealt with something like 5000 dead gitorious links manually, one by one. It took me weeks, and innumerable hours of work. If there is another infrastructure change, now with the {{repo link}} family of templates I can migrate all of those 5000 links within seconds. Or if SourceForge, GitHub, GitLab, or the Gitorious archive change their URLs or PHP query string interface, I can fix all links within a single location. In 20 years we will still have the wiki and we would probably have gone through one or two infrastructure migrations, just as we have been through 3 different infrastructures in the previous 20 years (Curt's CVS server, Gitorious, and SourceForge). So there is a very big advantage for the long term viability of the wiki.
A merged repository is also no problem for these templates. Just as I experimented with creating that merged repository, I also looked into what is required for the templates, and this is trivial (either for a merged repository, a submodule, or a subtree).
Bugman (talk) 16:32, 22 November 2020 (EST)
Agreed, I am entirely with bugman on this ...wiki admins (and hosting providers) come and go, but we don't really have many people interested in doing such tedious work. In fact, I wish there were more people with the privileges that Simon and Gijs have, so this mediawiki installation itself could be better maintained here. For instance, these template are enormously helpful, but obviously it could really go a long way if such helper templates were properly integrated in the WYSIWYG editor/interface - this, and many similar requests have been made over the years, but were rarely implemented by our server admins. Thus, templates like these are a compromise obviously, but I'd rather use these than have no option at all. So, thank you bugman for all your work here !! --Hooray (talk) 16:40, 22 November 2020 (EST)