World: r3wp

Ok, reproduced with Chrome.

Works Ok with IE7 and FF. Looks like Chrome is more sensible on multiple 
redirections.

I don't like to clear the cookies an my primary browser - I end up 
having to log into a ton of sites. I can't clear just one site's 
cookies.

an -> on

You don't have anymore, it looks like it's not related to old session 
cookie afterall. At least one ticket is opened in Chrome's tracker, 
but not confirmed by developers: http://code.google.com/p/chromium/issues/detail?id=1267

...have <to> anymore...

Cheap workaround, go to the second result ticket, then use the Previous 
[<] button.

I'll see how I can avoid the extra redirection for the first ticket 
in the next release.

[Logout] link doesn't seem to work with Chrome too.

I'll try upgrading to a new nightly Chromium build and see if that 
helps.

From a design POV, Chrome is right, web servers shouldn't redirect 
twice for a given resource, but, sometimes, it really helps by reducing 
complexity and code size.

The problem is not the twice, it's that it keeps going. I do the 
reload to let it continue and it does, back and forth forever.

Strange, if you keep clicking on the [refresh] link, it loops endlessly, 
but if you click inside the address bar and hit Enter key, it works.

Looks like a Chrome bug.

Anyway, CC shoudn't redirect twice, that's bad design.

Great, I "upgraded" Chromium and now autocomplete doesn't work (anywhere), 
in addition to the redirect bug still being there. :(

I'll have to try upgrading it again tomorrow.

Figured out which build I used to have and am reverting now. I'll 
keep a copy of its installer, just in case.

Logout works for me though.

system restore??

Don't be silly. Most non-Microsoft installers don't set system restore 
checkpoints.

Are you saying that you don't have any system restore points at all? 
 Or that you don't expect to find one from just before you upgraded 
Chromium?

I'm looking at my latest restore points.  They are in order:

HP device driver
Imagistik Image Viewer
Quicktime
Windows Update

I don't recall what installer they used ...

1) No, I don't set system restore points, I've had to spend way too 
much time fixing people's systems from the damage done by system 
restore. Using system restore causes more damage than most viruses.

2) Chromium doesn't upgrade, nor does it make system changes outside 
of its own directory. Chrome upgrades, but still sticks to its own 
directory, not even the registry. To "upgrade" Chromium you delete 
the old application files and rerun the installer.

System restore only affects the registry and files in the windows 
directories, not program files outside of those directories.

Oh? So, chromium can be run without installation then?  eg from a 
usb key

Yes, but I use the mini installer because I prefer how it lays out 
the directories to the .zip contents.

Both Chrome and Chromium installers put their application files in 
a directory next to the user data directory under the user's local 
settings directory. Non-admin install, no registry access except 
for setting the file associations if you like.

Try here: http://dirhael.dcmembers.com/cnu

Doc, is the CureCode "feature" severity meant ironically, as in "It's 
not a bug, it's a feature!"? If so, it would explain why that severity 
is not available on the Add Ticket page, and I would have to rereview 
every ticket I put that severity on thinking it meant "request for 
a feature". I've been marking non-bugs as dismissed so far.

I've removed it from "Add Ticket" list from the beginning because 
we already had Type->Wish for feature requests. For the severity 
field in the filters or in the ticket, I can remove it too, or we 
can keep it for marking tickets as "it's not a bug, it's a feature". 
As you like.

Rename it "By feature" or something not ambigious

Please rename the "feature" severity to "not a bug", and I will review 
the tickets accordingly. I need a way to mark tickets where people 
are reporting as bugs deliberate changes in the semantics of REBOL 
from R2 to R3. We are trying to fix design flaws in R2, so some incompatibility 
is *intended* to happen.

The "not a bug" phrasing will let people fill in the rest of the 
phrase in their heads :)

BrianH: done.

Didec: if you can think of a better (and shorter) french translation 
than "pas une anomalie", I would take it.

Thanks. Affected tickets modified accordingly. Here's the new criteria 
for applying the "not a bug" severity:

- If the ticket is a Bug or Issue and the behavior is by design and 
intention, it gets marked as "not a bug" and dismissed.

- If there is some question, comments are added saying so and the 
ticket is marked as "waiting" or "problem", depending on whether 
the question is more of a group thing or a Carl thing, with some 
leeway either way.

- If the ticket isn't deep enough it will be rewritten to reflect 
the real problem, or maybe a new ticket will be made.

- If the ticket is too broad or general, it will be marked "problem" 
and split into multiple narrower tickets.

Once a ticket is dismissed, what is the proces for it getting to 
closed?

There are a number of dismissed tickets in the REBOL3 tracker. I 
presume no further work is being done on them. The statistics on 
the main page would look much better if they were counted as closed.

I think it would be better to exclude "wishes" from the front-page 
stats too. There are a growing number of them and as they are included 
in the stats they give the impression that there are mire bugs than 
there are.

The stats needs to be fully refactored to better fit CC/R3 specific 
status list.

Anything I can do to help?

Once a ticket is dismissed, what is the proces for it getting to 
closed?
 I have been wondering that same thing (I'm the reviewer).

Carl and been in a hole generating R3 documentation so he hasn't 
been available to make policy decisions, but that would be the job 
of Carl and the reviewers (just me right now, want to volunteer?). 
However, I think "dismissed" should be removed from the stats and 
current list just like "closed", since it is useful to make the distinction 
between them for documentation purposes.

I think it would be better to exclude 

wishes" from the front-page stats too" Please don't. All requests 
for new functions or options are marked as wishes, so we need to 
keep track of those too if they aren't dismissed.

Missing functionality is a bug too, though less severe.

I entered a bug report into the Rebol3 tracker and it got duplicated 
- #645 & #646. I don't think I clicked "submit ticket" twice though 
I may have accidentally double-clicked on it.


I tried to delete #645 and followed the sequence "edit ticket"->"delete 
ticket"->"confirm ticket" but it wasn't deleted.

Doc, two requests:

- Remove the value="" attributes from the username and password input 
tags on the login page.

- Filter out tickets with dismissed status from the "Active Priorities" 
and "Worst Severity" preset filters.
Dismissed should be considered complete - rejected, but complete.

Noted. I'll make these modifications this weekend.

Is the value="" removal request related to an issue you've experienced 
with Chrome?

The value="" disables saved passwords. I don't want to have to load 
up my password database if I am on a trusted computer that I can 
just let the browser track my passwords.

Good to know. Your fixes are built on my CC developer instance. I'm 
currently adding a few more feature/fixes before releasing.

BrianH, on 21-Jan 11:16 PM you said : "Do a server-side redirect 
to a get page when you go into edit mode on a ticket or comment update."


I'm not sure to understand the "server-side redirect to a get page" 
part. When you click on a ticket ID or comment [Edit] button, you 
enter in edit mode using a GET request. What would a redirect improve 
here? Is it related to the browser Back button and client cache management?