https://issues.apache.org/ooo/show_bug.cgi?id=124323
--- Comment #4 from trebly <[email protected]> --- Hi, I have enumerated detailed problems as named "bugs". I am completely conscious that is impossible to "attack" such problems using the concept "1 bug = (1 action and 1 project)". For development I commonly was using this way : [1 bug (or bad featured)] <-> [1 request] <-> [<one or several functions and pieces of soft involved>] <-> [n - actions (todo)] <-> [current projects] it is a problem of structure of database for development management, I explain : It is not economically possible to do each job individually, but if the problem is known what we have (always) to do is to manage soft components structure, the list of bugs+bad_featured+enhancements, the list of decided projects. With these tables (common in project management) we can manage the links between the 3 structures. Then each time a project is launched it is easy to get the "bugs+bad_featured+enhancements" that are linked and to decide to treat someone for a very low-cost because it become just a little element of an upgrade process. What I see as priorities : 1- For each options changes which involves JAVA / run when OK is hitten an little sequence (as the one is run for search in help) which will crash if Java is not running well and send an ALERT message "JAVA is not running Well on the system". 2- For "Repair installation" be carefull to check the existency of each directory (use always try and error exception catch -> (re)create it and fill). This can be easily done for the case that I found, and later for all concerned directory of a module which must be upgraded for another reason. So my global answer is : - most of should be fixed (which one and which content) but cannot be treated as "punctual action" which would be too expensive. - each element of "fix-code" (which is into various places of the whole soft) can be (which ones and with coherent specifications) integrated in "todo" list associated to various projects - all choosen as useful will be cleaned progressively for the next years - there is no change for solving bug linked to the "bugs" that are in my list which leads to a coherent and unique main development. So it can be a long term progressive action. The tools and the way to solve which is involved, used, to manage this type of problems are not well adapted. For my own I uses a database described for a part at the beginning of this message. Best regards trebly -- You are receiving this mail because: You are on the CC list for the issue. You are the assignee for the issue. You are watching all issue changes.
