ࡱ> Root Entry F@CompObjnWordDocumentG+ObjectPoolII *+,-./01SummaryInformation(  FMicrosoft Word 6.0 Document MSWordDocWord.Document.69q Oh+'0 D h   @d C:\MSOFFICE\WINWORD\NORMAL.DOT7Open Radar 2.0 (Field) Issues Which Need R&D Attention Joe Kuefler Joe Kuefler@"@ Mw@8ޘ@ZMicrosoft Word 6.021g nothing special and nothing wrong. Despite this, a certain subset of their bugs entered via the web manifest a strange behaviܥe3 De+G+&&&&&&&(&'(((( ((b*1(((((((()))))))*T*`<)&&(((((<)(&&((((((&(&()&&,&&&&()(*(Open Radar 2.0 (Field) Issues Which Need R&D Attention TS Call # 47809 (Quark): Bizarre read only row phenomenon Quark is doing nothing special and nothing wrong. Despite this, a certain subset of their bugs entered via the web manifest a strange behavior. No matter what change is attempted on these bug records (from the win32 client), the change does not stick and is lost at commit time. Once a bug record manifests this strange behavior, it will always manifest it, until the entire database is dropped and rebuilt off either RXF or through copy database. Ive completely run out of ideas on this one. They are really strapped. Most of their bugs are entered via the web interface from foreign offices. Im scared that there is something really wrong with RemoteEntry which is just now showing up. Joe has already spent about 6 hours on this issue and the QA person at Quark (Doug McPeek) has probably spent 20. Joe needs more time. TS Call # 46753 (Gelco): Win95 machines are performing 18 times slower than their WinNT machines Gelcos Win95 machines seem to be identical to their WintNT machines, but radar is unusable on them. It takes a user about two minutes just to log into Radar. Joe has already spent about 8 hours on this issue and needs more time. TS Call # 47655 (Siemens): Unexpected Crashes Siemens is really frustrated with Radar. They want to return the product. They say it is too unstable and crashes too much. Joe is working with Sharon Rozines (on site at Siemens) to isolate steps to reproduce one of the crashes, but Joe does not have enough time to deal with this issue properly. TS Call # 46487 (HBOC/Amisys) / Bug # 22702: Radar crashes a lot when doing things too quickly Enough people in the field and internally have witnessed this first hand to refute that it is pure emotion. There seems to be some growing instability in ODBC. Each time a new ODBC application is installed on someones PC, the ODBC files (8 total) are potentially altered and various versions of ODBC may be creating problems for Radar. We fear that this problem will continue to manifest itself at more and more sites. It seems to be getting more and more common. This will takes days to isolate and analyze. It would be easier if someone was on site at Amisys (like Joe did at PhaseForward to nail down the long Description crash), but Amisys is not local. Joe has not spent a lot of time on this yet, since this phenomenon is just starting to become an issue in the field. TS Call # 47347 (ProBusiness) / Bug # 23163: Radar crashes during login with a Functional Sequence error This is related to the long description problem which showed up in the field and which Joe debugged at PhaseForward in Newton. We cannot reproduce this problem at Segue, but it is occuring at least three customer sites. Joe thinks he knows the fix and Jim may have made the code change, but Joe should review the code and then to send a patch (or 2.1 beta) to the various sites who are experiencing the problem. Open Radar 2.1 (QA/DEV) Issues Which Should Hold Up the Release of 2.1 The live database (radar@triton) had no indexes on the DEFECT table after upgrading it. This was (at least) the second of fairly serious problems with the new alpha release of 2.1 being used in house. Ideally, Joe should aow{jrB U >K^l]a~+,-/0?@V^$7s.[ 7  !;<GHVWPQRTcwg*R!:!, !!,!!,!!,!!,!!!:!!!!!!!!!!!!!!! h 4h'RxqArR+_K+-0@!!!!!,!!, h 4hK@Normala 4`4 Heading 1&T(T/(Uck.`. Heading 2<& ' ( ) "A@"Default Paragraph Font! !  7s,Y 2   t 78CDT*w+$Z%]B!:!,!!,!!,!!,!!,!!:!!,!!!,!!!,!!:!,!!!!!,!!,!!!!,!!,!!!,!!,!R@* Joe KueflerC:\DOCS\RIDGEW~1\RADISS.DOC@ga  ga     s t 8CDST  +!,y-</0?@O*1Times New Roman Symbol &Arial"h*&*&o`6Open Radar 2.0 (Field) Issues Which Need R&D Attention Joe Kuefler Joe Kueflerdid at PhaseForward to nail down the long Description crash), but Amisys is not local. Joe has not spent a lot of time on this yet, since this phenomenon is just starting to become an issue in the field. TS Call # 47347 (ProBusiness) / Bug # 23163: Radar crashes during login with a Functional Sequence error This is related to the long description problem which showed up in the field and which Joe debugged at PhaseForward in Newton. We cannot reproduce this problem at Segue, but it is occuring at least three customer sites. Joe thinks he knows the fix and Jim may have made the code change, but Joe should review the code and then to send a patch (or 2.1 beta) to the various sites who are experiencing the problem. Open Radar 2.1 (QA/DEV) Issues Which Should Hold Up the Release of 2.1 The live database (radar@triton) had no indexes on the DEFECT table after upgrading it. This was (at least) the second of fairly serious problems with the new alpha release of 2.1 being used in house. Ideally, Joe should aow{jrB U >K^l]a~+V^7s.[ 7  !;<GHVWPQRTcwg*R!:!, !!,!!,!!,!!,!!!:!!!!!!!!!!!!!!! h 4h'RxqArR+_K+!!!! h 4hK@Normala 4`4 Heading 1&T(T/(Uck.`. Heading 2<& ' ( ) "A@"Default Paragraph Font&! !  N&O7s,Y 2 &!:!,!!,!!,!!,!!,!!!:+R+* Joe KueflerC:\DOCS\RIDGEW~1\RADISS.DOC@    X  %&  *1Times New Roman Symbol &Arial"h*&e*&l`6Open Radar 2.0 (Field) Issues Which Need R&D Attention Joe Kuefler Joe KueflerRoot Entry F ޚCompObjnWordDocument"u*ObjectPoolII #$%&'()*+,-./0123456!SummaryInformation(  FMicrosoft Word 6.0 Document MSWordDocWord.Document.69q Oh+'0 D h   @d C:\MSOFFICE\WINWORD\NORMAL.DOT7Open Radar 2.0 (Field) Issues Which Need R&D Attention Joe Kuefler Joe Kuefler@"@ Mw@u@]Microsoft Word 6.020`6Open Radar 2.0 (Field) Issues Which Need R&D Attention Joe Kuefler Joe Kueflerܥe3 4e+u*&&&&&&&(&'(((( (()1 ( ( ( ( ( ( ( (J(L(L(L(L(L(L()T*`j(&& ( ( ( ( (j( (&& ( ( ( ( ( (& (& (J(&&,&&&& (J( (* (Open Radar 2.0 (Field) Issues Which Need R&D Attention TS Call # 47809 (Quark): Bizarre read only row phenomenon Quark is doing nothing special and nothing wrong. Despite this, a certain subset of their bugs entered via the web manifest a strange behavior. No matter what change is attempted on these bug records (from the win32 client), the change does not stick and is lost at commit time. Once a bug record manifests this strange behavior, it will always manifest it, until the entire database is dropped and rebuilt off either RXF or through copy database. Ive completely run out of ideas on this one. They are really strapped. Most of their bugs are entered via the web interface from foreign offices. Im scared that there is something really wrong with RemoteEntry which is just now showing up. Joe has already spent about 6 hours on this issue and the QA person at Quark (Doug McPeek) has probably spent 20. Joe needs more time. TS Call # 46753 (Gelco): Win95 machines are performing 18 times slower than their WinNT machines Gelcos Win95 machines seem to be identical to their WintNT machines, but radar is unusable on them. It takes a user about two minutes just to log into Radar. Joe has already spent about 8 hours on this issue and needs more time. TS Call # 47655 (Siemens): Unexpected Crashes Siemens is really frustrated with Radar. They want to return the product. They say it is too unstable and crashes too much. Joe is working with Sharon Rozines (on site at Siemens) to isolate steps to reproduce one of the crashes, but Joe does not have enough time to deal with this issue properly. TS Call # 46487 (HBOC/Amisys) / Bug # 22702: Radar crashes a lot when doing things too quickly Enough people in the field and internally have witnessed this first hand to refute that it is pure emotion. There seems to be some growing instability in ODBC. Each time a new ODBC application is installed on someones PC, the ODBC files (8 total) are potentially altered and various versions of ODBC may be creating problems for Radar. We fear that this problem will continue to manifest itself at more and more sites. It seems to be getting more and more common. This will takes days to isolate and analyze. It would be easier if someone was on site at Amisys (like Joe did at PhaseForward to nail down the long Description crash), but Amisys is not local. Joe has not spent a lot of time on this yet, since this phenomenon is just starting to become an issue in the field. TS Call # 47347 (ProBusiness) / Bug # 23163: Radar crashes during login with a Functional Sequence error This is related to the long description problem which showed up in the field and which Joe debugged at PhaseForward in Newton. We cannot reproduce this problem at Segue, but it is occuring at least three customer sites. Joe thinks he knows the fix and Jim may have made the code change, but Joe should review the code and then to send a patch (or 2.1 beta) to the various sites who are experiencing the problem. Open Radar 2.1 (QA/DEV) Issues Which Should Hold Up the Release of 2.1 The live database (radar@triton) had no indexes on the DEFECT table after upgrading it. This was (at least) the second of fairly serious problems with the new alpha release of 2.1 being used in house. Ideally, Joe should review the SQL statements (via debug.log) which are involved in the 2.0->2.1 upgrade steps and/or review the upgrade CPP logic. There are numerous issues which Bob may not have taken into account ranging from: dealing with indexes properly to avoiding the statement alter table on large tables such as DEFECT. Lyle believes that the new alpha 2.1 release being used in house is generally unstable. Ideally, Joe should review all the changes made to the CPP files. This could be coupled with continued education on the code base to Jim, Lyle, and/or whomever is appropriate. Crash a Login There are a number of mystery issues which are creating problems in the field. These mystery issues should be understood better before shipping 2.1 so that if we can make any changes to the code in order to eliminate them, we do this right away. Why Radar 3.0? Elimination of ODBC Who would have ever guessed how difficult ODBC would be to deal with, once Radar was in the field. The basic 8 files which make up ODBC get reved on a PC each time someone installs another ODBC application. This creates problems like: sudden and unexpected crashes read only recordset errors busy with previous HSTMT errors Functional sequence errors The problems are becoming more frequent and more obscure. Because of the fact that there is so much stuff in between the application and the actual RDBMS, it is extremely difficult to debug these problems and everytime one of the ODBC DLLs gets reved, its anybodys guess what is coming down the pipe. Elimination of Openlink What a rats nest. Openlink, the company, is a complete mess to deal with. Openlink, the software, was not all that bad until it became evident that their software needs to be relinked each time you install it at an Oracle site. If we had understood this, we would never have gone this route. Eliminating All Middleware in General Replacing Openlink with one of their ODBC driver competitors is not a solution. We need an architecture which does not rely on any 3rd party middleware. When other vendors own things in between the application and the database, two things happen: we inherit all the problems in the middleware product we lose the ability to debug the middleware and even our application from the perspective of the middleware (which often has an execellent vantage point) Interface with Configuration Management Software Numerous sites have requested integration with a source control/configuration management system. We would want to implement against the Microsoft SCC interface, which is proprietary, but which Segue has access to. This would give us most of the source control packages out there, including ClearCase and PVCS. New Architecture to support LiveQuality Needs APIs for LiveQuality to insert bug records after a scenario fails Ability to track issues back to a Requirements Document APIs for LiveQuality to escalate runtime alarms into Radar Minimum number of seats will stress the current architecture: the APP_MONITOR table which controls semaphoring and concurrency issues needs to be in memory Thin Client in order to make a Java Client possible The current architecture would not support a Java client: either in a browser or run as an application. We need to make the client thinner so that a 100% pure java client is possible. Ability to Keep Pace with new database revisions We currently do not support Oracle 8.x nor any version of Oracle on NT. Both of these realities have clearly hurt sales. Oracle 8.x has been out for over a year and Oracle on NT is a big competitor to MS SQL Server on NT. Open 2.0 Issues Each of the serious open 2.0 issues should be clearly understood before 2.1 gets shipped. Each of them listed (on the prior page) could turn out to be the tip of an iceberg.