View mode: basic / threaded / horizontal-split · Log in · Help
December 19, 2012
Re: Next focus: PROCESS
On Wed, Dec 19, 2012 at 04:48:22PM -0500, Andrei Alexandrescu wrote:
> On 12/19/12 4:40 PM, deadalnix wrote:
> >On Wednesday, 19 December 2012 at 21:30:44 UTC, Andrei Alexandrescu wrote:
> >>On 12/19/12 4:23 PM, foobar wrote:
[...]
> >>>Let's generalize this point for the sake of reaching consensus - we
> >>>need _at least one_ "stable" branch which is separate from
> >>>"staging". We are still conflicted as to what should be the maximum
> >>>amount. For the record, I'm with the camp advocating at most a
> >>>fixed amount countable on one hand. That's an O(1) with a very
> >>>small constant as opposed to the O(n) suggestion by Andrei. I hope
> >>>Andrei appreciates the order of efficiency here.
> >>
> >>I agree with one "stable" branch.
> >>
> >
> >This does conflict with the requirement you gave before about being
> >able to support anything, as previous stable version cannot be
> >revised.
> >
> >Or does stable here mean supported ? (which means we still have
> >branch per version, but only one version is supported)
> 
> Walter needs to chime in about that. One possibility is to continue
> using tags for marking releases, and then branch for the few
> important releases that we want to patch.
[...]

This is a good idea, to avoid cluttering the git repo with branches.
(But then again, branches in git are cheap so I don't think this is
really that big of a deal.)


T

-- 
Just because you survived after you did it, doesn't mean it wasn't stupid!
December 19, 2012
Re: Next focus: PROCESS
On Wednesday, 19 December 2012 at 21:30:44 UTC, Andrei 
Alexandrescu wrote:
> On 12/19/12 4:23 PM, foobar wrote:
>> On Wednesday, 19 December 2012 at 20:51:57 UTC, deadalnix 
>> wrote:
>>> On Wednesday, 19 December 2012 at 19:56:47 UTC, Rob T wrote:
>>>
>>>> Do we all agree that we need a "stable" branch?
>>>>
>>>
>>> No. Stable isn't a boolean criteria. You'll find different 
>>> degree of
>>> stability going from not so stable (dev version) to very 
>>> stable (dead
>>> project).
>>>
>>> The wiki already mention a process with a branch per version 
>>> of the
>>> software.
>>
>> Let's generalize this point for the sake of reaching consensus 
>> - we need
>> _at least one_ "stable" branch which is separate from 
>> "staging". We are
>> still conflicted as to what should be the maximum amount. For 
>> the
>> record, I'm with the camp advocating at most a fixed amount 
>> countable on
>> one hand. That's an O(1) with a very small constant as opposed 
>> to the
>> O(n) suggestion by Andrei. I hope Andrei appreciates the order 
>> of
>> efficiency here.
>
> I agree with one "stable" branch.
>
> Andrei

That's great!
What about the other high level points summarized eloquently by 
H. S. Teoh?
Any other high level points or goals the process should 
incorporate?

Personally, I think the whole pre-development stage needs to get 
looks at -
Specifically having some sort of at least high-level *binding* 
planning - road map, mile stones, todo lists. This should give 
more weight to DIPs.
DIPs at the moment have no weight whatsoever. The attributes 
showed all the major flows in the decision making process:

1. Feature idea comes up in discussion.
2. Feature was discussed heavily by the community reaching some 
design consensus.
3. Plan is abandoned/forgotten due to Walter's objections - not 
to the design but the idea itself.
4. Feature comes up again in discussion, thus returning to point 
1 above in infinite loop.

** 5. After many cycles spanning years, the community accepts 
that the feature will never be added despite a consensus and 
constant demand.
5.1 Feature is added by surprise with deviations from consensus 
design, optionally integrates purely with other parts of the 
language.
5.1.1 Feature is final!

Another prime example is the auto-ref feature which we are stuck 
with because Walter apparently understood differently from what 
you intended.

This is highly coupled with Walter, making it very hard to agree 
on a high level design and delegate its implementation to other 
developers. As far as I see, No major feature was ever 
implemented by someone other than Walter and he has final say on 
all design decisions.

