[vwnc] Preferred format for bug reports

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

[vwnc] Preferred format for bug reports

Andres Valloud-3
Hello,

With some exceptions, I am picking up AR reports from VWDEV and VWNC.  
It makes my life somewhat easier when the reports look like this:

Brief description: short, preferably one sentence.

Version: 7.5, 7.6nc, etc.

Severity: one of Low, Medium, High and Critical.

Description: a detailed explanation of the issue, optionally a stack
dump, and so on.


Please note this does not mean we will ignore any other report.  It is
just a preference :).

Thanks in advance, and happy bug hunting!

Andres.
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Reply | Threaded
Open this post in threaded view
|

Re: [vwnc] Preferred format for bug reports

Steven Kelly
Good idea, Andres! Many other products with active developer communities
have an online bug report system. The information is then filled in
correctly in the right format, the bugs can be followed by the reporter
and other interested customers, and customers know when submitting a bug
that the information they submit will be public to the community (maybe
not the world, if the system requires a login).

I have been told that problems with customer information privacy are the
main reason why Cincom's internal system for AR tracking has not been
made public. If it were possible to mark information in that system as
private, all existing ARs could be marked private, and new ones could be
public by default. New attachments of customer code or comments could be
marked as private by the customer, if he thought it appropriate.

Of course, the main thing is not the system, but that the bugs get fixed
and into releases. Aside from the obvious benefits to product quality,
this also means that long term customers can cull their accumulating
mass of overrides that fix VW bugs.

All the best,
Steve

> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]] On
> Behalf Of Andres Valloud
> Sent: 06 August 2008 11:29
> To: [hidden email]
> Subject: [vwnc] Preferred format for bug reports
>
> Hello,
>
> With some exceptions, I am picking up AR reports from VWDEV and VWNC.
> It makes my life somewhat easier when the reports look like this:
>
> Brief description: short, preferably one sentence.
>
> Version: 7.5, 7.6nc, etc.
>
> Severity: one of Low, Medium, High and Critical.
>
> Description: a detailed explanation of the issue, optionally a stack
> dump, and so on.
>
>
> Please note this does not mean we will ignore any other report.  It is
> just a preference :).
>
> Thanks in advance, and happy bug hunting!
>
> Andres.
> _______________________________________________
> vwnc mailing list
> [hidden email]
> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Reply | Threaded
Open this post in threaded view
|

[vwnc] AllEncodings: Bug?

Mike Bielser
Hi
I loaded the parcel AllEncodings into a "virgin" VWNC 7.6. The release notes for VW 7.6 say

"First, open the workspace; you'll see a lot of black rectangles. Then load
preview/unicode/AllEncodings.pcl and instantly the workspace will update to display all the unicode
characters that you have loaded. You can copy and paste text, for example from MS Word to VW,
without problems."

The first part (display updating) works; the second part (copy/paste) however didn't completely work
for me: Using the debugger, I verified that copying to the clipboard worked, but pasting (to a
different workspace sheet or MS Word) didn't work. Debugging revealed that


Screen>>getExternalSelectionIfEmpty: aBlock
"Get the host selection as a String from the window system, or perform aBlock if none is available"

^(self getExternalSelection: nil) ifNil: aBlock
        ifNotNil: [:sel | IOAccessor convertStringFromPlatform: sel]


is the culprit. Changing the body to


^(self getExternalSelection) ifNil: aBlock
        ifNotNil: [:sel | IOAccessor convertStringFromPlatform: sel]

worked for me. In other words, one has to make sure that Screen>>getExternalSelection gets called
(that's where the unicode stuff is) instead of Screen>>getExternalSelection: nil.

Maybe someone else can verify this so Cincom can fix it; maybe it's just me and my computer...

Mike

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc