On Wednesday, 4 December 2013 at 02:15:23 UTC, Andrew Edwards wrote:
>>>    http://wiki.dlang.org/Development_and_Release_Process.
>>
>> This does not reflect how we handle things currently.
>> It would be good to start from the current process (version branch +
>> cherry-picking from master) and incrementally improve it towards what we
>> want to achieve. The wiki depicts an idealistic process that requires a
>> lot of awareness by every dev and doesn't map good onto the GitHub
>> workflow.
>
> Understood. I would however, suggest that it is a habit that we should get into. One of the first things that we should have devs review when they want to know how to contribute is to lead them to this page. As I matter of fact, I think it might even be a good idea to include it in the CONTRIBUTING.md file on GitHub or, at the very least, insert a link to it.

It's not the new contributors which is the problem. It is the existing contributors. Every dev has to be retrained on how to handling patching multiple branches (in fact, it is less important contributors know, much more that the people merging know).

It is fine to move in this direction, but since you aren't well versed in git workflow it may be too much to take on for the first release.

Also, at some point Walter said in a random forum post that he wanted this next release to be bug fixes only and rather quick... You're plan and Walter's don't seem to match exactly.

On 12/3/13, 9:26 PM, Jesse Phillips wrote:
> On Wednesday, 4 December 2013 at 02:15:23 UTC, Andrew Edwards wrote:
>>>>    http://wiki.dlang.org/Development_and_Release_Process.
>>>
>>> This does not reflect how we handle things currently.
>>> It would be good to start from the current process (version branch +
>>> cherry-picking from master) and incrementally improve it towards what we
>>> want to achieve. The wiki depicts an idealistic process that requires a
>>> lot of awareness by every dev and doesn't map good onto the GitHub
>>> workflow.
>>
>> Understood. I would however, suggest that it is a habit that we should
>> get into. One of the first things that we should have devs review when
>> they want to know how to contribute is to lead them to this page. As I
>> matter of fact, I think it might even be a good idea to include it in
>> the CONTRIBUTING.md file on GitHub or, at the very least, insert a
>> link to it.
>
> It's not the new contributors which is the problem. It is the existing
> contributors. Every dev has to be retrained on how to handling patching
> multiple branches (in fact, it is less important contributors know, much
> more that the people merging know).

Point taken. It is hard to break old habits and from new ones but sometimes it is absolutely necessary. IMHO this is one of those times.

> It is fine to move in this direction, but since you aren't well versed
> in git workflow it may be too much to take on for the first release.

