Andrew McIntyre <[EMAIL PROTECTED]> writes: > I think he means: > > a) Deviation from a standard: JDBC, SQL, DRDA > b) client and embedded driver differences
Yes, thanks, Andrew. Thanks for extending the categories, it is better than stretching the semantics of the Components field, IMHO. A small issue, we now have Security both as a component and as a category. So far, for example when doing work relating to security I have ticked off the Security component as well as any other component affected, e.g. SQL. I think we could continue to do that when developing security related features which is by nature a cross-cutting aspect. So, what should be use the security category for? Rick suggested security holes if I understood correctly (a bug subcategory). If we want that the be the meaning of this category, we should perhaps be explicit in the name, e.g. "security hole" (covering also potential security holes). An alternative is to drop the security component and just keep the category (for simplicity). Too many options lead to choice problems :) +1 to move over regression from Info to Category if it doesn't create +too much havoc. This explanatory line could perhaps be reworded a bit: "Categories for Derby bugs (Performance, Security, etc.) that don't fit in the component list" seems to constrain the usage of the Category fields to bugs. I think they are useful also for Improvements (and possibly even New Features?)- For example, an issue marked "standards deviation", I could easily see labeled as an Improvement in stead of a Bug in many cases. So I suggest: "Categories for Derby issues (Performance, Security, etc.) that don't fit in the component list" Thanks, Dag
