World: r3wp

Ok, so the subject of the discussion is how to move the host-kit 
build and its related processes to a more manageable method.

This is good timing, because I was just about ready to change the 
method anyway.

Andreas has some suggestions, and if we can figure out a good way 
to put this together, it would benefit most developers (at this level.)

Ultimately, it would also greatly benefit you.

Where I was going previously: for now, the only part that would need 
your direct involvement is the automation of an "export" from your 
"internal" sources to a set of "external" sources.

The export step should not be that difficult. The problem will be 
if developers modify auto-generated files.

So, do we have a good place to put this? Google code?

I wouldn't worry about that for now.

(which?)

Where to put this.

Unless you want to adopt a new version control system for your sources 
alltogether.

So, how do we want to go about doing this?

The important part is that you use _some_ version control system 
internally.

Same one for ten years.

Ok, second step is to use a single repository for all your builds.

BTW, I don't type a dot without version control.

I.e. a 'Linux" repository and a "Win32" repository where you manually 
do merges (or copy/paste) in between will only lead to trouble.

Back in a while. Go ahead and post your notes, then I'll reply. Thanks!

Quick Q: what version control system do you use atm?

Third step is to write a post-commit hook which exports from internal 
to external.

And then the automation kicks in.

The same post-commit hook then:

- moves the export to someplace public (i.e. another public VCS like 
Github or Google Code; or simply uploading them to rebol.net/rebol.com),
- and somehow notifies anyone interested of the new upload.

You'll get the notification for free on Github (I don't know about 
Google Code). But this could also be updating a simple .txt on a 
webserver somewhere which lists all available exports. Heck, it even 
the directory listing features of a webserver would suffice (as long 
as the exports are named consistently).

And from there on, we can have build bots which pick up any new export 
and build it for their platform. Build results are reported back 
somewhere (email, static website on the bots which gets aggregated 
elsewhere, a simple CGI, R3 chat, ...).

The details of those latter parts are not particularly exciting, 
as they are easy to do in a variety of ways.

For example, even the makefiles are not really important at this 
point.

But what's important is how to keep those "external" builds consistent 
with your "internal" builds.

Which is why it's also important to realise that those build bots 
need not necessarily be public. They could well be Carl's own machines 
standing at home which put the final binary in a central place for 
Carl to use.

If that's not immediate, you can obviously still use your own build 
stuff (Visual Studio projects, whatever), and as long as you regularly 
keep the sources up to date by committing, the builders will notify 
you anyway if the external build mechnisms got out of sync.

The most important thing to realize, is that not every commit, even 
if externally visible, needs to be perfect. It's perfectly fine if 
the external builders break, that's what they are there for: telling 
you when something went amiss.

A few comments...

I was expecting that all these various implementation parts were 
already available.  That is, we're not reinventing the wheel.

They are.

Next, is there any conern about flooding. On a good day, I make about 
10-20 commits.

Nope.

BTW, there are no merges between Linux and Win32 files.  These are 
all in the same repository.

So, all of the above seems pretty standard.

It is.

It just needs to be done for R3.

That's why I asked earlier about where we want to put it.... because 
that seems to be a bigger question.

http://www.rebol.net/builds/rebol3/alpha/

Call the exports r3-<datestamp>-<revision>.zip.

dinner. bbl

Or export into Git and put it on your server or on Github.

Or export into Subversion and put it on Github, or Google Code, or 
....

I think using Git is the way to god for a new project.   every big 
project I see that is changing VCS is goint Git.  it seems to be 
the most powerfull VCS right now.  do you agree Andreas?

god... hahaha 
obviously I meant  "go"

Absolutely.

And I personally would suggest Git, put that'll take time and effort 
to get started with.

So it's probably quicker to get things going by using whatever Carl 
is familiar with.

are there free Git servers?