Stefan Steiniger wrote: Hello,
> 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 Ok, I'm already back from the Allgäu (we had to cancel our other planned 4-weeks vacation due to visa difficulties). I could almost see you from up at the Nebelhorn ;-) So I'll just start discussing... (hoping nobody else is on vacation and misses this) > * 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 Yes, I'd also like to see such a system. > * i think i would agree that we should have a clean >=5 bug list after > doing a major release e.g. 1.3 Me too. > 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) This seems fine to me. Anyway, for new versions, (1.3 to 2.0) IMHO we should carefully select the features/bugs we want to have fixed/implemented. > 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 I'm sure I can help to fix some (important) bugs when the time comes for a release/freeze. > 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. I guess the selection of new features which will be integrated in a new (major) release happens automatically for us, whenever someone commits one into trunk. Maybe we should not concentrate on the feature requests/wish list bugs too much. I for one can say that I can at most work on some small new features/wishes, since my company will not be able to support bigger developments for free. > 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. Agreed. > c) i think refactoring the JUMP core is impossible due to external > plugin dependencies. Refactoring of the core may be possible if we still support the old API through @deprecated wrappers to the new API. IMHO a rewrite or refactoring of complicated code is almost always a good thing, especially when new features will be added in the future anyway. Else one may end up with code that only a select few people can touch without breaking anything. On the downside, great changes to the core will involve a lot of work, which may or may not pay off. > >>>> > seems like we should sit together and make a release plan for the next > release 1.3 ;) > >>>> Agreed ;-) > 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. Yes, there is definitely a LOT of traffic going on. I sometimes need 2h just reading all those emails... > Maybe we should start thinking about > a) a voting system (using www.doodle.ch? would be an idea) I don't really see the need for a voting system. But I'd be happy to participate :) > b) or a complete new project structure: e.g. making task groups > (responsibles), dividing admin stuff and deveopment stuff. That sounds like a reasonable idea. This could also cut down on email traffic, eg developers only reading the devel lists. I'm not sure whether task forces are the right thing though. Being on a bug fix task force or not, when I have the time, I'll fix them ;-) Without having a concrete idea on how to fix the problem, I think that I could have used a lot of email time to fix a bug or two in the past. Maybe I should try to set up some better email filters... Best regards, Andreas -- l a t / l o n GmbH Aennchenstrasse 19 53177 Bonn, Germany phone ++49 +228 18496-11 fax ++49 +228 1849629 http://www.lat-lon.de http://www.deegree.org
signature.asc
Description: Digital signature
------------------------------------------------------------------------- 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
