World: r3wp

It would be a lot easier to just use fields according to their lable 
:-)

I try to not do this all the time as it gets tiresome, and at some 
point the UI problem will be fixed.

I *do* use the fields according to their label. Severity is severity. 
The severity of the user's problem can't be explained without context 
- a field would be useless, you have to give the context in the description 
or comments. The severity for the developers can be expressed in 
a field though, as the context is just the language itself.

As I said, I'm OK with adjusting it to a standard. But that would 
still be severity to the overall community, not severity to the developers. 
Nobody is interested in that

Except the people actually using CureCode to determine and plan fixes 
and changes. The people to whom those fields matter.

You're reversing the meaning of the field by changing it from severity 
of the inconvenience of the bug to severity of the inconvenience 
of the fix

Severity of the change, not some measure of inconvenience. That is 
the main thing that can stop a ticket from being implemented at all, 
the most important field in that group. You are acting like developers 
of the language are more concerned about their own convenience. You 
know that is not the way we work.

That is exactly what I'm telling you. I'm merely asking you to try 
to think for a moment from the perspective of the users you're asking 
to report issues, instead of your own perspective

We are in design mode, and for CureCode as well apparently. All tickets 
are important, or else they wouldn't have been reported.

Come on, then you should just remove the field

If you want to keep explaining yourself to unsuspecting users, I 
apparently can't stop you

We need to break it into two fields. One for the users to report 
their damage, one for us to use for determining the severity of the 
problem (whatever you want to call that). The user damage field wouldn't 
help us much in the process of fixing the user's problems or satisfying 
their requests, but users apparently expect one. We would get the 
real info from the summary, description, example code and comments, 
same as we do now. Without those details the importance of the fix/enhancement 
to the user is impossible to determine, but with those details we 
can really work on the user's problems and understand their priorities.

Keep in mind that I am not suggesting that this be called a "user 
damage" field. I think that it shouldn't be called "severity", because 
that only applies to bugs and issues. Perhaps "importance" would 
be better, as it applies to notes and wishes as well.

We still don't have a good way to set priorities in CureCode though, 
for planning releases. We have to do it manually. The CC priority 
field is OK for general priorities, but not for our priorities because 
our priorities vary from release to release, depending on what area 
of the code we are focusing on.

If a user lables a bug as "crash", that's significant enough, and 
Carl always wants to fix those first

Yeah, the importance field should definitely have crash and block 
importances.

And we reviewers would occasionally raise the importance if the submitter 
underestimated it, such as when it affects more users, or when it 
is a *really* good idea :)

The crash and block settings are the odd ones out of the current 
severity field. They should be moved to the importance field.

Version 0.9.12 sources package released: http://curecode.org/dl/curecode-0912.zip

I've changed the format of the GUID field in RSS feeds, so you'll 
get duplicate entries for the recent changes, just ignore them or 
delete the old ones.

There was a 5h outage on curecode.org affecting cheyenne-server.org 
and softinnov.org. It has been fixed just a few minutes ago.


After short investigation, it seems that a PHP internal issue (frozen 
process) caused a fatal error in Cheyenne main process. The error 
is very weird, see below the disarmed REBOL error :

make object! [
    code: 301
    type: 'script
    id: 'need-value
    arg1: evt:
    arg2: none
    arg3: none
    near: [evt: do-events 
        either none? evt
    ]
    where: 'do-cheyenne-app
]


So, DO-EVENTS (which is basically just WAIT [ ]) returned an unset! 
value. Does anyone know here if this a known behaviour or a REBOL 
bug?

I've never seen this.

any update on adding the R3 GUI as a project to curecode?

R3 GUI project added to CureCode, ticket http://issue.cc/r3/1837
moved to R3 GUI.

I've added alpha 110 & 111 to versions list, let me know if you need 
categories too (I would need an ordered list of items for that).

Great, thanks.

cool :-)

Sorry for the delay, I forgot about it until Henrik mentioned it 
again yesterday.

it's ok. now we have it. :-)

Doc, can you create a CC login for me please. Thx.

You have one already.

Loginid Robert.

Also Robert-Muench (another login)

:-) Good to know... let's try if I remember my password.

I don't know if there is a password recovery service; why don't you 
find out?

Ok, worked.

password recovery service
; sure, from home page -> Reset Password link

Doc, I am interested into using your product for tracking bug of 
other applications but we need Project and Subproject. Is there any 
plan to add subprojects ?

There's no "subproject" concept in CC, but you can use "category" 
field to divide a project. I have no plan to add such feature this 
year.

http://issue.cc/r3/1027

The state of the ticket should be revised

Doc, a little thing: the title.inc file for 0.9.12 needs to be updated. 
Or perhaps, the zip file is really .11. In any case, still a great 
app.

The ZIP file is 0.9.12, I left an older file version when I built 
the 0.9.12 archive. Issue fixed and 0.9.12 archive re-published. 
Thanks for reporting this issue.

NP ... get back to RED.  :-)

James: sure, I did that during my coffee break ;-)

Doc, I still have issues with the cookies created from Curecode. 
Essentially, when I leave the browser open and the session expires, 
the next time I try to use curecode, it loads up the error page. 
I just manually delete the cookie and I'm good and I have extended 
the timeout as well which helps. I was wondering in the httpd.cfg 
file if there is any value for curecode's timeout that will make 
it endless (perhaps "none" ? ). Thanks. It is a very usefule app.

There is no endless timeout value. Such feature would blow up the 
server's RAM sooner or later.

the next time I try to use curecode, it loads up the error page.

 Could you be more specific? On what page do you let the browser open? 
 What do you do when you resume your work after the session expires 
 (on what link/button do you click)?

I'll have to verify when it happens again but I think it's the "Sorry. 
this page cannot be displayed." And any link clicked will cause this 
to come up.  Doc, this is not super important because changing the 
timeout helps. I'll wait until it happens again and give you better 
details. How's that  sound?

Besides, no one else seems to have this issue so it could very well 
be something on my side.

Thanks, that would help, as I tried several times to reproduce your 
issue without success. By the way, what browser (and version) are 
you using?

Do you have a browser plugin or any other tool installed that could 
remove or alter in any way your browser cookies?