The ball is rolling and everything worked as documented with one minor exception (where it says git:// replace with https://). I have created the branch/tag and am waiting for a message to be released to the dmd-beta mailing list. Once devs are alerted and the binaries are prepared, a more formal message will be placed in the announce group.

> Also, at some point Walter said in a random forum post that he wanted
> this next release to be bug fixes only and rather quick... You're plan
> and Walter's don't seem to match exactly.
>

Unfortunately I did not see that post. And while our thoughts/plans may be different, Walter does have the option to speed up or slow down the process should it be warranted. As such, I will proceed according to my plan until informed otherwise.

On 12/3/13, 9:15 PM, Andrew Edwards wrote:
> On 12/3/13, 4:23 PM, Martin Nowak wrote:
>> Only Walter knows how to build the zip.
>> Nick wrote a build script the produces a similar zip file,
>> https://github.com/D-Programming-Language/installer/pull/24.
>> Maybe we can get that in shape for the next few releases.
>
> I'll check it out. Hopefully it does what I need.
>

Tried it but came across the following errors:


andrews-mini:osx-release ace$ ~/create_dmd_release v2.065-b1 --extras=$HOME/localextras-osx --archive-zip --archive-7z

Cloning: git@github.com:D-Programming-Language/dmd.git

The authenticity of host 'github.com (192.30.252.128)' can't be established.

RSA key fingerprint is 16:27:ac:a5:76:28:2d:36:63:1b:56:4d:eb:df:a6:48.

Are you sure you want to continue connecting (yes/no)? yes

Warning: Permanently added 'github.com,192.30.252.128' (RSA) to the list of known hosts.

Permission denied (publickey).

fatal: Could not read from remote repository.



Please make sure you have the correct access rights

and the repository exists.

Couldn't do git protocol, falling back to 'https://'...

Cloning: https://github.com/D-Programming-Language/dmd.git

Cloning: https://github.com/D-Programming-Language/druntime.git

error: pathspec 'v2.065-b1' did not match any file(s) known to git.

create_dmd_release: Error: Command failed (ran from dir '/private/var/folders/40/ks15z23971qfm9vsn2c2mz640000gn/T/.create_dmd_release/druntime'): git checkout -q 'v2.065-b1'


I created the v2.065-b1 tag and verified that it actually exists. If I use 2.065 as indicated in the instructions for making betas, it results in the exact same error.

Any thoughts?

Thanks,
Andrew

On Wednesday, 4 December 2013 at 04:29:19 UTC, Andrew Edwards wrote:
> On 12/3/13, 9:15 PM, Andrew Edwards wrote:
>> On 12/3/13, 4:23 PM, Martin Nowak wrote:
>>> Only Walter knows how to build the zip.
>>> Nick wrote a build script the produces a similar zip file,
>>> https://github.com/D-Programming-Language/installer/pull/24.
>>> Maybe we can get that in shape for the next few releases.
>>
>> I'll check it out. Hopefully it does what I need.
>>
>
> Tried it but came across the following errors:
>
>
> andrews-mini:osx-release ace$ ~/create_dmd_release v2.065-b1 --extras=$HOME/localextras-osx --archive-zip --archive-7z
>
> Cloning: git@github.com:D-Programming-Language/dmd.git
>
> The authenticity of host 'github.com (192.30.252.128)' can't be established.
>
> RSA key fingerprint is 16:27:ac:a5:76:28:2d:36:63:1b:56:4d:eb:df:a6:48.
>
> Are you sure you want to continue connecting (yes/no)? yes
>
> Warning: Permanently added 'github.com,192.30.252.128' (RSA) to the list of known hosts.
>
> Permission denied (publickey).
>
> fatal: Could not read from remote repository.
>
>
>
> Please make sure you have the correct access rights
>
> and the repository exists.
>
> Couldn't do git protocol, falling back to 'https://'...
>
> Cloning: https://github.com/D-Programming-Language/dmd.git
>
> Cloning: https://github.com/D-Programming-Language/druntime.git
>
> error: pathspec 'v2.065-b1' did not match any file(s) known to git.
>
> create_dmd_release: Error: Command failed (ran from dir '/private/var/folders/40/ks15z23971qfm9vsn2c2mz640000gn/T/.create_dmd_release/druntime'): git checkout -q 'v2.065-b1'
>
>
> I created the v2.065-b1 tag and verified that it actually exists. If I use 2.065 as indicated in the instructions for making betas, it results in the exact same error.
>
> Any thoughts?
>
> Thanks,
> Andrew

Maybe you have already looked here, but it may help you with your first error:

https://help.github.com/articles/error-permission-denied-publickey

Good luck.
Craig

On 12/3/13, 11:29 PM, Andrew Edwards wrote:
>
> I created the v2.065-b1 tag and verified that it actually exists. If I
> use 2.065 as indicated in the instructions for making betas, it results
> in the exact same error.
>
> Any thoughts?
>

OK the problem was that I didn't finish branching all the components. I did DMD but not DRUNTIME, PHOBOS, INSTALLER, TOOLS, and DLANG.ORG. They are now complete and I successfully built the binaries file for OSX.

My next question is whether or not this can be used on my platform (OSX) to build binaries for the other platforms (Linux, Windows, FreeBSD) or do I have to be on those platforms to do so? If that is the case, then I will need assistance getting for Windows binaries created and it will require more time than anticipated to get the the FreeBSD and Linux binaries complete because I will be teaching at 8AM and have not yet look at the material.

Thanks,
Andrew

On 12/3/13, 11:38 PM, Craig Dillabaugh wrote:
> On Wednesday, 4 December 2013 at 04:29:19 UTC, Andrew Edwards wrote:
>> On 12/3/13, 9:15 PM, Andrew Edwards wrote:
>>> On 12/3/13, 4:23 PM, Martin Nowak wrote:
>>>> Only Walter knows how to build the zip.
>>>> Nick wrote a build script the produces a similar zip file,
>>>> https://github.com/D-Programming-Language/installer/pull/24.
>>>> Maybe we can get that in shape for the next few releases.
>>>
>>> I'll check it out. Hopefully it does what I need.
>>>
>>
>> Tried it but came across the following errors:
>>

...

>>
>> I created the v2.065-b1 tag and verified that it actually exists. If I
>> use 2.065 as indicated in the instructions for making betas, it
>> results in the exact same error.
>>
>> Any thoughts?
>>
>> Thanks,
>> Andrew
>
> Maybe you have already looked here, but it may help you with your first
> error:
>
> https://help.github.com/articles/error-permission-denied-publickey
>
> Good luck.
> Craig

I didn't look into that as the there is a built in fallback for https. I will need to resolve the issue eventually though so thanks for the link. Original problem solved.

Andrew

On 2013-12-03 15:25, Andrew Edwards wrote:

> I am working on a MacMini running OS X v10.9. I have Ubuntu 13.10 Server
> loaded in VirtualBox and will be using Jordi Sayol's script to build
> packages for linux/Windows and Jacob Carlborg script for OSX.
>
> Both of these scripts require an preexisting release zip and as of this
> moment, I am unaware of the steps to create that file. I will need some
> instructions on how to access and run the auto tester if that's what
> generates the zip or, if it's already automatically created,
> instructions on how to retrieve and stage it for the build.

Unfortunately there is no publicly available script (or similar) that creates the zip. It's Walter how always creates it.

As others have said, the closest you get it probably the script Nick is working on: https://github.com/D-Programming-Language/installer/pull/24

> I will be setting up a tag on github today for the first beta release of
> 2.065 (2.065-b1).
>
> Request your corporation/support in ensuring a smooth process.

Ideally there should be a "one-click" tool/script that manages the complete release of a new version, including beta and release candidates. With one command it should:

* Create a git tag for all involved repositories

* Instruct the autotester to build the compiler, libraries, installers and all tools for each platform based on the newly created tag

* Assemble the cross-platform zip on one of the autotester machines

* Upload zip and all installers to the Digital Mars FTP and/or Amazon or wherever these things are currently hosted

* Generate the changelog from bugzilla. The overview/general information should already be present in the changelog at this time

* Updates the website with the new changelog and links to the new release

* Posts a message to the announce newsgroup, twitter, reddit? and any social networks we would like to post to

Preferably there should be options to disable any of these steps make it possible to just assembly the compiler and tools but not make a proper release (update website post to social networks)

-- 
/Jacob Carlborg

On 2013-12-04 02:30, Andrew Edwards wrote:

> Ok, got you. One question, does dinstaller.nsi work on linux/osx? If not
> I will need your assistance to prepare the package until such time as I
> can obtain an image for VirtualBox.

Everything should be built using the autotester.

> Which is basically a staged zip file and the same problem as stated. If
> the zip file doesn't exist locally or on the web site, then these tools
> do not work.

Then the tools need to be changed to be workable from source.


> Will try it but I thought it was platform specific. Meaning, I thought
> it created a OSX specific archive if ran on OSX and so on.

It need to compile everything on each platform. We don't support true cross-platform builds yet.

>> Historically, Walter has created the release zips (just using the
>> makefile, I believe). As far as I know, work hasn't begun on getting the
>> autotester to roll releases.
>
> That will be great when it's completed.

That should be our primary goal now.

-- 
/Jacob Carlborg

On 2013-12-03 20:08, Brad Anderson wrote:

> Historically, Walter has created the release zips (just using the
> makefile, I believe). As far as I know, work hasn't begun on getting the
> autotester to roll releases.

I doubt he has a completely automated process of doing it. It has failed too many times.

Having the autotester building and handling everything should be our primary goal.

-- 
/Jacob Carlborg

On 2013-12-04 03:26, Jesse Phillips wrote:

> Also, at some point Walter said in a random forum post that he wanted
> this next release to be bug fixes only and rather quick... You're plan
> and Walter's don't seem to match exactly.

Walter has also said it's up to the release manager (build master) to decide this.

-- 
/Jacob Carlborg