Build Master: Progress toward 2.065
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
Re: Build Master: Progress toward 2.065
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?
Re: Build Master: Progress toward 2.065
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
Re: Build Master: Progress toward 2.065
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.
Re: Build Master: Progress toward 2.065
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.
Re: Build Master: Progress toward 2.065
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.
Re: Build Master: Progress toward 2.065
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.
Re: Build Master: Progress toward 2.065
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
Re: Build Master: Progress toward 2.065
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
Re: Build Master: Progress toward 2.065
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.
Re: Build Master: Progress toward 2.065
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
Re: Build Master: Progress toward 2.065
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
Re: Build Master: Progress toward 2.065
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.
Re: Build Master: Progress toward 2.065
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
Re: Build Master: Progress toward 2.065
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.
Re: Build Master: Progress toward 2.065
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.
Re: Build Master: Progress toward 2.065
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
Re: Build Master: Progress toward 2.065
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.
Re: Build Master: Progress toward 2.065
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
Re: Build Master: Progress toward 2.065
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.
Re: Build Master: Progress toward 2.065
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.
Re: Build Master: Progress toward 2.065
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
Re: Build Master: Progress toward 2.065
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.
Re: Build Master: Progress toward 2.065
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
Re: Build Master: Progress toward 2.065
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
Re: Build Master: Progress toward 2.065
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
