Michaël Michaud wrote: Hi,
> Here are some thoughts about releases and bug management. > I think we miss some rules to decide when a new version of OJ has to be > released, and that lack of visibility may be a disadvantage for OJ's > adoption. I totally agree with this point. > The release rules should be linked to bug reports and feature requests, > but bug reports have to be sorted before they can be used as a base for > release decision. ACK. > A proposition is to let the default level 5 for bugs which have to be > fixed before a stable release, to use level 1 and 2 for bugs which have > to be fixed ASAP (before any release) and to set less important bugs to > priority 6 or more... (any other suggestion is welcome). > Any one having access to the bug tracker should be able to initiate this > hierarchy, subsequent changes should be asked to the community. > Major releases (version changes) could work the same way but based on > feature requests (feature requests for version 1.2, for 1.3...) I think that's a great idea. Since the list of bugs/feature requests is already quite long, that would make working on it more rewarding, with each bug fixed being one step towards the next release. 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 ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
