Hei,.. took me a long time to come to this email. It is longer than intended .. and i actually don't want to start the discussion on this now, as some people are still in holidays and i am busy with other things as well.
1) my comments on the release strategy =========================== * first when moving on with the disucssion we shall wait until Andreas is back from vacations * i agree that we need a system.. but which one? * i like the classification proposed by Michael (but inverted ;) It is a very good start, and we shall adopt it! I believe we are anyway just 2-3 person adding bug reports (actually i would like to see more added bug reports to have a history) * lots of the bug reports added recently by myself are reminders * i think i would agree that we should have a clean >=5 bug list after doing a major release e.g. 1.3 2) A release vs. bug management strategy could look like this: =========================== * value >6: bug need to be fixed before minor release (e.g. 1.2.2 to 1.2.3) * 3< value <6: fix for major release (e.g. 1.2 to 1.3) * value <= 3: fix latest for new version(1.3 to 2.0) 3) but there are still problems: ============================= - who classifies the bugs? - will somebody work on the bugs if we do a freeze? - when do we freeze? - who decides for the next release notes: a) to make a new major release (1.2 to 1.3) new features should be necessary. But this is obviously not a problem for us. b) when adopting larger core-changes (GUI: Dockable Framework, Data-IO) we need to include all projects: Pirol, Lat/lon, SIGLE, SkyJUMP and JPP in a discussion. c) i think refactoring the JUMP core is impossible due to external plugin dependencies. >>>> seems like we should sit together and make a release plan for the next release 1.3 ;) >>>> stefan PS: to be honest. Currently I have the feeling that OJ requires a half-day for managment (reading and answering emails can take up to 2h a day).but maybe this is reasoned by the fact that I (try) to do OJ stuff only in my speartime. Maybe we should start thinking about a) a voting system (using www.doodle.ch? would be an idea) b) or a complete new project structure: e.g. making task groups (responsibles), dividing admin stuff and deveopment stuff. ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
