www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - Build Master: Progress toward 2.065

reply Andrew Edwards <ridimz yahoo.com> writes:
All,

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 github.com/D-Programming-Language. 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 wiki.dlang.org and Nick 
Sabalausky packaging tool:

	dmd, druntime, phobos, tools, dlang.org, 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.

Note:
	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.

Regards,
Andrew

-------------------------
[1] 
http://wiki.dlang.org/Development_and_Release_Process#Local_repository_setup

[2] 
http://wiki.dlang.org/Development_and_Release_Process#Preparing_a_new_major_release
Dec 09 2013
next sibling parent reply "Dicebot" <public dicebot.lv> writes:
On Monday, 9 December 2013 at 14:49:05 UTC, Andrew Edwards wrote:
 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.
Maybe you have forgotten to add ssh daemon to autostart list?
Dec 09 2013
parent Andrew Edwards <ridimz yahoo.com> writes:
On 12/9/13, 10:28 AM, Dicebot wrote:
 On Monday, 9 December 2013 at 14:49:05 UTC, Andrew Edwards wrote:
 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.
Maybe you have forgotten to add ssh daemon to autostart list?
Thanks... that's exactly it.
Dec 09 2013
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2013-12-09 15:48, Andrew Edwards wrote:

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

      1) Mac OS X 10.9
Make sure I got GCC, I don't think the test suite passes if DMD built with Clang. -- /Jacob Carlborg
Dec 09 2013
parent reply Jacob Carlborg <doob me.com> writes:
On 2013-12-09 16:30, Jacob Carlborg wrote:

 Make sure I got GCC, I don't think the test suite passes if DMD built
 with Clang.
* you got. -- /Jacob Carlborg
Dec 09 2013
parent Andrew Edwards <ridimz yahoo.com> writes:
On 12/10/13, 2:16 AM, Jacob Carlborg wrote:
 On 2013-12-09 16:30, Jacob Carlborg wrote:

 Make sure I got GCC, I don't think the test suite passes if DMD built
 with Clang.
* you got.
Ok... will do.
Dec 10 2013
prev sibling next sibling parent reply "Dicebot" <public dicebot.lv> writes:
Also I don't think you need to bother with maintaining own forks 
unless you are planning to actually push something upstream. Just 
cloning core repos on build systems should be enough.
Dec 09 2013
parent Andrew Edwards <ridimz yahoo.com> writes:
On 12/9/13, 10:36 AM, Dicebot wrote:
 Also I don't think you need to bother with maintaining own forks unless
 you are planning to actually push something upstream. Just cloning core
 repos on build systems should be enough.
At least for the time being, the only things I need to push are tags/branches when I create them. Hopefully that will change in the future.
Dec 09 2013
prev sibling parent reply "Dicebot" <public dicebot.lv> writes:
On Monday, 9 December 2013 at 14:49:05 UTC, Andrew Edwards wrote:
 	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.
If branch does not have own commits to be preserved and needs to just be synced with master state (assuming D-Programming-Language remote is named `upstream`): git fetch upstream # download current remote state git checkout 2.065 # go to release branch git reset --hard upstream/master # make it identical to current master git push -f origin 2.065 # update own fork git push -f upstream 2.065 # update branch in core repos, careful here! I can't imagine any other case when one may want to update release branch from master so it must the what you need.
Dec 09 2013
parent reply "Kenji Hara" <k.hara.pg gmail.com> writes:
On Monday, 9 December 2013 at 15:51:47 UTC, Dicebot wrote:
 On Monday, 9 December 2013 at 14:49:05 UTC, Andrew Edwards 
 wrote:
 	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.
If branch does not have own commits to be preserved and needs to just be synced with master state (assuming D-Programming-Language remote is named `upstream`): git fetch upstream # download current remote state git checkout 2.065 # go to release branch git reset --hard upstream/master # make it identical to current master git push -f origin 2.065 # update own fork git push -f upstream 2.065 # update branch in core repos, careful here! I can't imagine any other case when one may want to update release branch from master so it must the what you need.
Note that, at least phobos repository already has some own commits in 2.065 branch. Kenji Hara
Dec 09 2013
next sibling parent reply Andrew Edwards <ridimz yahoo.com> writes:
On 12/10/13, 12:45 AM, Kenji Hara wrote:
 On Monday, 9 December 2013 at 15:51:47 UTC, Dicebot wrote:
 On Monday, 9 December 2013 at 14:49:05 UTC, Andrew Edwards wrote:
     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.
