cain071546 wrote in Tue Sep 15, 2015 3:05 am:this doesn't make sense to me.
so we all know the core developers job can be hard, but they are the reason that Flightgear is here today, i respect that alot.
I don't know how hard it is. But it certainly requires intimate knowledge of the code and all its components. The project is large and complex, full of sub-routines, and dependencies. I personally don't understand core development of flightgear, even thou I had glazed over the source code, so others are more fit to enter in this topics if needed. We both respect that a lot. The most important thing is how the software had largely improved on the last releases, and continues an steady increase. Furthermore it is alone in the landscape of free flight simulators that are truly openSource [* or is it?]. (XPlane people will excuse my opinion here, I guess!)
if they are so concerned with what goes into FGADDON then why do they still have lots of low quality models in the repo?
FGADDon inherited every aircraft previously existing on the FGDATA git repositories that existed in Gitorious until FG 3.2
Quality was not considered as a limit of exclusion for these.
Quality is, again, a new parameter of inclusion; and apparently, new aircrafts need to prove themselves worthy of the collection -- with this probably meaning they have to be better than the bunch.
Keep in mind thou it is a matter of classes. (Classes of people, off course). FGADDon commiters could easily add a new aircraft. They don't need votes or agreements. So, inclusion of both code and
full aircrafts by a committer goes easy; almost unchecked. For people without commit priviledges, that seems not to be the case. New contributions go via the devel list where they can end up sparking a series of controversies, and be rejected unless a certain set of criteria are met. Think of HerbyW Antonovs series, which by the way are much better than most FG aircrafts!! Sure, they were spun off Helijah's Aircrafts, and thus it became hard to understand why allow a new aircraft when another variant of the aircraft (much undeveloped) existed.
Similar fate suffered by Herby's spun on the Shuttle, which faced heavy competition by Thorsten and his group, and with a similar fatal fate. The contributions as new aircrafts did not meet an unexplained quality value. While other aircrafts brake the unknown quality thresholds and either come in (dhc6, b788) or get scheduled for inclusion (crj700).
Finally,
more directly addressing your question (again, purely my perspective) -- it is very hard to decide an aircraft is of an unmet quality and send it to the "Attic". How to judge an aircraft is tipically subjective, and determining thresholds very complex. Again, active maintainers could not only block contributions to certain un-impressive aircraft, but also be very jealous of letting their beauties go. And how they say in the devel list, aircrafts can be very useless for some, but great treasures for others.
All together, I do not say the core developers letting go a set of aircraft under pretenses of low quality. And we all are aware that some of those aircraft qualities are very far from the best of the lot.
why not unload all the low quality models onto FGMEMBERS?
They are already there!
Every aircraft in FGADDon also exists in FGMEMBERS!And some of the low quality ones, have a few commits that make them more useable in their FGMEMBERS' variant! So in certain cases, the FGMEMBERS' version is already arguably better and more functional.
This happens thanks to the fact that so much more contributors have an easier path to fix bugs. And the fact that contributors find a more expedite way to feel themselves of use to the project.
I can ease your worry thou that a low quality aircraft in FG is an excelsior in FGMEMBERS. We don't have those
. We just have them a little less worse.
it would decrease the number and size of files in FGADDON making it easier to maintain, they would have 20-30 of the best models to include in future FG releases.
That's a cold-ice hardcore threshold :S
besides, why would the core developers rely on aircraft maintainance elsewhere (?!)
if one of the devs wants a model added to FGADDON then it should be just as hard for them and should be of the same very high quality ie: f-14/a-10/777/cap10b/cub ect.
Truly, other users, such as Vincent KL666 also have your same point of view, that FGADDon should really honor the guarantee that is the collection of La creme de la creme of aircrafts for Flightgear. I just find hard to judge who honors inclusion in such conditions.
otherwise why cant we (devs and community members) just work out of FGMEMBERS until it becomes apparent that the model should be added to FGADDON?
This is the really hard pressing question. Why can't we just work on FGMEMBERS and enjoy FG, and share planes, and enjoy a platform that allows us to modify aircrafts and have fun with them; while learning a lot and creating community?
Why there has to be Official Rejection, or Consider that Officially we should be limited to enjoy FG in this new way [*within the Official infrastructure such as the Wiki and the Forum]?
Who said we had to fly the aircraft as officially made, and we can't use the GPL license to modify them, and experiment them [* and easily distribute our variants]?
Why if we, as a community, enjoy of this, we had to be made prey of prosecution, and aggressions, of core developers that have to come every day with the same repeated
you are not official storyline?
That is, I repeat, a really hard pressing question!
if the original author wants to LOCK access to an aircraft why not let them?
many of the authors also have the original version on their own websites/hangars
just fork it, but please rename it so i can have both installed!
That's the point. An author can fork the aircraft and manage his own fork as he seems fit. He can Lock access to every contribution as he seems fit, or allow openly the community to share and collaborate development. Currently, FGMEMBERS fork (repo) is open access to any "Member" as they have push access to the repo.
Github platform make completely possible to organize a very granular push access control on individual repositories to subgroups called teams. FGMEMBERS has about 18 teams. But not a central coordination to determine which team
"owns" the write priviledges of any of the repositories. So, Yes, it is possilbe. No, currently we don't operate that way.
that's all my ideas.
Kuddos
IH-COL
If we gave everybody in the World free software today, but we failed to teach them about the four freedoms, five years from now, would they still have it? Probably not, because if they don’t recognise their freedoms, they’ll let their freedoms fall