December 15, 2012
On Saturday, 15 December 2012 at 19:03:49 UTC, Brad Roberts wrote:

> This is a forcing function that's just required.

There is a focusing that needs to happen, but as you say, you can't really dictate where someone puts their time (for open source). So it is best to let the person who decided to review a pull to also spend the time to merge it. But strongly encourage everyone on the team to get the release out.

Remember we are preparing for growth and will want to be ready to handle all types of contributors.
December 15, 2012
On Saturday, 15 December 2012 at 19:03:49 UTC, Brad Roberts wrote:
> On 12/15/2012 2:29 AM, Dmitry Olshansky wrote:
>
>> I think one of major goals is to be able to continue ongoing development while at the _same time_ preparing a release.
>> To me number one problem is condensed in the statement "we are going to release do not merge anything but regressions"
>> the process should sidestep this "lock-based" work-flow. Could be useful to add something along these line to goals
>> section. (i.e. the speed and smoothness is a goal)
>
> I've been staying out of this thread for the most part, but I feel the need to comment on this part specifically.  It's
> quite common for most major projects to have a clear "we're wrapping up a release" phase where work _is_ restricted to
> bug fixing and stabilizing.  They don't stop people from working off in their development branches (no one could
> effectively impose such restrictions even if they wanted to), but they _do_ tighten down on what's allowed to be merged.
>
> This is a forcing function that's just required.  There's a lot of issues that otherwise won't get sufficient attention.
>  If all it took was altruism then regressions would be fixed immediately, bugs would always be fixed in highest priority
> to lowest priority (assuming that could even be effectively designed), etc.
>
> Without the 'ok, guys, focus in this smaller more critical subset of bugs' step, release branches would be created and
> never polished (or focused down to the release manager to do all the work if he's that skilled and/or generous of his time).
>
> There's a phrase I'm trying to remember, but it's something to the effect that 'hope isn't a recipe for success.'
> Hoping that people fix regressions on release critical bugs isn't sufficient.  Incentive and steering is required.  The
> desire to ungate master branch merges is one approach that's been shown to be successful.

Very good point. The final sprint is a good practice to adopt.
December 15, 2012
On Saturday, 15 December 2012 at 10:29:55 UTC, Dmitry Olshansky wrote:
> Second point is about merging master into staging - why not just rewrite it with master branch altogether after each release?
> master is the branch with correct history (all new stuff is rebased on it) thus new staging will have that too.

Why you don't rewrite is because it is a public branch. Unlike feature branches which will basically be thrown out everyone on the development team will need to have staging updated. If we rewrite history then instead of

$ git pull staging

At random times it will be (I don't know the commands and won't even look it up)

It just won't be pretty.


I've made modifications to the graphic hoping to illustrate some thoughts.

http://i.imgur.com/rJVSg.png

This does not depict what is currently described (in terms of branching). But is what I've written under http://wiki.dlang.org/Release_Process#Release_Schedule

I see patches going into the LTS-1 (if applicable), the LTS-1 is then merged into the latest LTS, which is merged into any active staging, that is then merged into master.

The monthly release don't get bug fixes (just wait for the next month).

I've removed some version numbering since I don't know if we should have a distinct numbering for LTS and Monthly. I've already give some thoughts on this: http://forum.dlang.org/post/ydmgqmbqngwderfkljde@forum.dlang.org
December 15, 2012
On Saturday, 15 December 2012 at 20:32:42 UTC, Jesse Phillips wrote:
> On Saturday, 15 December 2012 at 10:29:55 UTC, Dmitry Olshansky wrote:
>> Second point is about merging master into staging - why not just rewrite it with master branch altogether after each release?
>> master is the branch with correct history (all new stuff is rebased on it) thus new staging will have that too.
>
> Why you don't rewrite is because it is a public branch. Unlike feature branches which will basically be thrown out everyone on the development team will need to have staging updated. If we rewrite history then instead of
>
> $ git pull staging
>
> At random times it will be (I don't know the commands and won't even look it up)
>
> It just won't be pretty.
>
>
> I've made modifications to the graphic hoping to illustrate some thoughts.
>
> http://i.imgur.com/rJVSg.png
>
> This does not depict what is currently described (in terms of branching). But is what I've written under http://wiki.dlang.org/Release_Process#Release_Schedule
>
> I see patches going into the LTS-1 (if applicable), the LTS-1 is then merged into the latest LTS, which is merged into any active staging, that is then merged into master.
>
> The monthly release don't get bug fixes (just wait for the next month).
>
> I've removed some version numbering since I don't know if we should have a distinct numbering for LTS and Monthly. I've already give some thoughts on this: http://forum.dlang.org/post/ydmgqmbqngwderfkljde@forum.dlang.org

Can we drop the LTS name ? It reminds me of ubuntu, and I clearly hope that people promoting that idea don't plan to reproduce ubuntu's scheme :
 - it is not suitable for a programming language (as stated 3 time now, so just read before why I won't repeat it).
 - ubuntu is notoriously unstable.
December 15, 2012
12/15/2012 11:03 PM, Brad Roberts пишет:
> On 12/15/2012 2:29 AM, Dmitry Olshansky wrote:
>
>> I think one of major goals is to be able to continue ongoing development while at the _same time_ preparing a release.
>> To me number one problem is condensed in the statement "we are going to release do not merge anything but regressions"
>> the process should sidestep this "lock-based" work-flow. Could be useful to add something along these line to goals
>> section. (i.e. the speed and smoothness is a goal)
>
> I've been staying out of this thread for the most part, but I feel the need to comment on this part specifically.  It's
> quite common for most major projects to have a clear "we're wrapping up a release" phase where work _is_ restricted to
> bug fixing and stabilizing.  They don't stop people from working off in their development branches (no one could
> effectively impose such restrictions even if they wanted to), but they _do_ tighten down on what's allowed to be merged.
>
> This is a forcing function that's just required.  There's a lot of issues that otherwise won't get sufficient attention.
>   If all it took was altruism then regressions would be fixed immediately, bugs would always be fixed in highest priority
> to lowest priority (assuming that could even be effectively designed), etc.

I understand the desire of focusing people attention on a priority but there is no denying the fact that only a small subset of folks that is able to (say) fix a regression in the compiler.

What I'm trying to avoid here is a situation where the compiler team fights with last regressions but the phobos development is frozen. Or the other way around. There could be a couple of these ping-pongs during the process. And that's what I think we had and is suboptimal.

It's part of process to have a frozen view t in a form of staging branch but keep the master branch going. Otherwise it's just more branches (and pain) for no particular purpose.

> Without the 'ok, guys, focus in this smaller more critical subset of bugs' step, release branches would be created and
> never polished (or focused down to the release manager to do all the work if he's that skilled and/or generous of his time).
>

In the grander scale it boils down to managing who does what. Basically there should be a release check-list that everybody knows about: a list of issues and takers that currently work on them (Bugzilla provides that and should be more heavily used). If it's more or less covered (or nobody else could do it) the others may go on with the development on master.

The main problem I see with "everybody focus on these" is that I expect the number of contributors to grow but their area of expertise to get be more and more specialized (in general). Thus IMHO it won't scale.

> There's a phrase I'm trying to remember, but it's something to the effect that 'hope isn't a recipe for success.'
> Hoping that people fix regressions on release critical bugs isn't sufficient.  Incentive and steering is required.  The
> desire to ungate master branch merges is one approach that's been shown to be successful.
>
Yes. The focus of never stopping the development is to encourage new contributors by providing shorter feedback cycle.

-- 
Dmitry Olshansky
December 15, 2012
On Saturday, 15 December 2012 at 20:39:22 UTC, deadalnix wrote:
> On Saturday, 15 December 2012 at 20:32:42 UTC, Jesse Phillips wrote:
>> On Saturday, 15 December 2012 at 10:29:55 UTC, Dmitry Olshansky wrote:
>>> Second point is about merging master into staging - why not just rewrite it with master branch altogether after each release?
>>> master is the branch with correct history (all new stuff is rebased on it) thus new staging will have that too.
>>
>> Why you don't rewrite is because it is a public branch. Unlike feature branches which will basically be thrown out everyone on the development team will need to have staging updated. If we rewrite history then instead of
>>
>> $ git pull staging
>>
>> At random times it will be (I don't know the commands and won't even look it up)
>>
>> It just won't be pretty.
>>
>>
>> I've made modifications to the graphic hoping to illustrate some thoughts.
>>
>> http://i.imgur.com/rJVSg.png
>>
>> This does not depict what is currently described (in terms of branching). But is what I've written under http://wiki.dlang.org/Release_Process#Release_Schedule
>>
>> I see patches going into the LTS-1 (if applicable), the LTS-1 is then merged into the latest LTS, which is merged into any active staging, that is then merged into master.
>>
>> The monthly release don't get bug fixes (just wait for the next month).
>>
>> I've removed some version numbering since I don't know if we should have a distinct numbering for LTS and Monthly. I've already give some thoughts on this: http://forum.dlang.org/post/ydmgqmbqngwderfkljde@forum.dlang.org
>
> Can we drop the LTS name ? It reminds me of ubuntu, and I clearly hope that people promoting that idea don't plan to reproduce ubuntu's scheme :
>  - it is not suitable for a programming language (as stated 3 time now, so just read before why I won't repeat it).
>  - ubuntu is notoriously unstable.

Of course, lets just call it "stable", then. Or you have a better name?

Anyways, I do think that "stable" releases every 3 or more years and monthly or every 3 months releases are the best solution to the current D users.

-- Renato
December 16, 2012
On Saturday, 15 December 2012 at 19:03:49 UTC, Brad Roberts wrote:
> On 12/15/2012 2:29 AM, Dmitry Olshansky wrote:
>
>> I think one of major goals is to be able to continue ongoing development while at the _same time_ preparing a release.
>> To me number one problem is condensed in the statement "we are going to release do not merge anything but regressions"
>> the process should sidestep this "lock-based" work-flow. Could be useful to add something along these line to goals
>> section. (i.e. the speed and smoothness is a goal)
>
> I've been staying out of this thread for the most part, but I feel the need to comment on this part specifically.  It's
> quite common for most major projects to have a clear "we're wrapping up a release" phase where work _is_ restricted to
> bug fixing and stabilizing.  They don't stop people from working off in their development branches (no one could
> effectively impose such restrictions even if they wanted to), but they _do_ tighten down on what's allowed to be merged.
>
> This is a forcing function that's just required.  There's a lot of issues that otherwise won't get sufficient attention.
>  If all it took was altruism then regressions would be fixed immediately, bugs would always be fixed in highest priority
> to lowest priority (assuming that could even be effectively designed), etc.
>
> Without the 'ok, guys, focus in this smaller more critical subset of bugs' step, release branches would be created and
> never polished (or focused down to the release manager to do all the work if he's that skilled and/or generous of his time).
>
> There's a phrase I'm trying to remember, but it's something to the effect that 'hope isn't a recipe for success.'
> Hoping that people fix regressions on release critical bugs isn't sufficient.  Incentive and steering is required.  The
> desire to ungate master branch merges is one approach that's been shown to be successful.

I feel you've made a very important point here, and I've put up a section in the wiki process talk page devoted to the subject.

http://wiki.dlang.org/Talk:Release_Process#The_Path_of_Least_Resistance:_Incentives_and_Barriers

Although debating ideas in here is welcome, please be sure to post your ideas in the talk page, esp after there's a conclusion made, otherwise your excellent idea may vanish into the Ether and never become implemented as it should have been.

--rt
December 16, 2012
On Saturday, 15 December 2012 at 20:39:22 UTC, deadalnix wrote:
> Can we drop the LTS name ? It reminds me of ubuntu, and I clearly hope that people promoting that idea don't plan to reproduce ubuntu's scheme :
>  - it is not suitable for a programming language (as stated 3 time now, so just read before why I won't repeat it).

You don't need to repeat your self, you need to expand on your points. Joseph has already requested that you give specifics of your objection, you have explained why the situation is different but not what needs to be different.

Your points were specific to Debian's model, which is not Ubuntu's.

>  - ubuntu is notoriously unstable.

I don't know anyone who uses the LTS releases. That isn't to say no one is, but Ubuntu is doing a lot of experimenting in their 6 month releases.
December 16, 2012
On Sunday, 16 December 2012 at 02:03:34 UTC, Jesse Phillips wrote:
> On Saturday, 15 December 2012 at 20:39:22 UTC, deadalnix wrote:
>> Can we drop the LTS name ? It reminds me of ubuntu, and I clearly hope that people promoting that idea don't plan to reproduce ubuntu's scheme :
>> - it is not suitable for a programming language (as stated 3 time now, so just read before why I won't repeat it).
>
> You don't need to repeat your self, you need to expand on your points. Joseph has already requested that you give specifics of your objection, you have explained why the situation is different but not what needs to be different.
>
> Your points were specific to Debian's model, which is not Ubuntu's.
>
>> - ubuntu is notoriously unstable.
>
> I don't know anyone who uses the LTS releases. That isn't to say no one is, but Ubuntu is doing a lot of experimenting in their 6 month releases.

I think if we focus on the end results that the Ubuntu process is designed to accomplish and what the Debian is designed to accomplish we can start to think about which model is more likely to produce the desired results that we wish to achieve with the D process.

I'll sum it up as follows:

What both systems attempt to accomplish is in conflict, Ubuntu attempts to create a reasonably stable distribution with more recent updates so that users have access to current software, but that means there will be more bugs and less stability.

Debian attempts to distribute a bug free stable distribution, however the delays in getting there mean that the software is often much less current than what is currently available.

The end results may be summarized as follows:

I would *never* use Ubuntu for mission critical tasks, for example I would not use it to power a 24/7 remote server. I may use it for a workstation at home, but not at work, although I may use it at work if I needed access to the most current software.

Why not use it for mission critical tasks? Because it's unstable. Why is it unstable? Because it's based on Debian's unstable branch.

Debian stable on the other hand, is rock solid, and works well for mission critical tasks, and is suitable for use in a server environment, however, it does not come with the most current software, a some packages may be a couple of versions behind (which can be very frustrating at times).

So to achieve stability vs instability, you have to trade away less mature versions of software for older more mature versions of software.

Debian's process is design specifically for stability, Ubuntu's process is designed specifically to provide the most current software in a reasonably stable way.

--rt
December 16, 2012
On Thursday, 13 December 2012 at 07:18:16 UTC, foobar wrote:
>
> Per my answer to Rob:
> D2 *is* the major version.
> releases should be minor versions and largely backwards compatible - some evolution is allowed given some reasonable restrictions like a proper migration path over several releases.
> Critical bug-fixes can go directly on stable releases but nothing else.
>

I just realized that we are mixing together the version numbers for two entirely different things.

As you have correctly pointed out, one of the version numbers is for the D language specification, which is version 2.something, the other version is for the compiler releases, which has the major language specification version assigned to identify it as supporting version 2.something of the D language. The remaining numbers indicate incremental releases which may also roughly correspond to the minor evolutionary changes to the language specification, i.e., does DMD 2.061 also mean D specification 2.061?

I think it makes good sense that the "2" is used to indicate that the compiler supports D major version 2 of the specification, but we should all be clear that is all that it represents. Therefore DMD 3.x will never appear unless there's a D language ver 3 specification for it to support.

A completely separate issue that should be dealt with, is that the language specification's version number is not indicated anywhere that I could see. We just assume it's version 2.something and we have no idea where the "something" part is currently at or what has changed since ver 2.0. This is no good because it means that we cannot indicate in the compiler release change log what minor version of the 2.x specification the compiler is actually supporting.

--rt