Talk:Release plan
Testing Point Releases (after 2.10)
See http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg39287.html
For the benefit of the unwashed masses...
Would it be acceptable to discuss this proposition on this page? I've never managed to use the dev list properly - it always ends up being rather messy. -- Armchair Ace 15:00, 23 May 2011 (EDT)
What about inserting in this cycle a refactory release?
Hi, I was thinking: wouldn't it sound gound to add a 'refactoring'/performance/bugfixing specific release in this cycle. Maybe use a 3.1 number for instance. This would enable devs and fellow contributors to focus on fixing bugs reported, and try to make performance better on their projects. -- f-ojac 09:33, 21 August 2012 (EDT)
- Well, I like the idea, but I think it cannot be handled right now - due to the required workload for each release, just look at how people and resources are still the limiting factor here, even with "just 2" releases per year. This is because of all the manual work that's involved here. I don't think we'll see more releases without some serious automation work, like mentioned at Release plan#Open_items.2C_questions. Only after the release process is largely automated, can we expect more releases. Also, it's worth noting that, strictly speaking, refactoring is very different from improving performance or bugfixing. Bug fixing in particular is meant to be done during the code freeze period already. But, refactoring is all about keeping the existing behavior, while improving the design and the architecture to make it more maintainable. Now, having a "performance" release would be cool for a number of reasons,and FG can really be a resource hog. And FG eating up 14+ gb of RAM is just ridiculous and could have an impact on the project's reputation.--Hooray 04:42, 21 August 2012 (EDT)
FGRun inclusion
fgrun is now hosted in the fg project, and appears as a submodule of fgmeta in the master branch. A Jenkins task, Windows-rel-test, is configured to demonstrated the feasibility of including it in the final build process. What about including it in the release plan (same for maclauncher btw) ? -- Fredb 08:52, 4 September 2012 (EDT)
Should we sync the nav.dat more often and on a separate way from the apt.dat? Seems ours is getting pretty old now, and users are reporting about missing or old navigation aids in it. F-ojac 13:12, 16 November 2012 (EST)
project roles
We should generalize the release plan such that we introduce categories for different project roles (core developers, wiki admins, forum admins etc) so that there's a fallback in place whenever someone should be not be available (i.e. the Mac release for 2.8 was affected by the Tat's absence).
Ideally, we'll have different categories of users and their corresponding rules, such as:
etc --Hooray 19:04, 26 January 2013 (UTC)
"Lessons learded" != "Bugs found"
Hi Hooray (mostly),
I don't think the release plan is the right place to list bugs found during release candidate testing. I see the "What we learned" section as a place where we list things related to the process of releasing FlightGear into the wild.
Some examples:
- The fact that the keypad is broken on Mac since 2.8 doesn't have anything to do with the 2.10 release IMO. These things belong in our bug tracker.
- Same for "We should ensure that all dialogs can be used with the recommended minimal screen size".
- "Hosting a non-GPL hangar on the FG site" is also unrelevant IMO. That should/can be discussed independently from the official releases (because this would suggest that aircraft can be updated inbetween releases).
It would be nice if we could keep the list comprehensive and relevant, else it will soon turn into an unreadable mass of text. I much more prefer to focus on those things that did go wrong during the release, so we can fix them for the next cycle.
Cheers, Gijs 12:44, 1 February 2013 (UTC)
- Yes, agreed with Gijs - the list is meant to be about process improvements, not features of code.
- James
- Not at all disagreeing, I just ended up adding stuff that was discussed in the RC sub forum, especially issues NOT logged in the issue tracker. Also, whenever an issue affects more than just a single release (or even several just RCs), it's probably a good candidate for process improvements. This is really not about code features or bugs, it's about identifying issues to improve the release plan - issues that don't have another dedicated place yet, and which will be more than certainly forgotten about in 6 months from now, i.e. when the next release is due. Reviewing the list, and considering to add them to a dedicated page then.--Hooray 18:39, 1 February 2013 (UTC)
- Disagree. In some cases individuals (like myself) may have issues with how things are handled within FlightGear - but may not know if the issue is rightly considered a bug, or something else. In my own case, I would LOVE to create/submit a list of Windows installation issues/best-practices to dramatically improve the Windows installation and run-time experience - but have no idea where to put them. Creating bug reports for this list of items would be long, difficult, and cumbersome. Actually, I would love to create - somewhere within this WIKI if it is deemed appropriate, a "Windows installation issues" page where I, and others, could post Windows installation issues that could then - if needed - be transformed into bugs.
- p.s. How do you get the signed and dated signature tag? I looked in formatting and could not find it, so I am cutting-and-pasting the codes from someone else's signature and filling in my own information.
- Jim (JR)
- @Jim: These are all fair points, however we need to draw a line somewhere - and I do agree with Gijs & Zakalawe that the "Lessons learned" section has become rather sizeable. On the other hand, our main issue is lack of RC/release feedback, especially structured feedback. What I have been adding, were mostly points made in response to the 2.10 release. And I do agree that some items simply don't belong here. It's taken hours to compile these lists from various places. The truth is, we don't really have that many active contributors who actively follow/maintain the release plan according to the original agenda. What I have added information-wise will at least provide the foundation to change things in the future. Yes, it's plenty - but at least 90% of these items are directly applicable to the relase process, or to improving the troubleshooting process for our RC/beta testers. We cannot expect people to provide quality feedback if we don't provide the hooks/tools in the first place. Similarly, we cannot expect for the Release Plan to improve over time, if we don't collect feedback in a central place, and keep reviewing the release procedures in order to refine things. Bottom line being: yes, there are a bunch of things that don't really belong here, but the majority of items is pretty relevant - and the "Lessons learned" section would be much worse off without that info. In fact, I'm really hoping that we'll find a way to address the more important issues, revise the release plan accordingly, so that future releases won't suffer from some of the issues mentioned here. But obviously that won't happen "automagically", without us putting a concsious effort into it. So it's indeed a fine line to walk here: too little feedback, and we won't improve - too much, and people won't bother reviewing things here. Which is what Gijs and Zakalawe were pointing at. And their point is in fact well taken by the fact that they are the only ones who even bothered reviewing the section and commenting here obviously! --Hooray 12:56, 29 April 2013 (UTC)