AltME groups: search

On a related note, do you think it would be possible to export from 
RAMBO to CureCode?

Numbering: that's one central question. Currently the numbering is 
global to all projects for a given CC instance. When I made the first 
CC version, I wanted to follow the Mantis application as much as 
possible while make things simplier. I wasn't sure if the numbering 
should have been global or local to each project. Now, I think that 
I used it long enough to think that the local numbering is more natural 
and user-friendly. I'd like to switch to that local numbering in 
a future CC release while keeping the global numbering as an install 
option (for Mantis users and for migrating Mantis databases).

How is the information stored? Can you switch to a composite key, 
or an additional projectid-readableticketid key?

I was thinking about keeping the current ticket number as a "technical" 
number for external references and moving between projects while 
providing a local numbering in the UI (with the option to reference 
a ticket by its local number+project ID, or by it's absolute and 
unique internal ID). I feel like maybe it would be overcomplicated 
and not worth the effort?

CC data model : http://softinnov.org/dl/DB-schema.png

Yes, it's possible to switch to a composite key (ID+project or project+localnumber), 
but I often rely on a unique key (even if it is for internal use).

It may be confusing if we start a new project now, in the R3 CC instance, 
the first ticket would be #844...looks odd.

if you use external uid tables, you can have a dual id... the ticket 
global uid, and the projects-related id.

A table containing reproducibility qualifications :
	('Always'),
	('Sometimes'),
	('Random'),
	('Have not tried'),
	('Unable to reproduce'),
	('Not applicable');

<local numbering in the UI>

A project specific number as well as an internal UUID will be most 
flexible.
Think of cases when you may want to:
-- delete a project, and then later re-instate it
-- import a project from somewhere else

-- have the project database running decentralised across several 
loosely-coupled machines

-- have a project database that (for whatever reason) gets forked, 
and then needs to be merged back into one.


At the user interface level, all I should ever need to know is that 
issues are numbered sequentially from 1 for that project. How you 
implement that internally should be invisible to me.

Except that the tickets are referenced by human-written numbers from 
inside and outside CureCode. Inside is no problem - just assme the 
samme project. Otside is a problem unless some kind of project reference 
is included. An example of an outside reference is the bug#794 style 
referencing in R3 chat, or the get line referencing elsewhere. It's 
easy to add a project reference to get line stuff, but harder for 
bug#794 referencing.

I'm pushing the new v.0.9.8 in production, it shouldn't need to restart 
Cheyenne, but if someone (e.g. BrianH ;-)) is writing a long text 
in CureCode, better save it right now.

For users having a session running before the upgrade, you should 
terminate your session (logout or restart browser). The session content 
has been changed, so you'll get some page errors if you keep using 
your old session.

When I did a search for "return", I got duplicate entries in the 
results. If it matters, I was on the "Recent Changes" preset beforehand.

Good hint, looks like a SQL grouping issue.

Wait, that last one is not true. I found a dup tested.

Duplicates issue fixed. It was a SQL error : DISTINCT COUNT(id) instead 
of COUNT(DISTINCT id).

Re "block": it should be considered from the user POV. It means that 
the feature is not available because of the bug and that there's 
 no workaround. It's higher than "crash", because a crash can have 
workarounds, giving you access to the feature using other ways.


Example: if "make vector! [4 10]" crashes but not "to-vector [1 2 
3 ...]", it should be marked as "crash", there's a workaround for 
using vector! values. If both were crashing, the issue should be 
marked as "block", because, there would be no way then to use vector! 
datatype.

Henrik: "An alternative would be to blank the list when switching 
mode. That perhaps will lead the user to see that an action needs 
to be done to display a list that corresponds with the search query."


Sorry, couldn't fix that in this release, it's much more complicated 
to fix efficiently than I expected first. I should maybe try to clean 
the  result list using Javascript...will see that later.

I'll see if I can adjust that a little.

I'm trying to change ticket 820 from an issue to a bug, but I get 
a server failure.

Issues fixed. It was caused by a conflicting library version from 
another webapp running on the same Cheyenne instance. Should be ok 
now.