If branch does not have own commits to be preserved and needs to just be synced with master state (assuming D-Programming-Language remote is named `upstream`): git fetch upstream # download current remote state git checkout 2.065 # go to release branch git reset --hard upstream/master # make it identical to current master git push -f origin 2.065 # update own fork git push -f upstream 2.065 # update branch in core repos, careful here! I can't imagine any other case when one may want to update release branch from master so it must the what you need.
Note that, at least phobos repository already has some own commits in 2.065 branch. Kenji Hara
I which case, updating with master will be counter productive. Thanks for the heads up. I will just have to rely on the devs to cherry-pick what was not originally included in the branch. Andrew
Dec 10 2013
parent reply "Dicebot" <public dicebot.lv> writes:
On Tuesday, 10 December 2013 at 12:57:10 UTC, Andrew Edwards 
wrote:
 I which case, updating with master will be counter productive. 
 Thanks for the heads up. I will just have to rely on the devs 
 to cherry-pick what was not originally included in the branch.
cherry-picking is discouraged in that scenario as it will complicate merging 2.065 branch back into master after release. rebase sounds like best fit.
Dec 10 2013
next sibling parent reply "David Nadlinger" <code klickverbot.at> writes:
On Tuesday, 10 December 2013 at 13:01:50 UTC, Dicebot wrote:
 On Tuesday, 10 December 2013 at 12:57:10 UTC, Andrew Edwards 
 wrote:
 I which case, updating with master will be counter productive. 
 Thanks for the heads up. I will just have to rely on the devs 
 to cherry-pick what was not originally included in the branch.
cherry-picking is discouraged in that scenario as it will complicate merging 2.065 branch back into master after release. rebase sounds like best fit.
I'd argue that the release branches should be considered public history and thus never rebased. You can always just merge master into them... David
Dec 10 2013
parent reply "Dicebot" <public dicebot.lv> writes:
On Tuesday, 10 December 2013 at 13:25:02 UTC, David Nadlinger 
wrote:
 On Tuesday, 10 December 2013 at 13:01:50 UTC, Dicebot wrote:
 On Tuesday, 10 December 2013 at 12:57:10 UTC, Andrew Edwards 
 wrote:
 I which case, updating with master will be counter 
 productive. Thanks for the heads up. I will just have to rely 
 on the devs to cherry-pick what was not originally included 
 in the branch.
cherry-picking is discouraged in that scenario as it will complicate merging 2.065 branch back into master after release. rebase sounds like best fit.
I'd argue that the release branches should be considered public history and thus never rebased. You can always just merge master into them... David
Can't agree. Release _tags_ are public. Release branches exist primarily to organize development. Merging master into release branch working on it and then merging all back to master creates very messy making it much harder to say what commits where introduces by release process.
Dec 10 2013
parent reply "David Nadlinger" <code klickverbot.at> writes:
On Tuesday, 10 December 2013 at 13:30:22 UTC, Dicebot wrote:
 Can't agree. Release _tags_ are public. Release branches exist 
 primarily to organize development.
I'm not talking about public in the sense of them being an artefact we want to provide to end-users, but just in the sense that more than one person might need to work on the release branch. As I'm sure you are aware, you'd have to tell everybody to reset their local branches every time the upstream one is updated. Or do you expect only one person to ever commit to the release branch? Of course, ideally commits would go on the release branch first and from there be merged into master (or to other, newer version branches). But if the question is how to fix the current situation where this isn't the case, I'm not sure that rewriting public history is the best option. David
Dec 10 2013
parent reply "Dicebot" <public dicebot.lv> writes:
On Tuesday, 10 December 2013 at 13:37:11 UTC, David Nadlinger 
wrote:
 On Tuesday, 10 December 2013 at 13:30:22 UTC, Dicebot wrote:
 Can't agree. Release _tags_ are public. Release branches exist 
 primarily to organize development.
I'm not talking about public in the sense of them being an artefact we want to provide to end-users, but just in the sense that more than one person might need to work on the release branch. As I'm sure you are aware, you'd have to tell everybody to reset their local branches every time the upstream one is updated. Or do you expect only one person to ever commit to the release branch? Of course, ideally commits would go on the release branch first and from there be merged into master (or to other, newer version branches). But if the question is how to fix the current situation where this isn't the case, I'm not sure that rewriting public history is the best option. David
It is not a problem to reset local branches on rare occasions like this one, whatever developer count is. Reason why rebasing of public branches is discouraged is not some abstract inconvenience of collaboration - it is the fact that commit hashes change in history and anything that has been pointing to part of history that got rewritten will be broken (especially important if, for example, commit hashes are embedded into deployed builds). This is not the case here. There has not been a single tag on this branch and not a single packaged binary built from it. Just is just a development snapshot, rebasing it is no different than creating a new one. As it won't happen under normal conditions anyway, I fail to see the issue.
Dec 10 2013
parent reply "David Nadlinger" <code klickverbot.at> writes:
On Tuesday, 10 December 2013 at 13:43:51 UTC, Dicebot wrote:
 It is not a problem to reset local branches on rare occasions 
 like this one, whatever developer count is. Reason why rebasing 
 of public branches is discouraged is not some abstract 
 inconvenience of collaboration - it is the fact that commit 
 hashes change in history and anything that has been pointing to 
 part of history that got rewritten will be broken (especially 
 important if, for example, commit hashes are embedded into 
 deployed builds).
