On 09/09/14 06:56, Brad Roberts via Digitalmars-d wrote:

> I believe that some vm images were created by someone that Andrew used,
> and that's likely the best course to continue right now, imho.

I think Martin Nowak created the VM images using Vagrant. This file [1] contains some Vagrant related code/config.

[1] https://github.com/D-Programming-Language/installer/blob/master/create_dmd_release/build_all.d

-- 
/Jacob Carlborg

> Since Git 1.8.2 you can bound a submodule to a branch.

Ah cool didn't know that.

> ne important (in my opinion) disadvantage misssing: considerably harder PR maintenance (missing automatic categorization and separation between phobos / dmd teams). Being forced to look ar DMD pull requests to do Phobos maintenance will add lot of context overhead for me.

This kind of attitude worries me: every team works happily in its own cozy repository and it doesn't feel responsible about the other repos. The consequence is that, while breeding a new release, the release manager MUST take most of the burden about coordinating the teams and their work. This is a very complex task which requires insight knowledge in all 3 repos.

Having 3 repos, one team is not encouraged to help the other team to get the release out the door. This is because one team have a higher bar to help the other: it needs to checkout the right version of the foreign repo, manage own branches in the foreign repo, etc. Maybe this is the reason of multiple regression in the last release or the "virtual keyword surprise" (at least for some people).

I think that a 2 phase process similar to the Linux kernel release process [1] would work much better and motivates all the teams to help with the release:

Phase 1. Merge window: merge PRs containing new features
Phase 2. Test and stabilization: merge bugfix PRs only

Ideally the first phase is quite short (1 week for example) and it can be close supervised (or even executed??) by Walter and/or Andrei.

The second phase will continue until the acceptance criteria are met, the teams having a focus on the release (they get no new goodies till the test phase is done).

The normal development happens somehow offline by preparing quality PRs to be merged in phase 1.

>
> I also don't feel like it will help much for release preparation. Bisection and history investigation - undoubtedly. But for release management building stuff is one of the easier parts.

Agree, the technical build steps of the release process are easy. Just the casual experimenting with D is somehow clumsy.

[1] - https://www.kernel.org/doc/Documentation/development-process/2.Process

On Tuesday, 9 September 2014 at 09:59:37 UTC, Dragos Carp wrote:
>
>> ne important (in my opinion) disadvantage misssing: considerably harder PR maintenance (missing automatic categorization and separation between phobos / dmd teams). Being forced to look ar DMD pull requests to do Phobos maintenance will add lot of context overhead for me.
>
> This kind of attitude worries me: every team works happily in its own cozy repository and it doesn't feel responsible about the other repos. The consequence is that, while breeding a new release, the release manager MUST take most of the burden about coordinating the teams and their work. This is a very complex task which requires insight knowledge in all 3 repos.

This is not about happiness or zone of comfort - I am simply not competent to judge even most trivial DMD pull request as opposed to Phobos ones. Team separation exists for a reason - skills and knowledge required are totally different. Some developers do both but I doubt it is even the majority of active maintainers. By merging repos you are likely to discourage me from paying attention at all, not to invest huge amount of effort in increasing DMD proficiency.

I am also not sure what what coordination you are speaking about. Integrity of 3 repos is verified by auto-teser. Cross-repo issues are rare and usually handled by those who has merge access to both. Release manager shouldn't normally need any detailed knowledge of repo internal development and just tag certain branch heads. If this is not the case we have some hidden problem I am not aware of.

> Having 3 repos, one team is not encouraged to help the other team to get the release out the door. This is because one team have a higher bar to help the other: it needs to checkout the right version of the foreign repo, manage own branches in the foreign repo, etc. Maybe this is the reason of multiple regression in the last release or the "virtual keyword surprise" (at least for some people).

