I agree with Tim here. There are many secondary benefits of time-boxed releases. Getting bugfixes and mindshare improves interactions with the user community and attracts users which ultimately attracts new developers.
Of course there is a percentage effort cost to ensure broad stability - but ultimately that comes down to developer discipline and branch structure more than anything. By project agreement you sacrifice a release for high value/high risk changes (like the OSG transition). But beyond that you push for a greater focus on complete changes and as was originally suggested an improved architecture that allows subsystems to be added and removed is the main driver. With this new release, flightgear's multihead capability will be added to the Phoronix Test Suite as a test. (Google for more info). If someone wants to take leadership in improving testability/automated testing with flightgear, that can go a long way to pushing flightgear out further, as well as ensuring that standard releases can be tested. If there is someone willing to step up to the task I can provide more information. Any takers? Regards... Matthew On 12/29/08, Tim Moore <timo...@redhat.com> wrote: > LeeE wrote: >> Hello dev list, >> >> If you're in no mood to critically appraise a rant then read no >> further. >> >> For quite a while now, since I stopped actively contributing to FG, >> I've been sitting here watching the direction in which FG >> development is heading and if ever there was a good project, which >> has potentially boundless scope in the field of VR, but which has >> lost it's way and is now chasing it's tail up it's own fundament >> then FG is it. >> >> What finally broke this camel's back was the thread about release >> schedules, but it goes further than that. >> >> The idea that FG should be updated and released to what is a purely >> abstract schedule is disingenuous and destructive nonsense. The >> origin and sole purpose behind the idea of releasing new versions >> of software on any sort of regular schedule is to upset and exploit >> the market for the type of software you're producing; it's a thinly >> veiled attempt to deter your market from trying, and perhaps >> adopting, alternative solutions by promising even better things in >> your future product. This simply doesn't apply to open-source >> software projects because maintaining or increasing market take-up >> of your product brings no benefits to you, other than massaging >> your egos. > What we're talking about is doing "timebox releases." I suggest you Google > the > term. There is a steady stream of new features checked into CVS. However, > most > FG users can't or won't build Flightgear from source, so these features > don't > see wide use until a release. The fact that we make a release is a signal > that > we believe the code to be stable and that it is worth the time of packagers, > within the FG project and outside, to make a package out of the code at that > point. The timebox idea enforces some discipline to get the code ready and > not > noodle around with new features indefinitely. It's used by many open-source > projects today. It will certainly work better with several independent > source > branches in the repository. > > So I reject the breathless cynicism of your proposition :) > >> >> The idea then, that new versions of FG should be released on a >> regular schedule, is an attempt at competing with something that >> has no intrinsic value - it's a worthless fight, not only for the >> effort that it consumes, but for what could be won. >> >> The reason that Open-source projects occur at all comes down to one >> major factor; someone has a better idea. There are a number of >> secondary reasons for open-source projects, but without that single >> primary reason they're pointless - what is there to be achieved by >> simply duplicating what has already been achieved? Simply doing it >> so that people don't have to pay money for it is not an adequate >> answer; if people need the software they'll pay for it, if >> necessary. The 95% of computers that run MS software proves this. >> >> The justification for the existence of FG is to make a better >> solution. 'Better' in this context encompasses several areas: >> being 'open' is the primary benefit of open-source projects, >> because whatever you do will never be perfect for everybody, but >> being open means that other people can progress in their own >> direction by standing on your shoulders; but they couldn't do >> whatever they want to do without you doing your bit first. But >> being 'better' also means other things too. Another important >> aspect of 'better' includes the overhead of using the FG solution >> over others, and in this respect FG is getting worse not better. > I think many would say that an open-source flight simulator is already a > better > idea than a closed source one. Not only is it useful for many projects, it > is > more fun to work on :) >> > ... >> >> As a consequence, while the overall design of FG is familiar to many >> of the developers, no one knows all the details. This is normal in >> such a complex software project, but in such a complex project >> everyone _does_ need to know the scope of their work; what their >> work will effect, and how. For FG though, this is absent; no one >> can be sure that the scope of their change will not extend beyond >> what they intend and it's almost become a case of random guesswork >> as to the scope of the consequences of source-code changes. In >> just about every case, the software changes that make it in to FG >> are a good idea, and should make FG better, but in practise now, >> they are just making a confused situation worse. >> > Part of the problem is that it's hard to comprehensively test new work > against > the wide range of aircraft and possible scenarios, to say nothing of the > varieties of hardware and operating systems people are using. I don't have > any > great insight there, other then perhaps using more pre-recorded FDM data > like > Matthew Tippet has done in his demos. Frequent releases help flush out bugs > too... > >> In summary then, for FG to survive in any greater form than a quaint >> alternative to better alternatives, which I admit may not exist yet >> but will certainly do so at some point in the future, FG _needs_ to >> be re-designed with an architecture that not only makes use of >> current hardware, especially with regard to multi-core/distributed >> computing systems, but also enforces scope of sub-systems and >> allows multiple concurrent versions of sub-system. > It's easy to suggest this when you're not contributing actively. Putting > snark > aside, I'd suggest that FG is not in as bad shape as you think. The property > system is already a great mechanism for communication among the sub-systems > of > FG. A great project would be to look at making the property system > thread-safe, > and follow that up by turning it into a "blackboard" that can be used by > distributed copies of FlightGear. >> >> Doing this is a daunting but necessary task. It also cannot be the >> only task that people work on, but it has to be done nonetheless, >> and sooner rather than later. It will also not be a quick and easy >> task - it will probably take a couple of years of thinking, >> experimenting and testing to just come up with a viable >> architecture, let alone implementing a 100% solution, but it needs >> to be started now. >> >> Having got that off my chest, I'd like to make it clear that I'm not >> trying to criticise anyone, or the FG dev community in general, and >> as such, I'm not interested in arguing about any of this. The >> reason that I've bothered to spend a couple of hours composing this >> post is not to annoy & diss people but because I care. If I >> didn't, I wouldn't have bothered. And at least I waited until >> after xmas so I didn't spoil it for anyone:) > > Despite the fact that I disagree strongly with almost everything you've > written > :), I respect your opinion and I know it takes time to write mail that one > cares > about. > > Tim > > ------------------------------------------------------------------------------ > _______________________________________________ > Flightgear-devel mailing list > Flightgear-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/flightgear-devel > -- Sent from my mobile device ------------------------------------------------------------------------------ _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
