On 09/09/09 06:16, Tim Moore wrote: >>> Yes, the 2009 code is different from the 2007 code. >>> The 2009 features and bugfixes are a superset of the >>> 2007 features and bugfixes. Also the 2009 commits >>> were rebased so that they applied cleanly to the FGFS >>> release that was current at the time. >>> >> That's great! What's the url for the repository that has these changes? >> Unless I'm doing something wrong, it seems like >> http://www.av8n.com/repo/fgs/.git >> and http://www.av8n.com/repo/sg/.git haven't been updated in some >> time.
I updated that site just now. I had stopped using it more than two years ago, because it is just a fileserver (lots of network connectivity, without much CPU capacity) ... meaning it didn't support gitweb. I thought it would be more convenient for folks to evaluate my patches if I put my FGFS stuff on a gitweb-enabled host. It turned out it didn't make much difference. James Turner looked at a couple of my patches using gitweb, but the only folks who actually downloaded and tested the patches were folks without commit authority. My FGFS gitweb host died a while back. I didn't bother to replace it, since it wasn't seeing any traffic. Consider the following two lists: A) -- nice looking livery -- nice looking vegetation -- nice looking panel layout -- et cetera B) -- realistic localizer -- realistic glideslope -- realistic DME -- realistic status flags -- realistic IDENT -- realistic altimeter and atmosphere -- realistic ATIS -- et cetera For the vast majority of FGFS users, the things on list (A) are important. Things on list (B) don't matter at all. They are harmless but irrelevant. In contrast, real-world instrument flying demands close attention to things on list (B). Things on list (A) don't matter at all. They are harmless but irrelevant, unless they impair the frame rate; you can't see the vegetation at night, or when you are solid in cloud. Everybody agrees that features on list (B) would be nice to have, but years of experience indicate that nobody with commit authority is interested in working on such things. To some extent this is a chicken-and-egg situation. So long as FGFS emphasizes gamer features (list A) it will attract gamers as users. If/when FGFS implements pilot features (list B) it will attract pilots as users. I emphasize that it is _not necessary_ to choose between gamer features and pilot features. FGFS should implement both. There is no reason not to. I guarantee you that a gamer who did not notice the absence of a working status flag will not notice the presence of a working status flag. Everybody says these features are "great". If somebody wants these features enough to actually allow them to be committed, please say so. On 09/09/09 07:08, James Turner wrote: >>> Yes, the 2009 code is different from the 2007 code. >>> The 2009 features and bugfixes are a superset of the >>> 2007 features and bugfixes. Also the 2009 commits >>> were rebased so that they applied cleanly to the FGFS >>> release that was current at the time. > With apologies, I should note that my recent re-factoring work in > navradio will likely mean these patches do not apply cleanly to > current trunk. That's ironic. If the aforementioned patches had been applied back in January 2009, many of the "new" features (such as normalized outputs) would already be in place and well tested. > My issue back in January was, and remains, that I don't feel qualified > to commit major functional changes to the radio code, since radio > modelling is far from my areas of expertise. That's not meant as an > obstacle to incorporating any particular change or bug-fix I'm glad to hear it was not intended as an obstacle. On this list I've heard lots of euphemisms for "none of your code is going to be committed" but at the end of the day they all mean "none of your code is going to be committed". Are not the recent changes "major" changes? Changing the semantics of the outputs, so as to a require a change in every instrument ... that seems kinda major to me. I still think it is a Bad Idea to change navradio.cxx in such a way as to change the semantics of the existing outputs. I recommend leaving the existing outputs alone, and simply _adding_ whatever normalized outputs are desired, under new names. This preserves 100% backward compatibility, so that panel designers are free to update their instruments _or not_, if/when/however they please. This is how my code handled things back in January 2009. If you really want to rip out the old outputs, in the name of "internal cleanliness" or whatever, that can wait a year or two. It is always wise to look at things from the users' point of view. Users care about bugs they can see and features they can see. If/when "internal cleanliness" contributes to reliability, that's fine, but in this case it makes a negative contribution. At the very least, it distracts from incomparably more important work that needs to be done. > simply > that either I need to be able to convince myself that a specific > change is correct .... Otherwise, I'll leave any > functional changes to to others. What others? As of January, I was under the impression that you, James, were the one and only maintainer of navradio.cxx. Are you suggesting that there is someone with commit authority who was interested and/or qualified to judge the correctness of my code? I was quite unaware of this back in January. Has the situation changed somehow? Several people did try out my code ... just nobody with commit authority. Evidently this kind of testing doesn't count. Is the criterion that I have to prove that my patches are absolutely correct? I don't see how it would ever be possible to do that. The code had tons of bugs before I touched it, and it has tons of bugs now. It seems safe to say that accepting my patches would have resulted in a better feature set and _far fewer_ bugs, to say the least. ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Flightgear-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/flightgear-devel
