December 03, 2013 Re: Build Master: Scheduling II | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrew Edwards | On Tuesday, 3 December 2013 at 14:26:07 UTC, Andrew Edwards wrote:
> Betas will be released four weeks after an official release. The intent is to afford a thorough review of all features introduced since the last official release and allot ample time to remedy any resulting regressions.
>
> Release candidates will follow naturally from Betas two weeks prior to an official release. Once a release candidate is published, no new features will be added.
I don't understand the necessity of a beta release if it doesn't guarantee anything with respect to the codebase. Wouldn't it make more sense to have a "mid-release review" after 4 weeks where everyone discusses the state of the release and the targets for the release candidate? The release candidate seems to handle locking down the addition of new features.
|
December 03, 2013 Re: Build Master: Scheduling II | ||||
---|---|---|---|---|
| ||||
Posted in reply to Dicebot | On Tuesday, 3 December 2013 at 16:04:32 UTC, Dicebot wrote:
>
> Wasn't Nick working on automation of that part?
It isn't automatable because the zip is assembled from different platforms.
|
December 03, 2013 Re: Build Master: Scheduling II | ||||
---|---|---|---|---|
| ||||
Posted in reply to Martin Nowak | On Tuesday, 3 December 2013 at 20:51:27 UTC, Martin Nowak wrote: > On Tuesday, 3 December 2013 at 16:04:32 UTC, Dicebot wrote: >> >> Wasn't Nick working on automation of that part? > https://github.com/D-Programming-Language/installer/pull/24 |
December 03, 2013 Re: Build Master: Scheduling II | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrew Edwards | On Tuesday, 3 December 2013 at 14:26:07 UTC, Andrew Edwards wrote: > Tools currently included in the packages are as follows: We need to discuss the list of included tools. Some of them are only available as binaries, i.e. only Walter knows how to build them. Also DUMPOBJ and OBJ2ASM aren't needed on linux or OSX. The tools strictly related to D are, dman, ddmangle and rdmd. > This list, at the very least, should include DustMite but there are some other tools included in the tools repo on github that might belong here. (This will be considered for inclusion in future releases and will have no effect on release 2.065) > > As I am not skilled at GitHub, I will be following the instructions/guidelines exactly as outlined here: > > http://wiki.dlang.org/Development_and_Release_Process. This does not reflect how we handle things currently. It would be good to start from the current process (version branch + cherry-picking from master) and incrementally improve it towards what we want to achieve. The wiki depicts an idealistic process that requires a lot of awareness by every dev and doesn't map good onto the GitHub workflow. > > I am working on a MacMini running OS X v10.9. I have Ubuntu 13.10 Server loaded in VirtualBox and will be using Jordi Sayol's script to build packages for linux/Windows and Jacob Carlborg script for OSX. > > Both of these scripts require an preexisting release zip and as of this moment, I am unaware of the steps to create that file. I will need some instructions on how to access and run the auto tester if that's what generates the zip or, if it's already automatically created, instructions on how to retrieve and stage it for the build. Only Walter knows how to build the zip. Nick wrote a build script the produces a similar zip file, https://github.com/D-Programming-Language/installer/pull/24. Maybe we can get that in shape for the next few releases. In the mid-term we should replace all installer scripts that depend on the dmd2.zip with scripts that build a platform specific release from source. Work is being done to add install targets to the Makefiles of each project. I'm currently working on a spec file to build RPMs for Fedora. > > I will be setting up a tag on github today for the first beta release of 2.065 (2.065-b1). > It would be helpful to post a short notice in advance on the dmd-beta mailing list so that the devs can coordinate their work accordingly. |
December 03, 2013 Re: Build Master: Scheduling II | ||||
---|---|---|---|---|
| ||||
Posted in reply to Martin Nowak | On Tuesday, 3 December 2013 at 21:23:49 UTC, Martin Nowak wrote:
> The tools strictly related to D are, dman, ddmangle and rdmd.
>
And link on windows.
Thanks for doing this Andrew.
|
December 03, 2013 Re: Build Master: Scheduling II | ||||
---|---|---|---|---|
| ||||
Posted in reply to Martin Nowak | On 2013-12-03 21:51, Martin Nowak wrote: > It isn't automatable because the zip is assembled from different platforms. Why can't that be automatable? We do have the servers running the tests. The idea is that they should build them. -- /Jacob Carlborg |
December 04, 2013 Re: Build Master: Scheduling II | ||||
---|---|---|---|---|
| ||||
Posted in reply to tn | On 12/3/13, 12:21 PM, tn wrote:> In general this sounds great. However: > > On Tuesday, 3 December 2013 at 14:26:07 UTC, Andrew Edwards wrote: >> Betas will be released four weeks after an official release. > > Does this mean that a new release branch will be created at that point? > I think it makes sense. Yes. >> Once a release candidate is published, no new features will be added. > > Does this imply that new features are still added in beta phase? That > does not fit well with creating the branch in the beginning of the beta > phase. > > My opinion: > > I don't think new features should be added in beta phase. Instead it > should be for bug fixing. When no known blocker bugs are left, a release > candidate phase should be started. Relase candidate should be, as the > name implies, a candidate for release. Thus, if no new critical bugs are > found, then the release can be made in principle just by bumping the > version number. You make a good point. I actually thought about that after I posted but was on my way to work so could not re-post at the time. The beta release will start a new branch and will basically follow the steps you describe. No new features after a beta is released. > More important than defining when the actual releases are made, is to > define when branching is done. It is easy to slip release date because > of new bugs and that can then delay the next release (depending on how > you implement the procedure). Instead, a new release branch should be > branched from the master branch exactly every 8 weeks. That should be > easy, since there are no such stability requirements as for actual > releases. Whether the following stabilisation phase (betas + release > candidates) lasts exactly 3 or 4 or 5 weeks is not that important as > long as the quality of the release will be acceptable. The phase should > last long enough that all blocker bugs are fixed. In this model the time > between actual releases can vary a bit, but on average it will be > exactly 8 weeks. Make sense. I will take this into consideration. |
December 04, 2013 Re: Build Master: Scheduling II | ||||
---|---|---|---|---|
| ||||
Posted in reply to Brad Anderson | On 12/3/13, 2:08 PM, Brad Anderson wrote: > On Tuesday, 3 December 2013 at 14:26:07 UTC, Andrew Edwards wrote: >> [snip] >> I am working on a MacMini running OS X v10.9. I have Ubuntu 13.10 >> Server loaded in VirtualBox and will be using Jordi Sayol's script to >> build packages for linux/Windows and Jacob Carlborg script for OSX. > > Please use windows/dinstaller.nsi for creating the installer on > Windows. linux/win/installer.nsi has some missing features and an issue > with deleting the entire directory tree as part of a uninstallation > pre-step that has caused problems for some people. I'm going to try to > merge these two files to pick up some of the useful features Jordi has > added but for the time being dinstaller.nsi is the proper one to use. Ok, got you. One question, does dinstaller.nsi work on linux/osx? If not I will need your assistance to prepare the package until such time as I can obtain an image for VirtualBox. >> >> Both of these scripts require an preexisting release zip and as of >> this moment > > dinstaller.nsi defaults to a web-installer (it downloads dmd2.zip and > others itself). As such, it doesn't require the dmd zip to be present in > order to create the installer executable. It can optionally embed the > zip in the installer but that hasn't been how it's been used historically. Which is basically a staged zip file and the same problem as stated. If the zip file doesn't exist locally or on the web site, then these tools do not work. > If you open up dinstaller.nsi it should be fairly obvious how it all > works with regard to updating it for a new release. Just change the > version number at the top of the file and ensure the url to the dmd zip > a bit further down is correct. Understood. > Have you arranged with Walter or Brad Roberts to get access to upload to > the download server? I think the build master having the ability to do > uploads is vital. I have not. Did for the GitHub repository but forgot about that. Thanks for the reminder. >> , I am unaware of the steps to create that file. > > I believe Nick's release tool can generate the release zip properly. > https://github.com/D-Programming-Language/installer/pull/24 I really > recommend looking at it. He spent a lot of time perfecting it. Will try it but I thought it was platform specific. Meaning, I thought it created a OSX specific archive if ran on OSX and so on. >> I will need some instructions on how to access and run the auto tester >> if that's what generates the zip or, if it's already automatically >> created, instructions on how to retrieve and stage it for the build. > > Historically, Walter has created the release zips (just using the > makefile, I believe). As far as I know, work hasn't begun on getting the > autotester to roll releases. That will be great when it's completed. >> >> I will be setting up a tag on github today for the first beta release >> of 2.065 (2.065-b1). >> >> Request your corporation/support in ensuring a smooth process. >> > > Good luck. Let me know if you have any questions or problems with the > Windows installer script. Thanks. >> Andrew > |
December 04, 2013 Re: Build Master: Scheduling II | ||||
---|---|---|---|---|
| ||||
Posted in reply to Nick | On 12/3/13, 3:32 PM, Nick wrote:
> On Tuesday, 3 December 2013 at 14:26:07 UTC, Andrew Edwards wrote:
>> Betas will be released four weeks after an official release. The
>> intent is to afford a thorough review of all features introduced since
>> the last official release and allot ample time to remedy any resulting
>> regressions.
>>
>> Release candidates will follow naturally from Betas two weeks
>> prior to an official release. Once a release candidate is published,
>> no new features will be added.
>
> I don't understand the necessity of a beta release if it doesn't
> guarantee anything with respect to the codebase. Wouldn't it make more
> sense to have a "mid-release review" after 4 weeks where everyone
> discusses the state of the release and the targets for the release
> candidate? The release candidate seems to handle locking down the
> addition of new features.
The beta release will the signify the end of new features for that particular release cycle. I was concerned about the same thing after posting this morning but was on my way out the door so could not address earlier.
|
December 04, 2013 Re: Build Master: Scheduling II | ||||
---|---|---|---|---|
| ||||
Posted in reply to Martin Nowak | On 12/3/13, 4:23 PM, Martin Nowak wrote: > On Tuesday, 3 December 2013 at 14:26:07 UTC, Andrew Edwards wrote: >> Tools currently included in the packages are as follows: > > We need to discuss the list of included tools. > Some of them are only available as binaries, i.e. only Walter knows how > to build them. Also DUMPOBJ and OBJ2ASM aren't needed on linux or OSX. > The tools strictly related to D are, dman, ddmangle and rdmd. > >> This list, at the very least, should include DustMite but there are >> some other tools included in the tools repo on github that might >> belong here. (This will be considered for inclusion in future releases >> and will have no effect on release 2.065) >> >> As I am not skilled at GitHub, I will be following the >> instructions/guidelines exactly as outlined here: >> >> http://wiki.dlang.org/Development_and_Release_Process. > > This does not reflect how we handle things currently. > It would be good to start from the current process (version branch + > cherry-picking from master) and incrementally improve it towards what we > want to achieve. The wiki depicts an idealistic process that requires a > lot of awareness by every dev and doesn't map good onto the GitHub > workflow. Understood. I would however, suggest that it is a habit that we should get into. One of the first things that we should have devs review when they want to know how to contribute is to lead them to this page. As I matter of fact, I think it might even be a good idea to include it in the CONTRIBUTING.md file on GitHub or, at the very least, insert a link to it. >> >> I am working on a MacMini running OS X v10.9. I have Ubuntu 13.10 >> Server loaded in VirtualBox and will be using Jordi Sayol's script to >> build packages for linux/Windows and Jacob Carlborg script for OSX. >> >> Both of these scripts require an preexisting release zip and as of >> this moment, I am unaware of the steps to create that file. I will >> need some instructions on how to access and run the auto tester if >> that's what generates the zip or, if it's already automatically >> created, instructions on how to retrieve and stage it for the build. > > Only Walter knows how to build the zip. > Nick wrote a build script the produces a similar zip file, > https://github.com/D-Programming-Language/installer/pull/24. > Maybe we can get that in shape for the next few releases. I'll check it out. Hopefully it does what I need. > In the mid-term we should replace all installer scripts that depend on > the dmd2.zip with scripts that build a platform specific release from > source. > Work is being done to add install targets to the Makefiles of each project. > > I'm currently working on a spec file to build RPMs for Fedora. > >> >> I will be setting up a tag on github today for the first beta release >> of 2.065 (2.065-b1). >> > It would be helpful to post a short notice in advance on the dmd-beta > mailing list so that the devs can coordinate their work accordingly. Will do. |
Copyright © 1999-2021 by the D Language Foundation