It feels like you have imagined some process that does not really match reality :( Explicit tracking of matching version is never needed - it is either branch head for all repos, or identically named tags.

I have already explained above some of the real reasons that make closer collaboration close to impossible.

> I think that a 2 phase process similar to the Linux kernel release process [1] would work much better and motivates all the teams to help with the release:
>
> Phase 1. Merge window: merge PRs containing new features
> Phase 2. Test and stabilization: merge bugfix PRs only
>
> Ideally the first phase is quite short (1 week for example) and it can be close supervised (or even executed??) by Walter and/or Andrei.
>
> The second phase will continue until the acceptance criteria are met, the teams having a focus on the release (they get no new goodies till the test phase is done).
>
> The normal development happens somehow offline by preparing quality PRs to be merged in phase 1.


This all sounds like solving the problem that doesn't exist instead of addressing the real ones (lack of clear documented rules for release packaging and awkward cherry-pick based release branch maintenance)

Also it sounds as if you think that someone actually does any coordination about what must go into release. As far as I am aware there is no such thing, even http://wiki.dlang.org/Agenda is just a convention. Currently releases are based exclusively on a time frame + regression list (all that was in master goes to the release branch and is kept there until known regressions are fixed, repeat for the next cycle).

On Tuesday, 9 September 2014 at 12:31:26 UTC, Dicebot wrote:
> Also it sounds as if you think that someone actually does any coordination about what must go into release. As far as I am aware there is no such thing, even http://wiki.dlang.org/Agenda is just a convention. Currently releases are based exclusively on a time frame + regression list (all that was in master goes to the release branch and is kept there until known regressions are fixed, repeat for the next cycle).

Are you satisfied with the current process?

Let me summarize some important drawbacks of the current workflow:

1. No clear defined deadline for preparing a merge-able PR.

2. Unorganized PR merge campaigns. The people merging the PR are doing a great job, but they do this triggered by arbitrary events: too many open PRs, a cool new PR appears, somebody poke them on forum, or simply have some time for this kind of work.

3. Somehow arbitrary merge criteria. Having a defined merge window, when some people do just PR merges, will implicitly produce more predictable and uniform acceptance criteria.

4. Lack of focus during test phase. Maybe this is the main reason for the v2.066 regressions. Some people keep merging new PRs, before the old ones are proven done during the test phase. Even Walter was annoyed a couple of times by the multitude of versions that the people are simultaneously working on.

5. Rotting old PRs. The "merge window" phase would be a defined recurrent occasion to review and decide about those.

On 9/8/14, 10:30 AM, Andrei Alexandrescu wrote:
> Andrew Edwards has done a great job with the recent release, but needs
> to step down because he's busy with other pursuits.
>
> We need a release lieutenant who would carry us through the release
> process. Please tender your application by replying to this.
>
>
> Thanks,
>
> Andrei


Follow these steps to prepare your build environment:

    1. Install VirtualBox: https://www.virtualbox.org/wiki/Downloads
    2. Install Vagrant: https://www.vagrantup.com/downloads.html
    3. Clone installer: git clone --recursive https://github.com/D-Programming-Language/installer.git

Note 1: MartinNowak already prepared boxes for FreeBSD and Debian which are directly imported through the build script. However, you must prepare your own OSX and Windows 7 boxes. Instructions for preparing doing so are located here:

	OSX => https://gist.github.com/MartinNowak/8156507
	Windows7 => https://gist.github.com/MartinNowak/8270666

Steps for building are outlined here:
	http://wiki.dlang.org/Simplified_Release_Process_Proposal

Tracking is done here:
	http://wiki.dlang.org/Beta_Testing

Note 2: I am not vacating the post of Build Master. I have some personal matters that require a significant amount of my time over the next couple of months. I cannot promise to be on time with the releases before October 15. Until then, I will do my best to prepare releases as time permits.

As it stands: If there are no pending merges for the 2.066.1 branch, I will be able to prepare a RC before morning (time now is 12:58 AM JST).

On 9/9/2014 6:54 AM, Dragos Carp via Digitalmars-d wrote:
> On Tuesday, 9 September 2014 at 12:31:26 UTC, Dicebot wrote:
>> Also it sounds as if you think that someone actually does any
>> coordination about what must go into release. As far as I am aware
>> there is no such thing, even http://wiki.dlang.org/Agenda is just a
>> convention. Currently releases are based exclusively on a time frame +
>> regression list (all that was in master goes to the release branch and
>> is kept there until known regressions are fixed, repeat for the next
>> cycle).
>
> Are you satisfied with the current process?
>
> Let me summarize some important drawbacks of the current workflow:
>
> 1. No clear defined deadline for preparing a merge-able PR.
>
> 2. Unorganized PR merge campaigns. The people merging the PR are doing a
> great job, but they do this triggered by arbitrary events: too many open
> PRs, a cool new PR appears, somebody poke them on forum, or simply have
> some time for this kind of work.
>
> 3. Somehow arbitrary merge criteria. Having a defined merge window, when
> some people do just PR merges, will implicitly produce more predictable
> and uniform acceptance criteria.
>
> 4. Lack of focus during test phase. Maybe this is the main reason for
> the v2.066 regressions. Some people keep merging new PRs, before the old
> ones are proven done during the test phase. Even Walter was annoyed a
> couple of times by the multitude of versions that the people are
> simultaneously working on.
>
> 5. Rotting old PRs. The "merge window" phase would be a defined
> recurrent occasion to review and decide about those.

Of course the process can be better.  But NONE of those are a result of the repository split that you're advocating removing.

On Tuesday, 9 September 2014 at 18:56:16 UTC, Brad Roberts via
Digitalmars-d wrote:
>
> Of course the process can be better.  But NONE of those are a result of the repository split that you're advocating removing.

I think these are related. It will be a real challenge to keep in
sync three in parallel running release processes. Keeping in mind
that each team has own development pace, man-power, or
undertakings, how do you avoid that the three release processes
does not diverge between the teams?

On 9/9/2014 9:54 AM, Dragos Carp wrote:
>
> Are you satisfied with the current process?
>
> Let me summarize some important drawbacks of the current workflow:
>
> 1. No clear defined deadline for preparing a merge-able PR.
>
> 2. Unorganized PR merge campaigns. The people merging the PR are doing a
> great job, but they do this triggered by arbitrary events: too many open
> PRs, a cool new PR appears, somebody poke them on forum, or simply have
> some time for this kind of work.
>
> 3. Somehow arbitrary merge criteria. Having a defined merge window, when
> some people do just PR merges, will implicitly produce more predictable
> and uniform acceptance criteria.
>
> 4. Lack of focus during test phase. Maybe this is the main reason for
> the v2.066 regressions. Some people keep merging new PRs, before the old
> ones are proven done during the test phase. Even Walter was annoyed a
> couple of times by the multitude of versions that the people are
> simultaneously working on.
>
> 5. Rotting old PRs. The "merge window" phase would be a defined
> recurrent occasion to review and decide about those.

Most of that is unavoidable without salaried devs on it. D is 100% volunteer, deadlines and such aren't realistically feasible.