I agree with Walter's motives, he wants to stabilize the language 
and by resisting to feature suggestions he sets a very high bar 
for any major change. That is a good thing. The problem is that 
it all happens in his head and not in plain sight. The community 
has no idea what his plans are, I'm not convinced that even you 
get all the details. That means no planning ahead and no 
delegation. Had we known that Walter sign off featureX but just 
doesn't have the time to implement it, than it still would be on 
the official *binding* todo list and someone else would be able 
to implement this feature. As the situation now stands, no one 
will bother doing any significant work if it has a high chance of 
being entirely dismissed by Walter.
December 19, 2012
Re: Next focus: PROCESS
On Wednesday, 19 December 2012 at 21:48:22 UTC, Andrei 
Alexandrescu wrote:
> Walter needs to chime in about that. One possibility is to 
> continue using tags for marking releases, and then branch for 
> the few important releases that we want to patch.
>

Note that what is described on the wiki distinguish new version 
(that actually bring new stuff) and revision (that contains only 
bugfixes).

Does having branches that are not used anymore is a problem ? 
They'll not make the repository much bigger because the data is 
in history anyway.
December 19, 2012
Re: Next focus: PROCESS
On Wednesday, 19 December 2012 at 21:58:12 UTC, foobar wrote:
> On Wednesday, 19 December 2012 at 21:30:44 UTC, Andrei 
> Alexandrescu wrote:
>> On 12/19/12 4:23 PM, foobar wrote:
>>> On Wednesday, 19 December 2012 at 20:51:57 UTC, deadalnix 
>>> wrote:
>>>> On Wednesday, 19 December 2012 at 19:56:47 UTC, Rob T wrote:
>>>>
>>>>> Do we all agree that we need a "stable" branch?
>>>>>
>>>>
>>>> No. Stable isn't a boolean criteria. You'll find different 
>>>> degree of
>>>> stability going from not so stable (dev version) to very 
>>>> stable (dead
>>>> project).
>>>>
>>>> The wiki already mention a process with a branch per version 
>>>> of the
>>>> software.
>>>
>>> Let's generalize this point for the sake of reaching 
>>> consensus - we need
>>> _at least one_ "stable" branch which is separate from 
>>> "staging". We are
>>> still conflicted as to what should be the maximum amount. For 
>>> the
>>> record, I'm with the camp advocating at most a fixed amount 
>>> countable on
>>> one hand. That's an O(1) with a very small constant as 
>>> opposed to the
>>> O(n) suggestion by Andrei. I hope Andrei appreciates the 
>>> order of
>>> efficiency here.
>>
>> I agree with one "stable" branch.
>>
>> Andrei
>
> That's great!
> What about the other high level points summarized eloquently by 
> H. S. Teoh?
> Any other high level points or goals the process should 
> incorporate?
>
> Personally, I think the whole pre-development stage needs to 
> get looks at -
> Specifically having some sort of at least high-level *binding* 
> planning - road map, mile stones, todo lists. This should give 
> more weight to DIPs.
> DIPs at the moment have no weight whatsoever. The attributes 
> showed all the major flows in the decision making process:
>
> 1. Feature idea comes up in discussion.
> 2. Feature was discussed heavily by the community reaching some 
> design consensus.
> 3. Plan is abandoned/forgotten due to Walter's objections - not 
> to the design but the idea itself.
> 4. Feature comes up again in discussion, thus returning to 
> point 1 above in infinite loop.
>
> ** 5. After many cycles spanning years, the community accepts 
> that the feature will never be added despite a consensus and 
> constant demand.
> 5.1 Feature is added by surprise with deviations from consensus 
> design, optionally integrates purely with other parts of the 
> language.
> 5.1.1 Feature is final!
>
> Another prime example is the auto-ref feature which we are 
> stuck with because Walter apparently understood differently 
> from what you intended.
>
> This is highly coupled with Walter, making it very hard to 
> agree on a high level design and delegate its implementation to 
> other developers. As far as I see, No major feature was ever 
> implemented by someone other than Walter and he has final say 
> on all design decisions.
>
> I agree with Walter's motives, he wants to stabilize the 
> language and by resisting to feature suggestions he sets a very 
> high bar for any major change. That is a good thing. The 
> problem is that it all happens in his head and not in plain 
> sight. The community has no idea what his plans are, I'm not 
> convinced that even you get all the details. That means no 
> planning ahead and no delegation. Had we known that Walter sign 
> off featureX but just doesn't have the time to implement it, 
> than it still would be on the official *binding* todo list and 
> someone else would be able to implement this feature. As the 
> situation now stands, no one will bother doing any significant 
> work if it has a high chance of being entirely dismissed by 
> Walter.

