Talk:FGAddon

Templates instead of explicit URLs

Moved here from FlightGear wiki:Village pump#Repository link templates (perm).

The FGAddon article could greatly benefit from being reviewed with a focus on getting rid of/generalizing explicit URLs (or even git instructions) in favor of using templates that encapsulate any URL/git specifics, so that things can be more easily updated in the future. --Hooray (talk) 03:01, 20 September 2015 (EDT)

Is there a listing or category page for such templates? I haven't found where these are collected, and cannot find the relevant template. The SF URLs are very diverse in this article, e.g.:

svn+ssh://<username>@svn.code.sf.net/p/flightgear/fgaddon/trunk/Aircraft/
svn+ssh://<username>@svn.code.sf.net/p/flightgear/fgaddon/trunk/Aircraft/DaSH
svn+ssh://<username>@svn.code.sf.net/p/flightgear/fgaddon/trunk/Aircraft/<aircraft>
https://svn.code.sf.net/p/flightgear/fgaddon/trunk/Aircraft/
https://svn.code.sf.net/p/flightgear/fgaddon/trunk/Aircraft/DaSH
https://svn.code.sf.net/p/flightgear/fgaddon/trunk/Aircraft/<aircraft>
https://sourceforge.net/u/<username>/profile/
https://sourceforge.net/u/<username>/code-fkdr1/ci/master/tree/
ssh://<username>@git.code.sf.net/u/<username>/code-<aircraft>
https://sourceforge.net/u/<username>/code-<aircraft>/ci/master/tree
ssh://<username>@git.code.sf.net/u/<username>/code-ornithopter
https://sourceforge.net/u/<username>/code-ornithopter/ci/master/tree/
ssh://<username>@git.code.sf.net/u/<username_leader>/code-ornithopter

Some of these URLs are highly specific to the very detailed and reqired instructions on the page. The parts in angular brackets <> should be presented in these brackets on the page to indicate that the reader replaces it with the relevant value. So these are not followable URLs anyway. And can templates be used in the <syntaxhighlight> tags? Note that none of these are for the SF web interface, for which all the templates I've seen so far are for.

Bugman (talk) 13:58, 27 October 2015 (EDT)

The idea can be seen at [1] - i.e. originally, we were hoping to grow a library of templates that can be parameterized, not just in terms of "actions" (clone, update/pull, push etc), but also in front-end terms - e.g. by adding screen shots for different front-ends and dynamically showing the matching UI front-end (or shell instructions). ::: The whole thing was inspired by the discussion at Talk:Development Workflow. For instance, for NetBeans:

git pull via NetBeans

--Hooray (talk) 14:05, 27 October 2015 (EDT)

In an abstract way, I can see how this would be useful. In a concrete way - i.e. the fine details of how this should be implemented - I cannot see this yet. I need some time to think about it. The main issue is that the exact commands to type, which are essential and without which the article cannot function, are very much specific to the prompt UI of svn, git, and git-svn. Each GUI does this differently, packaging a number of the commands into one menu entry or button. I think for this task that the GUI diversity is insane, and we cannot provide full coverage, and that the major focus of the article should be the command line.

For URL templates, some of these may have a slight advantage. However look at history - of the Gitoriuos to SF transition. If we had had Gitorious templates, these and there surrounding instructions would be hopelessly out of date and nothing could be done in the template to fix it. The fixing action would be to search for all instances in the wiki and replace, and this would be the same amount of work with or without the template. The other situation where a template would be useful is if the SF url changes. However this might require a template change and search+fix all instances anyway. Also the SF urls are pretty much fixed in stone and very unlikely to change. So template+template usage costs may be higher than pure command+url usage. From a pure cost analysis perspective, I'm not convinced of the benefit yet.

Bugman (talk) 11:22, 28 October 2015 (EDT)

Let me add, that for that long list of specific SF URLs above, that 0% of these are covered by the current {{repo link}} template.

Bugman (talk) 11:55, 28 October 2015 (EDT)

History of the fgdata split

Hooray, I would prefer not to have the following changes:

• http://wiki.flightgear.org/index.php?title=FGAddon&diff=98220&oldid=98157
• http://wiki.flightgear.org/index.php?title=FGAddon&diff=98222&oldid=98221
• http://wiki.flightgear.org/index.php?title=FGAddon&diff=98223&oldid=98222