This collection of "anything" includes local tracking branches people might already use, a simple "git pull" won't work anymore. Thus, it's very much not just an abstract inconvenience – it might be trivial to fix, but less Git-savy people might not immediately know how to handle the situation. David
Dec 11 2013
parent "Dicebot" <public dicebot.lv> writes:
On Wednesday, 11 December 2013 at 09:13:05 UTC, David Nadlinger 
wrote:
 This collection of "anything" includes local tracking branches 
 people might already use, a simple "git pull" won't work 
 anymore. Thus, it's very much not just an abstract 
 inconvenience – it might be trivial to fix, but less Git-savy 
 people might not immediately know how to handle the situation.
That may sound very impolite but last thing I want to care about are "less Git-savy" people that refuse to learn. Resetting local tracking branch is common part of normal git workflow. It is not even advanced stuff. When I am speaking about "anything" I imply "anything released / deployed" - there is no practical value in adhering to local development branch history other than removing requirement to be familiar with `git reset` basics. If someone among developers participating in 2.065 is not familiar with it, it is a major problem in those developers, not in git flow. I am continuously outraged by the fact that someone may find acceptable to willingly ignore one of most important tools involved in development / release process.
Dec 11 2013
prev sibling next sibling parent "eles" <eles eles.com> writes:
On Tuesday, 10 December 2013 at 13:01:50 UTC, Dicebot wrote:
 On Tuesday, 10 December 2013 at 12:57:10 UTC, Andrew Edwards 
 wrote:
 cherry-picking is discouraged in that scenario as it will 
 complicate merging 2.065 branch back into master after release. 
 rebase sounds like best fit.
Or just dropping and start again. For a first try is OK to do several trials until the things get on track.
Dec 10 2013
prev sibling parent reply Leandro Lucarella <luca llucax.com.ar> writes:
Dicebot, el 10 de December a las 14:01 me escribiste:
 On Tuesday, 10 December 2013 at 12:57:10 UTC, Andrew Edwards wrote:
I which case, updating with master will be counter productive.
Thanks for the heads up. I will just have to rely on the devs to
cherry-pick what was not originally included in the branch.
cherry-picking is discouraged in that scenario as it will complicate merging 2.065 branch back into master after release. rebase sounds like best fit.
I don't understand. Rebasing the release branch on top of master shouldn't be an option, as it means you are taking all the changes to master and put them in the release branch. That's just using master as a release branch. The other way around would be crazy. What problems do you see merging cherry-picked stuff back into master? IIRC git should be smart enough to recognize duplicated commits and ignore them, at least if you merge often. -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ ---------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------- Hola soy Angie. Quería preguntarles como inserto un archivo .cab (paquete hecho en Visual Basic contiene una librería y un ocx) en Internet Explorer para después me deje trabajar en PHP con este .cab
Dec 10 2013
parent reply "Dicebot" <public dicebot.lv> writes:
On Tuesday, 10 December 2013 at 15:09:13 UTC, Leandro Lucarella 
wrote:
 I don't understand. Rebasing the release branch on top of master
 shouldn't be an option, as it means you are taking all the 
 changes to
 master and put them in the release branch. That's just using 
 master as
 a release branch. The other way around would be crazy.
Yes, of course, it is not a normal thing to do. As far as I understand, Andrew wants to restart release branch from scratch, based on current master state (because old base happened before he started working on release management). In that case it is a natural (and exceptional) solution.
 What problems do you see merging cherry-picked stuff back into 
 master?
 IIRC git should be smart enough to recognize duplicated commits 
 and
 ignore them, at least if you merge often.
In my experience it was not smart enough. It may have changed in latest versions of course.
Dec 10 2013
next sibling parent reply Andrew Edwards <ridimz yahoo.com> writes:
On 12/10/13, 10:18 AM, Dicebot wrote:
 On Tuesday, 10 December 2013 at 15:09:13 UTC, Leandro Lucarella wrote:
 I don't understand. Rebasing the release branch on top of master
 shouldn't be an option, as it means you are taking all the changes to
 master and put them in the release branch. That's just using master as
 a release branch. The other way around would be crazy.