The high-level steps as I see them:
1. The community discusses the merits and costs of the suggested 
feature and a consensus must be reached regarding adding such a 
feature.
2. An initial design must be provided - also with consensus. 
including this parts:
2.a. Suggested semantics of the feature - describe as precisely 
as possible
2.b. All interactions with other language features must be 
carefully examined and listed.
2.c An initial syntax agreed upon by the community.
3. Feature is implemented and after reaching some agreed upon 
level of stability is than field tested by the public.
3.1 Based on public feedback, feature design can be refined and 
bugs are fixed until consensus is reached that feature is ready 
to be finalized and merged to the next stable release.

It's vague on purpose - the exact details of how each point above 
is approved is to be decided later. The main principle is that 
approved planned features should be listed on the road map and 
point to their DIP with description of their design. Rejected 
features are also listed as DIPs with the rationale for the 
rejection, this is to avoid wasting time on repeat discussing 
them and requesting them.
Ultimate goal for all this is making the planning process as 
transparent as possible for the community.
December 19, 2012
Re: Next focus: PROCESS
On 12/19/12 5:07 PM, deadalnix wrote:
> On Wednesday, 19 December 2012 at 21:48:22 UTC, Andrei Alexandrescu wrote:
>> Walter needs to chime in about that. One possibility is to continue
>> using tags for marking releases, and then branch for the few important
>> releases that we want to patch.
>>
>
> Note that what is described on the wiki distinguish new version (that
> actually bring new stuff) and revision (that contains only bugfixes).
>
> Does having branches that are not used anymore is a problem ? They'll
> not make the repository much bigger because the data is in history anyway.

I kinda like the idea that we have tags for releases not planned for 
long term support and distinguished branches for those that we do. 
Clarifies intent a lot.

Andrei
December 19, 2012
Re: Next focus: PROCESS
On Wednesday, 19 December 2012 at 21:53:04 UTC, H. S. Teoh wrote:
> On Wed, Dec 19, 2012 at 04:48:22PM -0500, Andrei Alexandrescu 
> wrote:
>> On 12/19/12 4:40 PM, deadalnix wrote:
>> >On Wednesday, 19 December 2012 at 21:30:44 UTC, Andrei 
>> >Alexandrescu wrote:
>> >>On 12/19/12 4:23 PM, foobar wrote:
> [...]
>> >>>Let's generalize this point for the sake of reaching 
>> >>>consensus - we
>> >>>need _at least one_ "stable" branch which is separate from
>> >>>"staging". We are still conflicted as to what should be the 
>> >>>maximum
>> >>>amount. For the record, I'm with the camp advocating at 
>> >>>most a
>> >>>fixed amount countable on one hand. That's an O(1) with a 
>> >>>very
>> >>>small constant as opposed to the O(n) suggestion by Andrei. 
>> >>>I hope
>> >>>Andrei appreciates the order of efficiency here.
>> >>
>> >>I agree with one "stable" branch.
>> >>
>> >
>> >This does conflict with the requirement you gave before about 
>> >being
>> >able to support anything, as previous stable version cannot be
>> >revised.
>> >
>> >Or does stable here mean supported ? (which means we still 
>> >have
>> >branch per version, but only one version is supported)
>> 
>> Walter needs to chime in about that. One possibility is to 
>> continue
>> using tags for marking releases, and then branch for the few
>> important releases that we want to patch.
> [...]
>
> This is a good idea, to avoid cluttering the git repo with 
> branches.
> (But then again, branches in git are cheap so I don't think 
> this is
> really that big of a deal.)
>
>
> T

This has nothing to do with repository size, git optimizes that 
anyway.

This is a very good decision which I endorse (well, I suggested 
it in the first place..). Having a single stable branch helps 
integration and minimizes human error in the process.
December 19, 2012
Re: Next focus: PROCESS
On Wednesday, 19 December 2012 at 22:30:29 UTC, Andrei 
Alexandrescu wrote:
> On 12/19/12 5:07 PM, deadalnix wrote:
>> On Wednesday, 19 December 2012 at 21:48:22 UTC, Andrei 
>> Alexandrescu wrote:
>>> Walter needs to chime in about that. One possibility is to 
>>> continue
>>> using tags for marking releases, and then branch for the few 
>>> important
>>> releases that we want to patch.
>>>
>>
>> Note that what is described on the wiki distinguish new 
>> version (that
>> actually bring new stuff) and revision (that contains only 
>> bugfixes).
>>
>> Does having branches that are not used anymore is a problem ? 
>> They'll
>> not make the repository much bigger because the data is in 
>> history anyway.
>
> I kinda like the idea that we have tags for releases not 
> planned for long term support and distinguished branches for 
> those that we do. Clarifies intent a lot.
>

Should something be released if nobody will support it ?

