World: r3wp

but in the meantime use stuff as it is .... and not delay by forever 
rewriting tools

All of this is to be done by this week.

yeah delay is the prob currently

Carl wants to release R3 ASAP.

this week ? whoaaaaa, it might be a dream

thanks for the report Graham

is the next alpha release included in (this week) ?

So, pehaps people can make suggestions for a BBS ( needs tags so 
that Carl only need to filter by tags to read what he needs to read 
), and good spam fitltering

All of this needs to be up and running so that we can receive feedback 
for R3

The move now is to get as many eyeballs on R3 as possible ... but 
we don't want to lose the feedback

So, I think the idea is not to release R3 as a finished product ...

yeah but at first, you will get enough feedback from Altme community: 
so give us a release

but to get more betas out

no problem is it's not finished , just give us material

there is work to do .... doc has to import all the tickets from Altme 
bug tracker into curecode

*if

I hope we are moving to a more pragmatic approach now

Hg is also being adopted by Qtask ... so it seems a good choice

Users can download tortoiseHg now to get some experience

good news because some reboler i know getting nervous breakdown (including 
me)

Of course it's just intentions ... we need to be sure it all happens

arghhhh.... give me a rope ;-)

well well, i o

.... only hope it's not a joke....

http://tortoisehg.sourceforge.net/

looking at current description of Rebbrowser I am far from satisfied. 
I can already imagine how ugly the default interface is going to 
be. It seems to me like a concept without deeper thought. Buttons 
as forward, back, are the most flawed concept of the web, with very 
negative effect for the web apps ...

Why don't we just use Tortoise SVN? Some ppl know it from RebGUI 
project. Is SVN any less functional?

Not distributed

Why do we need distributed?

IMO rebrowse should be far away in our todo list. So much core capabilities 
was missing in the first R3 released.

When i read that for Carl, [parse] evolutions must be downsized the 
most as possible (while I believe this is one of the most important 
functions 

in Rebol), i have still some doubts how priorities are well defined.

It has been said by many rebolers all over the past, the Killer app 
should be an IDE (including code editor, screen designer and other 
wizards).

It the only manner to encourage new groups of developper in starting 
huge projets with Rebol.

Distributed version control is far superior over the classic schemes

SVN is hardly an upgrade over CVS

TortoiseSVN on Windows XP has been a nightmare: the more you checkou, 
the slower XP Explorer runs until you uninstall.

RapidSVN has worked flawlessly for anything that was not convenient 
on a command line

TortoiseSVN: Good name then. :-)

There are many advantages to using a distributed vcs, all variants 
on a theme. For example:

- You can track changes within your own code without submitting it 
until it is ready.

- It is easier to collaborate with other people without having to 
put your changes into the central repository.

This makes it easier to make large changes with the help of other 
people, and is why I suggested Mercurial over CVS.


The problem with all of this is that the main purpose of DevBase 
isn't source control, it is managing development workflow. No other 
vcs handles the workflow management function of DevBase. Without 
the workflow management Carl can't manage contributions.

Yesterday I came up with a way to change the DevBase model so that 
it would keep (and enhance) the workflow management functions and 
still get most of the benefits of a distributed vcs. Yes, it would 
depend on making the DevBase client a reblet run by the browser above, 
but that would be a bonus for R3 anyways.

Pekr, the navigational functions of web browsers are what makes the 
web work so well. You shouldn't misjudge them by the way that some 
badly designed web apps don't take them into account. We will still 
have the ability to create regular aplications in R3 when the browser 
model doesn't work for you.

Steeve, the reasons for minimizing the parse proposals are given 
in the proposal doc, but they boil down to these:

- Clean, simple and powerful is not only the REBOL way, but more 
efficient at runtime. It's the greatest strength of PARSE.

- PARSE is only one dialect of many in REBOL, and they are designed 
to be used together.

If anyone wants to discuss the source control and workflow management 
of the R3 project, mention it in the !DevBase group here.

BrianH: so which of parse proposals will make it into?

Don't know yet. I know my preferences - should I put an Editor's 
Note in the Priorities section?

Don't know - it makes sense, only if Carl takes the list of priorities 
seriously. Maybe he has his own opinion and will choose to implement 
according to his own priorities ...

I haven't edited the priorities section at all - I figured that was 
Carl's job. I should take a look at it. The trouble is, I don't know 
whether Carl has already started work or whether he has put it on 
hold in order to get a developers' release out ASAP.

Henrik claimed Carl is working on parser for one week or so :-) But 
maybe he just guessed?

I would prefer public relese, and continuous, incremental releases. 
But - can it happen without CVS?

Is there any conclusion to it? Will it be Mercurial? Hg? DevBase?

No conclusion yet, discussion continues in the DevBase groups.

Mercurial = Hg