Stefan, This is an excellent e-mail. (By the way, I saw your picture online the other day and was surprised at how young you are. I guess your wisdom had me picturing you as some old university professor.) :]
If we came up with a bug classification system I would be willing to spend a couple of weeks every few months working on bugs during a freeze. I also like the idea of making task groups or assigning different responsibilities. I think you could already put Peppe and I down for documentaiton and OpenJUMP help. :] SS On 9/18/07, Stefan Steiniger <[EMAIL PROTECTED]> wrote: > 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 > ------------------------------------------------------------------------- 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
