The following lists my progress and few points for which I need clarification.

I created a git hub account (AndrewEdwards) and obtained necessary access to all repos at Access to the ftp is pending but should be granted shortly.

I've forked the following repos in order to comply with the Development_and_Release_Process documentation at and Nick Sabalausky packaging tool:

        dmd, druntime, phobos, tools,, installer

Following instructions at [1], I created a local repository prepared branch 2.065 in accordance with [2] for the forked repositories.

I've prepared a build environment on Mac OS X 10.9 with five VirtualBox images as follows:

        1) Mac OS X 10.9
        2) FreeBSD 9.2
        3) Windows 7
        4) Fedora 19
        5) Ubuntu 12.04

SSH was configured on all systems and keys were generated and uploaded to GitHub. I am experiencing a slight problem on Fedora though. After initial config, I was able to login remotely but now receive the error "Connection refused". Can't remember changing anything to cause this but anything is possible so I won't discount it. Worst case scenario, I'll wipe and reinstall it (for the novice the road to professional can seem very long).

Cygwin is installed on Windows 7 and SSHD properly configured.

Martin Norwak and Nick Sabalausky are working on polishing up the build script. Once this is complete, I will generate the binaries for the betas and upload.

Questions requiring clarification:

1) Do I need to create a local repository on each system on which I build or does the one local repository on the base system suffice?

2) What is the process to update a branch with all changes master? I will need to do this because a lot of changes have occurred since the 2.065 branches were created but the actual betas are not yet prepared. Going forward, this is the only time this will occur.

3) Walter: Need your input/decision on what which tools are strictly required for the dmd release.

Release 2.065 will be treated in the same fashion as previous releases in order to afford devs additional time to become familiar with documented release process. Meaning, after the betas are prepared and made available, bug fixes will merged to master and regressions cherry-picked into the branch.

I'm aiming to make betas public by 17 December.




Reply via email to