db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dag.Wan...@Sun.COM (Dag H. Wanvik)
Subject Re: categorizing JIRAs
Date Sun, 15 Jun 2008 20:44:54 GMT
Andrew McIntyre <mcintyre.a@gmail.com> 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

Mime
View raw message