Lieutenant needed: build and release process (page 5)

On Tuesday, 9 September 2014 at 22:41:39 UTC, Nick Sabalausky wrote: > > Most of that is unavoidable without salaried devs on it. D is 100% volunteer, deadlines and such aren't realistically feasible. I'm talking about the deadlines for your own PRs. If you miss one release, you will have your chance in the next one. Of course you will still freely choose for yourself the tasks that suit you best. Beside that, having a deadline it is a great motivational factor to do even some unpleasant work (for me at least).

September 09, 2014

Re: Lieutenant needed: build and release process

Posted by Dicebot
in reply to Dragos Carp

Permalink

Dicebot

Posted in reply to Dragos Carp

Permalink

On Tuesday, 9 September 2014 at 13:54:15 UTC, Dragos Carp wrote:
> Are you satisfied with the current process?

Yes. I am not satisfied with certain parts of implementation of the process but the concept overall is a good as it can possibly be given manpower available and lack of any centralized collaboration. Think about it - despite the fact that there is no one actually responsible for release planning and no fully commited developers we still somehow manage to get those release out. This is quite an achievment if you think about it.

> Let me summarize some important drawbacks of the current workflow:
>
> 1. No clear defined deadline for preparing a merge-able PR.

.. which allows maintainers to merge pull requests when they seem ready without any synchronization "locks" and does not interfere with release branches.

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

There is no such thing as "PR merge campaign" and there is not point in having one. It is everlasting process - stuff gets merged when its done, it is completly irrelevant to release planning. "simply have some time for this kind of work" is the only realistic criteria for any sort of maintenance activity here, you can't get any other without bunch of devs on salary.

It is a process which is almost exclusively blocked by maintainer time. It is quite telling that situation with Phobos (which has easier learning curve and more active maintainers overall) is much better than with DMD.

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

What makes you think so? It will only introduce arbitrary limitation on a time when you can merge pull requests. Merge criteria is an orthogonal topic - if it is possible to formalize one, it can also be done without introducing merge windows. Implicit uniform criteria is much better defined by the simple fact that those are the very same people doing merges (and there aren't many)

Only thing merge window will achieve is making pull reqeuests stockpile even more because developers won't be allowed to merge them when they have time to do so.

> 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

Main reason is that there are only few developers capable of fixing DMD regressions. If release beta happens when either of them is busy it will result in immediate slowdown. This is especially true about Kenji.

Do you realize that fixing release and merging new pull requests happens in _different_ branches? And merging even 1000 new features doesn't affect testing of the release beta? There were certain bad cases when major refactorings in master make it hard to port bug fixes to release branch but those were rare.

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

There are no rotting old PRs now in Phobos despite the maintenance / release process is the same. Guess why? With recent addition of bunch of new maintainers we simply got the resources to clean and categorize those and this just immediately happened.

Unfortunately, there is no magic process can just create new developers out of the air :(

On Tuesday, 9 September 2014 at 15:58:45 UTC, Andrew Edwards wrote: > 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). Thanks Andrew! This is most helpful. I will try this out this weekend to be able to act as backup build master for 2.067

On 9/9/14, 4:06 PM, Dragos Carp wrote: > On Tuesday, 9 September 2014 at 22:41:39 UTC, Nick Sabalausky > wrote: >> >> Most of that is unavoidable without salaried devs on it. D is 100% >> volunteer, deadlines and such aren't realistically feasible. > > I'm talking about the deadlines for your own PRs. If you miss one > release, you will have your chance in the next one. Of course you > will still freely choose for yourself the tasks that suit you > best. Beside that, having a deadline it is a great motivational > factor to do even some unpleasant work (for me at least). Yah, we should have deadlines. -- Andrei

On Wednesday, 10 September 2014 at 07:43:22 UTC, Andrei Alexandrescu wrote: > Yah, we should have deadlines. -- Andrei We have them already, it just happens that those are never realistically executed. http://wiki.dlang.org/Release_Process#Release_Schedule

On 9/10/14, Dicebot via Digitalmars-d <digitalmars-d@puremagic.com> wrote: > On Wednesday, 10 September 2014 at 07:43:22 UTC, Andrei Alexandrescu wrote: >> Yah, we should have deadlines. -- Andrei > > We have them already, it just happens that those are never realistically executed. > > http://wiki.dlang.org/Release_Process#Release_Schedule “I love deadlines. I love the whooshing noise they make as they go by.” - Douglas Adams

On Tuesday, 9 September 2014 at 15:58:45 UTC, Andrew Edwards wrote: > 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 Trying this right now, got through Win7 box setup but where one is supposed to get "InstallESD.dmg" mentioned in installation instructions?

On 2014-09-20 16:44, Dicebot wrote: > Trying this right now, got through Win7 box setup but where one is > supposed to get "InstallESD.dmg" mentioned in installation instructions? As the instructions say, from the "Install Mac OS X Mountain Lion.app" bundle. This bundle is downloaded from the Mac App Store. For Mavericks it's located in "Install OS X Mavericks.app/Contents/SharedSupport/InstallESD.dmg". If you download it form the app store it's will be placed in /Applications. BTW you should only do this on a Mac. Technically it's possible to do on another platform. -- /Jacob Carlborg

On Saturday, 20 September 2014 at 15:16:20 UTC, Jacob Carlborg wrote: > BTW you should only do this on a Mac. Technically it's possible to do on another platform. Ah I see. Guess this is the point where I should say "Thanks, no, I am not going to volunteer". Can do linux-only releases if anyone is interested ;)

Forums