If it is in order to provide overview of what is coming in the 
next version, I guess the best option is to provide a snapshot of 
the staging branch on regular basis (and call it beta or 
whatever).

Reading this answer, I start to think that we have something 
pretty close in mind but fail to explain it to each other.
December 19, 2012
Re: Next focus: PROCESS
On Wednesday, 19 December 2012 at 22:30:29 UTC, Andrei 
Alexandrescu wrote:
> On 12/19/12 5:07 PM, deadalnix wrote:
>> On Wednesday, 19 December 2012 at 21:48:22 UTC, Andrei 
>> Alexandrescu wrote:
>>> Walter needs to chime in about that. One possibility is to 
>>> continue
>>> using tags for marking releases, and then branch for the few 
>>> important
>>> releases that we want to patch.
>>>
>>
>> Note that what is described on the wiki distinguish new 
>> version (that
>> actually bring new stuff) and revision (that contains only 
>> bugfixes).
>>
>> Does having branches that are not used anymore is a problem ? 
>> They'll
>> not make the repository much bigger because the data is in 
>> history anyway.
>
> I kinda like the idea that we have tags for releases not 
> planned for long term support and distinguished branches for 
> those that we do. Clarifies intent a lot.
>

Let me propose an updated version of branches w have, according 
to what I understand here.  Note that I avoid using the term 
stable because I'm pretty sure it is a source of confusion and 
miscommunication.


master : used as a base for development. New feature are merged 
here.
staging : used to provide a view of what the next version will 
look like. Regular snapshot of that branch are made so public can 
use the last features.
version : used to contain a version that will have a support for 
an extended period of time.

If I understand correctly, version is what you call stable : a 
branch that is detached to provide long term support.
December 19, 2012
Re: Next focus: PROCESS
On 12/19/12 5:43 PM, deadalnix wrote:
> On Wednesday, 19 December 2012 at 22:30:29 UTC, Andrei Alexandrescu wrote:
>> On 12/19/12 5:07 PM, deadalnix wrote:
>>> On Wednesday, 19 December 2012 at 21:48:22 UTC, Andrei Alexandrescu
>>> wrote:
>>>> Walter needs to chime in about that. One possibility is to continue
>>>> using tags for marking releases, and then branch for the few important
>>>> releases that we want to patch.
>>>>
>>>
>>> Note that what is described on the wiki distinguish new version (that
>>> actually bring new stuff) and revision (that contains only bugfixes).
>>>
>>> Does having branches that are not used anymore is a problem ? They'll
>>> not make the repository much bigger because the data is in history
>>> anyway.
>>
>> I kinda like the idea that we have tags for releases not planned for
>> long term support and distinguished branches for those that we do.
>> Clarifies intent a lot.
>>
>
> Should something be released if nobody will support it ?

My understanding is that's what many projects do. Supporting each minor 
release would make for a ton of work.

> If it is in order to provide overview of what is coming in the next
> version, I guess the best option is to provide a snapshot of the staging
> branch on regular basis (and call it beta or whatever).

No, I'm not talking about previews.

> Reading this answer, I start to think that we have something pretty
> close in mind but fail to explain it to each other.

That's quite possible. Again, I'm not an expert in the matter and turned 
to the community for that reason. What we're looking for is a process 
that makes things better for everyone involved without having too much 
overhead.


Andrei
December 19, 2012
Re: Next focus: PROCESS
On Wednesday, 19 December 2012 at 23:08:59 UTC, Andrei 
Alexandrescu wrote:
> My understanding is that's what many projects do. Supporting 
> each minor release would make for a ton of work.
>

The whole point is to not support all minor release. Usually 
project supports one or 2 of them, that's it. Nobody win in 
supporting more.

For instance, python is supporting 2.7 and 3.3 .
PHP support 5.3 and 5.4 .
Ruby support 1.9 .
Java support 1.6 and 1.7 .
scala 2.8 and 2.9 .

As you can see, this is very common way of doing thing in the 
programming language world.

I propose to release snapshot of staging in order to allow for 
very few version branches to be created, while still alowing 
people to try the very last D, and so allow to support them for 
an extended period of time without havin to ends up in a 
maintenance hell.

>> If it is in order to provide overview of what is coming in the 
>> next
>> version, I guess the best option is to provide a snapshot of 
>> the staging
>> branch on regular basis (and call it beta or whatever).
>
> No, I'm not talking about previews.
>

Then call let's call it rolling release, release candidate, 
bleeding edge D, unstable, latest, whatever may fit depending on 
how high we raise the bar in terms of stability.
11 12 13 14 15 16 17
Top | Discussion index | About this forum | D home