Verified fixed. Apparently the failed attempts were partially completed, 
so the history is a little messy on ticket 820 now :(

What do you think of the subject matter of the bug? Do you think 
it's a good idea?

I would whole hardedly welcome explicit binary and string parsing 
differenciation... in fact for some tcp server stuff, I know for 
a fact that if R3 doesn't have binary-specific parsing, its going 
to create a BIG hole in rebol's capabilities, or make it very complicated.

For example while parsing binary! and I use [1 skip] I want to skip 
1 byte only, not a unicode char which can be on more bytes.

it is better currently than in R2, because you can use the same rules 
to parse a binary or a string of the same content.

No need to have different rules, so no need to wast memory using 
useless conversions  with to binary!/string!

It's a counter? Interesting - that explains why only one ticket was 
affected.

The counter is here just for speeding up the main SQL query (saves 
a costly sub-query).

I think a new bug type or severity which indicates a ticket being 
reference for documentation could be usefull.  some tickets start 
out as bugs and become examples of use or help in detailing non-obvious 
cases of some features.


setting a ticket as dismissed and not a bug, clearly means that it 
will be ignored in the long run, and rememebering what tickets are 
usefull and can be included in reference documentation when such 
a time occurs would be usefull... it could even allow us to search 
the bug database directly for strange reactions we might consider 
bugs but were pointed out as features or gotchas.


the "not a bug" severity  is similar, but doesn't relate if the post 
is usefull or not.


bug#928 is an example where this could be applied.  I am sure there 
are others.

Ladislav: a compliment coming from you is always greatly appreciated, 
thank you.

Max: maybe a tagging system for tickets would be a good addtion?

there is a sql problem in %build-db.sql file, when I try to execute 
the statements, the last statement gives an error.

yes tagging is an even better solution. it could even replace much 
of the current fields, if done associatively, using a two column 
tag -> id  table..

BrianH: I'll add that. I'm working on fixing a few UI issues on CureCode 
(mainly on stats page).

BrianH: noone wants distinction between dismissed and completed being 
removed, it could be subgrouped. But that way, it is a bit difficult 
to quickly get clear view, of how many tickets are being regarded 
being finished, and with how many tickets there is a chance someone 
will look at them, correct or implement. Simply put - when I looked 
at Carl't graph, it gave me clear status of overall R3 development. 
6 months CureCode status is no clear indication about the concrete 
state of the project.

I agree with Pekr about the need of a simple and global graph.

Weirdness on http://curecode.org/rebol3/: Twice today I have noticed 
people changing descriptions of tickets after they were reviewed 
or tested, people who don't have admin privileges, afaik. Has there 
been a change to CureCode recently, or have new admins been added?

Hmm, the stats page has been removed a week ago waiting for fixes. 
That's the only change done recently.

I've done a lot of fixes and improvements on the stats page so I'll 
put it back online tomorrow. I've also pulled CureCode out of the 
quirk rendering mode, so a lot of CSS have been changed to keep the 
look as it should be. The result is an improved CSS support for Gecko 
and Webkit, but I gave up on IE8 (can't fix table inner borders).

It looks to me that the only way for proper table border rendering 
in a cross-browser way is replacing them with DIV tags.

I would like to propose some enhancements:


- having to manually always select particular ticket-view category 
and project name in changelog section, becomes kind of denerving, 
once you have to do it several times a day

- hence I propose to extend user-profile settings, where we can preselect 
such things. If it is more complicated effort, I vote to change default 
ticket view from "my tickets" to "most recent reports" one

Pekr: I'm looking at thoses features to see if I can add it easily 
now (or postpone it in a future release).

I noticed that the first category in the list gets selected by default, 
so I cleared the list and added an Uncategorized category first then 
readded the rest of the categories back. Later I came up with more 
categories to add in the middle. Eventually I had to give up for 
a while - too much work.

It would be easier if the order in the dropdown list was a separate 
field from the order added, then add little up/down arrows or something 
to the management page. That way you can rearrange the dropdown list 
without needing to recategorize tickets.

Having a default Uncategorized category (however you want to name 
it) would help too.

CureCode will be down for a few minutes from now for upgrading files 
and the database.

Upgrade done. If you had a previously opened session on CureCode, 
you have to close it and log again.

For a long while, "Most Recent Reports" and "Recent Changes" produced 
identical results here, but works properly now. Is that part of the 
fixes above?

is there a status on the API?

I might give it a shot at some point. We also need an R3 native client 
to connect to it eventually, so I might want some practice.

Today, CureCode on Chrome looks like it does on Firefox: No extra 
padding, white grid separators, nice. Must have been a cache issue 
yesterday. Good work, Doc :)

Nope, the schema was changed a little for R3 specific needs.

If a new project is created, does that go into the logs table?

That's a typo, it should be INT(16).

If so, then when several fields of a ticket are changed at once, 
does that generate several log entries in the logs table?

Yes, each field changed generates a new log entry.

API hasn't changed. Do you have an example URL? I don't see any difference 
in column order. Btw, I've just released a fix for a bug in the type=ticket 
mode throwing an error if the 'fixedin field was none.

For CureCode users: do you guys think that a project-wide timeline 
page like the following one would be useful? http://www.sqlite.org/cvstrac/timeline

looks to me that curecode 098 is hardwired for the R3 bug list. there 
is a ton of references to R3 in it.

Ah, only the database name is r3bugs. I think it would be relatively 
easy to move into a config?

possibly better to use column names than a values block.

I presume you can't insert into a primary key auto_increment field

I think you should be able to, otherwise you wouldn't be able to 
use VALUES on a table with a primary key

one would think, there would be a login to the database somewhere 
in the code. can't find it though. there is one in some test files 
and in the installer.

this was also present before I changed the httpd config, so there 
must be a different error somewhere.

so that you have a validated session?

just [root-:-localhost], but I don't think this is a database problem. 
it's more fundamental.

aren't you getting a message about the browser doens't understand 
?

(could use a phpinfo() like page)

Try a probe system/product to see if View is there.

it looks to me that Curecode is a webapp, due to the presence of 
an app-init.r file, so I'll have to find documentation on how to 
describe it as such

now I'm trying to add a project, but on the index.rsp page in the 
manage section, I get:

URL  = /bugs/manage/index.rsp
        File = www/bugs/manage/links.rsp

        ** Script Error : Invalid path value: clear 
        ** Where: rsp-script 
        ** Near:  [response/clear 
response/redirect request/web-app
]

there is no response/clear in the docs, so I assume this is a newer 
cheyenne feature?

that helped. now to create a user account...

response/clear => you've found a bug, it's a typo, as Will says, 
it should be response/reset. (now fixed in 0.9.9).

Did you removed the admin user creation from the install script? 
You need that admin user in order to create new projects and manage 
them (the bug you just hit is in a code branch that is evaluated 
only if a non-admin user try to access manager pages).

I'm sorry that the install process is not more handier, AFAIK, you're 
just the 2nd user (after Graham) trying to install CC. I guess that 
I can call that a "community" and start working on a nicer install 
process. ;-)

