Michael, I like the concept behind this suggestion. I only see a couple of obstacles to its implementation:
[1] It requires that someone sort and maintain the bug-tracker list. [2] It requires some of us to quit working on out "pet functionality improvements' and to start fixing bugs. I don't think it is very "fair" to put the burden for either [1] or [2] on any single programmer. I would suggest we choose two (2) weeks before the end of the year to do the following: [1] Freeze all new contributions to the JPP SVN. [2] Sort and prioritize the bugs in the bug tracker. [3] Ask for volunteers to tackle one or two bugs during the freeze. [4] Integrate bug fixes. If there is support for this, I would gladly take on a large chunk of the work required to sort the bug tracker, and I know there are one or two bugs that I have had my eyes on. Would the first two (2) weeks in October work? We could then shoot for another stable release by the first of November. (We should really let Stefan have the final decision, since he has been taking care of the OpenJUMP releases. These are just some suggestions.) The Sunburned Surveyor P.S. - If I remember correctly from my last attempt at fixing three (3) items in the bug tracker only one (1) of the three (3) items was really a bug. The other problems were resolved or caused by other factors and didn't really belong in the bug tracker. I imagine we will discover more of this, which means we likely don't have the bug problem that we think we do. On 9/3/07, Michaël Michaud <[EMAIL PROTECTED]> 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. > 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. > 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...) > > This way, may be we could focus on major bugs and try to release a > stable version before the end of 2007. > > Michaël > > > ------------------------------------------------------------------------- > 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 > ------------------------------------------------------------------------- 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
