Next focus: PROCESS

foobar foo at bar.com
Wed Dec 19 13:58:11 PST 2012


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.


More information about the Digitalmars-d mailing list