now a new error... possibly mail related.

This line in the webapp declaration should remain with a relative 
path : locales-dir %private/locales/

Try with an absolute path for root-dir. I remember having hit the 
same issue once a long time ago, but can't remember the fix.

I think it would be a good idea to create a set of sanity checks, 
to check that the webapp paths are correct and that the right rebol 
version is used. that would be the easiest way to improve installation.

Successfully sent mail from a rebol command prompt, but it doesn't 
work in Cheyenne, despite identical set-net config. Odd.

If I'm right, sending mail only happens in the helper.r file. But 
even if I try to make an error well before the actual mail sending 
happens in 'send-confirmation, it still returns a tcp error. It seems 
I'm not hitting the right place in the code.

it's probably a permissions problem

There used to be a tracker at http://softinnov.org:8000/curecode

yes, I thought I could make an error! earlier in that function, but 
I still get a TCP error.

oh that's it. I just need to fill that function up with debug/probes 
and it works. :-) got a mail now.

v0.9.9 is a little bit better for management.

I'll make a package asap, so you can upgrade.

yes, BTW, there are many places where the word REBOL3 is hardcoded 
in strings. I was wondering if it's a good idea to move that to the 
config? It seems obvious for customization.

I would have said that CC's current install process is a real PIA 
;-)

I think we unearthed a lot of things that we otherwise would just 
bump into along the way, anyway. I'm still not safe on the email 
issue, as the debug lines are still present.

Ok, submitted a ticket!

I'm working on an integrated client Mail Transfer Agent that will 
handle emails sending in Cheyenne without the need to install any 
third-party mail server. It should be ready in a couple of days.

Transparently for the user. Internally, like a normal MTA, getting 
the right MX, queuing outgoing emails on disk, retry sending a few 
times if required, inform back user (and admin optinaly) by email 
if sending failed.

only a couple of linest to make that into a mta :)

Doc - does Cheyenne already enable setting handlers for particular 
filetypes? I mean - equivalence to:

AddHandler rebol-cgi-dispatch .html
Action rebol-cgi-dispatch /cgi-bin/rebol-cgi-dispatch.cgi


For Cheyenne only users, it is not important, they can use RSP, but 
for those who want to have chance to migrate between Apache and Cheyenne 
in CGI mode, it might be usefull. I expect it not being a priority 
for you though ...

Would it be possible for a developer to have his reports automatically 
reviewed? There's a lot of extra clicking involved for me in my curecode 
since I submit reports to my own tracker.

It would be really lovely to have change log information provided 
via API or plain text, so it can be integrated into a website.

I had a lot of trouble with comments in CureCode today being hex-decoded, 
when I was just trying to refer to a filename %bar.r. I had to write 
it as %25bar.r, every time, even during revisions. Comments shouldn't 
be hex-decoded.