Re: [Flightgear-devel] RFC : FlightGear Roadmap for 2.0 and further
Tatsuhiro Nishioka wrote: Hi there, I'm very happy that we finally released 1.9.0. According to the discussions before the release, I believe that many of us are willing to release FlightGear more often, like semiannually or quarterly (or even more often). To release more than once a year, I believe that we need to have clearer roadmap, versioning policy, and the release process. Here are my opinions so please give me comments and feedback please. 1) The version numbers and release dates Here's an example list of version numbers and release dates when FlightGear will be released quarterly. 2.0 - at the end of March, 2009 2.1 - at the end of June, 2009 2.2 - at the end of September, 2009 2.3 - at the end of December, 2009 This is a good idea, regardless of the specific milestones that make it into a release. It seems to me that just the data tree sees enough new development that quarterly releases would have interesting new content. 2) Milestones (Goal for each release) Here's an example list of must-achieve things for 2.0.0 (based on discussion on the list, I believe). [2.0.0 - at the end of March, 2009] Functionality: - Landing Lights - Shadows - More improvements in 3D clouds (I don't know the exact goal on this though...) This sounds nice, but we, or at least I, can't commit to specific features or development on a fixed timescale. 3) Release branch I believe that we need to have a release branch for both developers and release organizers. The main reason is to separate bug fixes from implementing a new features. This way, developers don't have to wait for the release to check in attractive but likely buggy code to cvs. Usually you must not include a new feature to the release branch once it is created. However, if many developers want to include one to the release branch, then we can discuss it in the list. After each release, we'll merge the bug fixes to trunk. If we get used to this release process, maybe a branch exists only for a few weeks, and thus merging changes to trunk is not gonna be that hard. I think this is a very good idea, and the work like shadows could start going into a bleeding edge branch soon. I think we need a stable branch, even with quarterly releases; new code and fixes are checked in all the time that our power users want, even if they aren't willing to break their world with experimental stuff. That said, I cannot bear the thought of setting up this parallel branch structure (to say nothing of the plib branch, that sees some fixes from time to time) in CVS. I know it's possible in CVS, I've worked on many hobby and professional projects that use CVS branching, and there is always some fiasco that happens in the course of making or merging branches. I don't have the bandwidth to deal with those headaches on a hobby project. Thus, I won't support a bleeding-edge branch until we move to a revision control system that properly supports branching. We can debate this 'til the cows come home, but Git is the only rational choice for a replacement VCS. It has the features, the community, and today has the user friendliness and Windows support to be used by everyone who wants to compile current FG development sources. It is already being used by a critical mass of FG developers. Tim -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC : FlightGear Roadmap for 2.0 and further
Hi, Thanks for the comments, It's kinda hard to reply individually, so here I wrap up the comments given so far: 1) The version numbers and release dates Here's an example list of version numbers and release dates when FlightGear will be released quarterly. 2.0 - at the end of March, 2009 2.1 - at the end of June, 2009 2.2 - at the end of September, 2009 2.3 - at the end of December, 2009 James: It's not quite the number system I first guessed at, and I think the odds of ever *doing* a bug-fix release are quite low, but it sounds reasonable. Stuart: A roadmap would be a great idea. However, I'm not sure a quarterly release cycle is realistic. Allowing for a 2 week RC test, you're talking about less than 3 months of actual development between releases. That's not much time. Tim: This is a good idea, regardless of the specific milestones that make it into a release. It seems to me that just the data tree sees enough new development that quarterly releases would have interesting new content. So having such version numbers are acceptable but we have more room on determining the release cycle. To me quarterly release cycle is reasonable, plus you don't have to promise 100% completeness on a certain feature for each release. Almost all open source software have some bugs in each release, so we don't have to seek for such perfect project that none can reach. There're some preferences for version numbers, but all the comments are not against the version numbers I listed as examples. So my idea may be acceptable, I think. I want to collect more opinions on the release cycle. Which do you prefer, semiannual or quarterly? and why? 2) Milestones (Goal for each release) Here's an example list of must-achieve things for 2.0.0 (based on discussion on the list, I believe). [2.0.0 - at the end of March, 2009] Functionality: - Landing Lights - Shadows - More improvements in 3D clouds (I don't know the exact goal on this though...) Stuart: These seem like sensible goals for a 2.0 release. However, they appear to be very dependant on Tim and myself. (snip) Pushing for a release in 3 months without any commitment from the developers involved in the main feature improvements is pretty high risk. Tim: This sounds nice, but we, or at least I, can't commit to specific features or development on a fixed timescale. James: Overall I agree, coming from a commercial software development side, I'd prefer people to think in terms of features, and committing to delivering them for a certain release. Where a feature means the kind of thing we'd put in a 'new for this release' bullet point list. Then we can decide whether to delay a release because feature X will take an extra two weeks, or postpone feature Y from release 2.n to 2.n+1 because it would delay it too much. So maybe Must-achieve is a bit too tight. What about listing features that you (will) start working instead of must achieve. That also work. This way there's no commitment of achievement on each release, but it rather says you are or will be start working on a listed feature on a certain release. We cannot seek for the 100% completeness at the end of each release, but it is a good idea to show that we have a certain set of features regardless of completeness. we can keep improving such features in the versions follow. How's this? About the milestone document, we can put these in either wiki or cvs. Maybe there's no perfect place so we can start writing such things to wiki with a clear note like developers only. By the way, are there any features that can be implemented on 2.0.0? 3) Release branch I believe that we need to have a release branch for both developers and release organizers. The main reason is to separate bug fixes from implementing a new features. This way, developers don't have to wait for the release to check in attractive but likely buggy code to cvs. Usually you must not include a new feature to the release branch once it is created. However, if many developers want to include one to the release branch, then we can discuss it in the list. After each release, we'll merge the bug fixes to trunk. If we get used to this release process, maybe a branch exists only for a few weeks, and thus merging changes to trunk is not gonna be that hard. James: I think in practice, the odds of ever doing a release *branch* for a project like FG is very low. I'd rather just stabilise trunk and tag. If we ever needed to do a x.y.1 release, it's trivial to branch from the tag and fix the bug. In general, back-merging from a release branch to a trunk is a horrible, thankless task, so avoiding it seems like a win to me. Stuart: I think cutting a release branch just prior to the release makes sense, but having long-term release branches and only merging from trunk when you're confident a feature is finished and
[Flightgear-devel] RFC : FlightGear Roadmap for 2.0 and further
Hi there, I'm very happy that we finally released 1.9.0. According to the discussions before the release, I believe that many of us are willing to release FlightGear more often, like semiannually or quarterly (or even more often). To release more than once a year, I believe that we need to have clearer roadmap, versioning policy, and the release process. Here are my opinions so please give me comments and feedback please. 1) The version numbers and release dates Here's an example list of version numbers and release dates when FlightGear will be released quarterly. 2.0 - at the end of March, 2009 2.1 - at the end of June, 2009 2.2 - at the end of September, 2009 2.3 - at the end of December, 2009 0.1 is increased on every release until it reaches the goal of 3.0.0 (it can be 2.10.0 or 2.150.0 :-p) I think incrementing minor version number on each release is enough for our project, and micro version number can be reserved for bug-fix releases between two releases. 2) Milestones (Goal for each release) Here's an example list of must-achieve things for 2.0.0 (based on discussion on the list, I believe). [2.0.0 - at the end of March, 2009] Functionality: - Landing Lights - Shadows - More improvements in 3D clouds (I don't know the exact goal on this though...) Reliability: - NaN things must be eliminated - SIGSEGV must be avoided when: + no osg plugins are found + a sound file is missing + there are some other missing xml / ac files Usability: - to be determined (T.B.D.) Effifiency: - T.B.D. Maintainability: - T.B.D. Portability: - T.B.D. [2.1.0 and further versions ] - T.B.D. :-p We can add more items on each category (I took these categories from ISO-9126, but we can express the must-achieve things in a different categorization) Maybe we need to separate general FG things from per aircraft things. It is also very good to organize the must-achieve items for each release based on the following documents: - http://wiki.flightgear.org/index.php/Long_Term_Goals - http://wiki.flightgear.org/index.php/FGFS_Todo - http://wiki.flightgear.org/index.php/Feature_Requests_/_Proposals_/_Ideas I believe that these milestones don't prevent the developers from implementing their new ideas at all. we can freely add new features even these are not listed in the milestones. Moreover, if we cannot implement some of the must-achieve items due to lack of time, then we will carry these over the next release, and make the current release published. 3) Release branch I believe that we need to have a release branch for both developers and release organizers. The main reason is to separate bug fixes from implementing a new features. This way, developers don't have to wait for the release to check in attractive but likely buggy code to cvs. Usually you must not include a new feature to the release branch once it is created. However, if many developers want to include one to the release branch, then we can discuss it in the list. After each release, we'll merge the bug fixes to trunk. If we get used to this release process, maybe a branch exists only for a few weeks, and thus merging changes to trunk is not gonna be that hard. Any comments, better idea? Tat -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC : FlightGear Roadmap for 2.0 and further
On 25 Dec 2008, at 18:38, Tatsuhiro Nishioka wrote: 1) The version numbers and release dates Here's an example list of version numbers and release dates when FlightGear will be released quarterly. 2.0 - at the end of March, 2009 2.1 - at the end of June, 2009 2.2 - at the end of September, 2009 2.3 - at the end of December, 2009 0.1 is increased on every release until it reaches the goal of 3.0.0 (it can be 2.10.0 or 2.150.0 :-p) I think incrementing minor version number on each release is enough for our project, and micro version number can be reserved for bug- fix releases between two releases. It's not quite the number system I first guessed at, and I think the odds of ever *doing* a bug-fix release are quite low, but it sounds reasonable. 2) Milestones (Goal for each release) Here's an example list of must-achieve things for 2.0.0 (based on discussion on the list, I believe). snip Overall I agree, coming from a commercial software development side, I'd prefer people to think in terms of features, and committing to delivering them for a certain release. Where a feature means the kind of thing we'd put in a 'new for this release' bullet point list. Then we can decide whether to delay a release because feature X will take an extra two weeks, or postpone feature Y from release 2.n to 2.n+1 because it would delay it too much. OGRE create a wiki page for each release - initially it's a blue-sky page, then it becomes 'live' when the release is being worked on, and finally it becomes the release notes for that release, with a list of completed features. That seems pretty logical to me. 3) Release branch I believe that we need to have a release branch for both developers and release organizers. The main reason is to separate bug fixes from implementing a new features. This way, developers don't have to wait for the release to check in attractive but likely buggy code to cvs. Usually you must not include a new feature to the release branch once it is created. However, if many developers want to include one to the release branch, then we can discuss it in the list. After each release, we'll merge the bug fixes to trunk. If we get used to this release process, maybe a branch exists only for a few weeks, and thus merging changes to trunk is not gonna be that hard. I think in practice, the odds of ever doing a release *branch* for a project like FG is very low. I'd rather just stabilise trunk and tag. If we ever needed to do a x.y.1 release, it's trivial to branch from the tag and fix the bug. In general, back-merging from a release branch to a trunk is a horrible, thankless task, so avoiding it seems like a win to me. James -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC : FlightGear Roadmap for 2.0 and further
Tat wrote: I'm very happy that we finally released 1.9.0. Thanks for your hard work in making it happen! According to the discussions before the release, I believe that many of us are willing to release FlightGear more often, like semiannually or quarterly (or even more often). To release more than once a year, I believe that we need to have clearer roadmap, versioning policy, and the release process. Here are my opinions so please give me comments and feedback please. A roadmap would be a great idea. However, I'm not sure a quarterly release cycle is realistic. Allowing for a 2 week RC test, you're talking about less than 3 months of actual development between releases. That's not much time. For example, I think we've had 3D clouds in CVS for 3 months at least, and we certainly haven't ironed out all the bugs yet. 1) The version numbers and release dates Here's an example list of version numbers and release dates when FlightGear will be released quarterly. 2.0 - at the end of March, 2009 2.1 - at the end of June, 2009 2.2 - at the end of September, 2009 2.3 - at the end of December, 2009 0.1 is increased on every release until it reaches the goal of 3.0.0 (it can be 2.10.0 or 2.150.0 :-p) I'd prefer to name something 2.0 or 3.0 when we think we are producing a major release, with significant new features. Producing 3.0 simply because the last release was 2.9 will set false expectations for users - they will be expecting significant feature improvements. Much better would be 2.01, 2.02 ... that gives us much more leeway before the next major release. I think incrementing minor version number on each release is enough for our project, and micro version number can be reserved for bug-fix releases between two releases. That's certainly sensible. 2) Milestones (Goal for each release) Here's an example list of must-achieve things for 2.0.0 (based on discussion on the list, I believe). [2.0.0 - at the end of March, 2009] Functionality: - Landing Lights - Shadows - More improvements in 3D clouds (I don't know the exact goal on this though...) These seem like sensible goals for a 2.0 release. However, they appear to be very dependant on Tim and myself. Regarding 3D clouds: - There are significant ordering issues, quite apart from the challenge posed by creating stratus layers. Frankly, unless someone else is intending to spend significant time writing 3D clouds _code_, I don't think 3 months is going to be enough time for me to fix all the issues. I made myself enough of a hostage to fortune last time by saying I'd have them ready by Christmas - I'm not making that mistake again ;) I believe Tim has spent some time working on Shadows (don't know about landing lights). He's much more sensible than me and hasn't said when he'll have any code ready ;) Pushing for a release in 3 months without any commitment from the developers involved in the main feature improvements is pretty high risk. [We'll gloss over the fact I'd be a bit disgruntled being told when to have something ready. That's far to close to work, and FG dev is pretty close already ;) ] Reliability: - NaN things must be eliminated I completely agree on this one. We can add more items on each category (I took these categories from ISO-9126, but we can express the must-achieve things in a different categorization) Maybe we need to separate general FG things from per aircraft things. It is also very good to organize the must-achieve items for each release based on the following documents: - http://wiki.flightgear.org/index.php/Long_Term_Goals - http://wiki.flightgear.org/index.php/FGFS_Todo - http://wiki.flightgear.org/index.php/Feature_Requests_/_Proposals_/_Ideas As far as I am aware, none of those documents is up to date, or reflects current development. I think a roadmap checked into CVS would be more sensible. We have a docs repository for exactly this sort of thing. At the very least it would mean that some random user can't just add features to the roadmap. snip 3) Release branch I believe that we need to have a release branch for both developers and release organizers. The main reason is to separate bug fixes from implementing a new features. This way, developers don't have to wait for the release to check in attractive but likely buggy code to cvs. Usually you must not include a new feature to the release branch once it is created. However, if many developers want to include one to the release branch, then we can discuss it in the list. After each release, we'll merge the bug fixes to trunk. If we get used to this release process, maybe a branch exists only for a few weeks, and thus merging changes to trunk is not gonna be that hard. I think cutting a release branch just prior to the release makes sense, but having long-term release branches and only merging from trunk when you're confident a feature is
Re: [Flightgear-devel] RFC : FlightGear Roadmap for 2.0 and further
On 25 Dec 2008, at 22:46, Stuart Buchanan wrote: As far as I am aware, none of those documents is up to date, or reflects current development. Yep - that's partly why I created a personal 'plan' page - so I can say what I *am* working on, and what I intend to work on, and hence hopefully avoid people getting upset when work is duplicated. I think a roadmap checked into CVS would be more sensible. We have a docs repository for exactly this sort of thing. At the very least it would mean that some random user can't just add features to the roadmap. Could work, though CVS isn't terribly visible, so this is a two-edged sword. James -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
