View mode: basic / threaded / horizontal-split · Log in · Help
December 15, 2012
Re: Next focus: PROCESS
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
Re: Next focus: PROCESS
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
Re: Next focus: PROCESS
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
Re: Next focus: PROCESS
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
Re: Next focus: PROCESS
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
Re: Next focus: PROCESS
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
Re: Next focus: PROCESS
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
Re: Next focus: PROCESS
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
Re: Next focus: PROCESS
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
Re: Next focus: PROCESS
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
4 5 6 7 8 9 10 11 12
Top | Discussion index | About this forum | D home