I liked the categories that Satheesh proposed. I don't really care if the sub categories have SQL- or not. I see having these categories as better than not, even though in most cases I expect Derby users to just go ahead an report SQL rather than a subcategory.
I see the sub categories as value to the Derby developers, and expect them to move issues from SQL to one of the sub-categories as they add their expertise to the issue. Andrew McIntyre wrote: > > On Jan 30, 2006, at 9:33 AM, Kathey Marsden wrote: > >> On Jan 23, 2006, at 10:25 PM, Satheesh Bandaram wrote: > >>> This sounds good, balancing what is good for users and developers >>> working with JIRA's limitations. So, I would suggest: >>> >>> SQL >>> SQL-parser >>> SQL-optimizer >>> SQL-compiler >>> SQL-datatype >>> SQL-execute or SQL-executor (First one matches 'execute' package name) >> >> >> Should issues in the subcategories also be marked as SQL? >> >> >> I personally am not so keen on it because >> >> >> - makes it all the more liikely that issues will be assigned the >> >> wrong components >> >> - adds more maintenance >> >> - I am guessing we will gets lots of questions about where to put >> issues. >> > > Perhaps a better breakout, based on the current organization of the > code, would be: > > SQL (== parser/datatypes/standards compliance) > Optimizer (== reorg of query tree) > Compile/Execute (== java representation of optimizer-selected query) > > Based on a quick review of the issues filed in JIRA, this makes sense to > me. If I were to reclassify some of the current issues assigned to the > SQL component, I would assign them as follows (by JIRA number): > > SQL - 20, 69, 277, 396, 464 > Optimizer - 269, 713, 781, 837, 890 > Compile/Execute - 28, 176, 338, 438, 759, 887 > > And anything that crosses these boundaries should be assigned multiple > components, such as SQL and JDBC, with DERBY-215. Or Store and Optimizer > with DERBY-886. > > But, I'm sure there will be other opinions on the list. I won't make any > changes until there's something resembling consensus. :-) > > andrew > >