Yes, of course, it is not a normal thing to do. As far as I understand, Andrew wants to restart release branch from scratch, based on current master state (because old base happened before he started working on release management). In that case it is a natural (and exceptional) solution.
Yes. This is precisely the case and exactly what I'm trying to achieve. My hope is that by doing this I will not be adversely effecting any code already merged into the branch. If there is a chance that this might happen, I would rather cherry-pick the items that must be included or simply forgo such inclusion until the next release.
 What problems do you see merging cherry-picked stuff back into master?
 IIRC git should be smart enough to recognize duplicated commits and
 ignore them, at least if you merge often.
In my experience it was not smart enough. It may have changed in latest versions of course.
Dec 10 2013
parent "Kenji Hara" <k.hara.pg gmail.com> writes:
On Wednesday, 11 December 2013 at 03:12:40 UTC, Andrew Edwards
wrote:
 On 12/10/13, 10:18 AM, Dicebot wrote:
 On Tuesday, 10 December 2013 at 15:09:13 UTC, Leandro 
 Lucarella wrote:
 I don't understand. Rebasing the release branch on top of 
 master
 shouldn't be an option, as it means you are taking all the 
 changes to
 master and put them in the release branch. That's just using 
 master as
 a release branch. The other way around would be crazy.
Yes, of course, it is not a normal thing to do. As far as I understand, Andrew wants to restart release branch from scratch, based on current master state (because old base happened before he started working on release management). In that case it is a natural (and exceptional) solution.
Yes. This is precisely the case and exactly what I'm trying to achieve. My hope is that by doing this I will not be adversely effecting any code already merged into the branch. If there is a chance that this might happen, I would rather cherry-pick the items that must be included or simply forgo such inclusion until the next release.
 What problems do you see merging cherry-picked stuff back 
 into master?
 IIRC git should be smart enough to recognize duplicated 
 commits and
 ignore them, at least if you merge often.
In my experience it was not smart enough. It may have changed in latest versions of course.
I think that, resetting current release branch in Phobos repo does not cause so serious problem. So it is acceptable to me. Kenji Hara
Dec 18 2013
prev sibling parent reply Leandro Lucarella <luca llucax.com.ar> writes:
Dicebot, el 10 de December a las 16:18 me escribiste:
 On Tuesday, 10 December 2013 at 15:09:13 UTC, Leandro Lucarella
 wrote:
I don't understand. Rebasing the release branch on top of master
shouldn't be an option, as it means you are taking all the changes
to
master and put them in the release branch. That's just using
master as
a release branch. The other way around would be crazy.
Yes, of course, it is not a normal thing to do. As far as I understand, Andrew wants to restart release branch from scratch, based on current master state (because old base happened before he started working on release management). In that case it is a natural (and exceptional) solution.
Ah, perfect, then ignore my previous message :) -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ ---------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------- ELLA FUE INFIEL, PERO EX POLOLO PAGÓ -- TV CHILE
Dec 12 2013
parent "Dicebot" <public dicebot.lv> writes:
On Thursday, 12 December 2013 at 15:09:12 UTC, Leandro Lucarella
wrote:
 Ah, perfect, then ignore my previous message :)
P.S. I have just made a test rebase to provide better instructions for Andrew and can confirm that cherry-picked commits still cause conflicts (as well as any other same-content-but-different-hash commits). There was one such commit in current 2.065 state
Dec 12 2013
prev sibling parent "Dicebot" <public dicebot.lv> writes:
On Tuesday, 10 December 2013 at 05:45:26 UTC, Kenji Hara wrote:
 On Monday, 9 December 2013 at 15:51:47 UTC, Dicebot wrote:
 On Monday, 9 December 2013 at 14:49:05 UTC, Andrew Edwards 
 wrote:
 	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.
If branch does not have own commits to be preserved and needs to just be synced with master state (assuming D-Programming-Language remote is named `upstream`): git fetch upstream # download current remote state git checkout 2.065 # go to release branch git reset --hard upstream/master # make it identical to current master git push -f origin 2.065 # update own fork git push -f upstream 2.065 # update branch in core repos, careful here! I can't imagine any other case when one may want to update release branch from master so it must the what you need.
Note that, at least phobos repository already has some own commits in 2.065 branch. Kenji Hara
So, technically, there has been already some release work ongoing in that branch but now you want to restart it with new base? git fetch upstream git checkout 2.065 git rebase upstream/master # assumes it has common point with master earlier in history # resolve conflicts if any git push -f origin 2.065 # any rewrite of history is likely to require force push git push -f upstream 2.065
Dec 10 2013