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`):




current master


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`):




 current master


 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`):






 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`):




 current master


 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

master earlier in history


to require force push
     git push -f upstream 2.065
Dec 10 2013