Firstly, any mention of FGMEMBERS is irrelevant to FGAddon. Ok, they wish to slaughter FGAddon, but that has zero business in this article. Secondly a lot of the introduced text is a repetition of what is already there. Look at your text where you are quoting my statements about Gijs, and then look at the next paragraph that says "A first splitting attempt was organised by Gijs de Rooy and announced on October 18, 2011". I didn't mention Cedric, but he is listed in the reference at the bottom of the page. But the quote is an almost perfect doubling up of the text - the quote origin is essentially quoting from here, and that is now coming back. As for Curt's quote, this is justifying why SourceForge was used, in the context of FGMEMBERS attacks. I think my original sentence "Other parts of the FlightGear infrastructure were already hosted by SourceForge, making the move a natural one." is sufficient and a positive outlook on the subject, as it is and should be seen. This history section is about presenting the facts. The excessive justifications demanded from the FlightGear community by FGMEMBERS does not in any way belong in here! All of the facts are from long before FGMEMBERS came into existence.

Bugman (talk) 09:22, 14 May 2016 (EDT)

You are free to review/edit and revert the corresponding additions, like I said, they were not intended to stay "as is". However, the history section is currently incomplete anyway, and that "fgmembers" ended up in it, is merely because I took your quote ;-) The current forum debate illustrates that it does make sense to mention that we've had other attempts, and that they failed. Anyway, feel free to revert. I just think that the history section could have the potential to explain things that people ask about on the forum - even without mentioning fgmembers specifically.--Hooray (talk) 09:38, 14 May 2016 (EDT)

It's already all there. For example:

• Original: A first splitting attempt was organised by Gijs de Rooy and announced on October 18, 2011[9]. Each aircraft was placed in its own Git repository and all aircraft linked back to fgdata using a Git submodule approach. However this attempt failed and was abandoned. From this date until the end of 2014, the design of the fgdata split was discussed on the development mailing list and summarised in the FlightGear Git: splitting fgdata wiki article. In the planning stages, the repositories were known as fgdata-old splitting into FGData (a.k.a. fgdata-new) and FGAddon (a.k.a. flightgear-aircraft and fgaircraft). After half a decade of planning, it was decided that the best solution for FlightGear aircraft development would be a single centralized Subversion repository. This would facilitate community management and maintenance of the aircraft while at the same time providing modularity and smaller downloads and smaller local repository sizes.

• New addition: Back in Oct 2011, the group decided to go with the git submodule approach, as lead by Gijs. However Gijs found a number of fatal issues with the approach, the exact same issues are actually currently found in the FGMEMBERS aircraft repositories, and there were enough voices on the list to stop with the git submodules and to search for an alternative, that ended up being SVN. Cedric was obviously not happy after spending so much effort on creating the full git submodule system with one repository per aircraft[7] - a system identical to the FGMEMBERS aircraft repositories.[8]

Cedric is the first name in reference 9, so apart from the mention of FGMEMBERS, the two pieces of text say exactly the same thing. This is not coincidence ;) A duplication is confusing, and the second piece of text is just one of many regurgitations of the history that FGMEMBERS proponents repetitively and incessantly ask for (to somehow try to slaughter FGAddon). For the second addition:

• The short summary is that we already were maintaining a well established presence on sourceforge. So after quite a bit of discussion, we decided to consolidate there. In addition, we had a perpetual complaint that the fgdata git repository was far too big for most people to initially download (1Gb+). Thus we split off most of the aircraft (expecting unbounded future growth potential) into an svn repository called fgaddon. Sourceforge supports both git and svn repositories. This puts a dependency on a central svn server for our fgaddon aircraft repository, but lightens the weight for anyone wanting to checkout a copy of everything (you don't need a copy of the entire development history, and a copy of every version ever created of every aircraft if you just want to have the latest versions.) Plus svn allows checking out subtrees (without needing the whole repository) so this can also serve as a potential JIT single aircraft service provider. Of course there are always multiple ways to solve every problem and of course every engineering decision has trade offs. Github is a nice provider, no doubt.[10]

This too is repetitive and long. For example sentence 1 is covered by "Other parts of the FlightGear infrastructure were already hosted by SourceForge...". Sentence 3 is the early text "...the fgdata repository mushroomed...". The lightening the weight might be useful, but as a few words at the point where the split is first mentioned. I'll revert, but see if there are a few small things that can be added without this having to look like an attempt to justify the right for FGAddon to exist. And I'll try to keep this light, as needed for a 20 year summary of all the FlightGear asset history.

Bugman (talk) 11:32, 14 May 2016 (EDT)

Request for “Contributing” section

The page deals with using, and then with developing aircraft. But there is a very important middle-ground: people who like to fly this for a bit and then that for a bit, find issues and want to report those issues and possibly have a simple patch worth a couple of lines to fix it. Such people (like me) are not really interested in setting up development branches nor getting commit access. They just need:

1. A documented, on this page and the sourceforge project page, and reasonably simple way to report those issues that is preferably:
   1. Consistent across all the aircraft. I.e. it shouldn't be this email for one aircraft, that forum thread for second and another github repo for third. If that is the status quo and can't be improved on, at least there should be one place where the correct way for each aircraft could be found: not all aircraft have wiki pages, not all have README, etc.
   2. With public record. Bug tracker is best, but forum or mailing list are fine as long as it does not depend on one maintainer who might have gone MIA without anyone noticing.
2. Similarly documented best practice how to prepare and send patches to maximise the chance that the repository maintainers will accept and merge them.

Would anybody please be able to add that info before the [Aircraft development] section? Or at least give me hint where to find such information so I could copy it over here?

Thanks

Note: This is, for me, benefit of the FGMEMBERS—it is clear that the appropriate channel is the github issue tracker for each aircraft. However I worked in many settings and don't mind the particulars. Whatever works for the core team is fine be it a mailing list, forum or whatever kind of tracker. It just needs to be obvious and in case of FGAddon (and to large extent FlightGear itself too) it never was to me.

—JanHudec (talk) 10:03, 26 July 2016 (EDT)

This is a fair point - I'll add some information about the FlightGear tracker - https://sourceforge.net/p/flightgear/codetickets/?source=navbar - for posting patches, files, etc.

Note though that this is complex because of how the FGAddon repository is used. A large number (likely >75%) of aircraft are managed and developed in external 3rd party hangars. That is why the most important point is to contact the original author (FGAddon#Contact the original aircraft authors). For example the Helijah hangar consists of 275+ actively maintained aircraft in FGAddon. For these it is best to directly contact Emmanuel rather than use the tracker. The same goes with many other aircraft - simply contact the original author. Anyway, you'll be told if you use that FG tracker for an actively maintained aircraft to go to the original source.

Bugman (talk) 10:33, 26 July 2016 (EDT)

It would be great if the maintainers could be, gradually, persuaded to use a common tracker. It would make it easier for others to contribute. But obviously it's not gonna change overnight (I guess that's big part of the reason FGMEMBERS don't work). Documenting the status quo is an important first step. Thank you.

—JanHudec (talk) 10:44, 26 July 2016 (EDT)

It also depends on the motivation of the original authors. Again for example take a look at the Helijah hangar: http://helijah.free.fr/flightgear/hangar.htm. For Emmanuel, it is a lot of work to actively follow a tracker for 275+ aircraft. A simple email or post on his dedicated forum - http://embaranger.free.fr/ - is more efficient for him, and is his preferred way of working. I am specifically redesigning the {{infobox aircraft}} template to help direct potential contributors to the correct original source.

Bugman (talk) 11:00, 26 July 2016 (EDT)

That's great too. Unfortunately of the 275+ aircraft (to continue that example), the Category:Helijah hangar only has 22…

Also, good tracker, when properly configured, is easy to follow: when the component (aircraft) is correctly filled in, it should send notification to the respective maintainer and it should provide the maintainer an overview of outstanding issue in the components (aircraft) they maintain. But I understand it's not easy to change one's habits.

—JanHudec (talk) 11:18, 26 July 2016 (EDT)

If you look at the recent wiki history (Special:RecentChanges), you'll see that I'm in the process of converting the 486 aircraft pages to the new template. This is no easy task! Have a look at the Category:Unknown hangar at Category:Aircraft by hangar to get an idea. Also a lot in Category:FGAddon hangar still have to be tagged with the 'devel-hangar' parameter to categorize all those external hangars hosted within FGAddon.

For the tracker, you can assign an "owner", and everyone with current FGAddon access is listed (a number of authors are still to sign up, but they have effectively retired). Many authors for the external hangars in FGAddon however prefer direct contact.

Bugman (talk) 11:50, 26 July 2016 (EDT)

Launcher?

Hi, i tought that the launcher also downloads from the version-tagged fgaddon tree?

Should the page be revised in this regards?

Correct! For quite a while now actually... Please go ahead and update the Obtaining aircraft section.

Gijs (talk) 09:09, 28 July 2023 (UTC)