On Thursday, 29 November 2012 at 21:36:46 UTC, deadalnix wrote:
> On Thursday, 29 November 2012 at 21:19:02 UTC, Jacob Carlborg wrote:
>> That's not what I've heard. Minor could be new features, as long as they don't break anything. But that might be more for libraries, i.e. adding a new function.
>
> Exactly.

Yes, after posting I thought that part was perhaps debatable.

The real challenge is how to implement something like this in a reasonable time frame.

Who has the means to make it so?

--rt

On Thursday, November 29, 2012 22:01:46 Rob T wrote:
> On Thursday, 29 November 2012 at 20:54:33 UTC, Jacob Carlborg
> 
> wrote:
> > On 2012-11-29 17:12, H. S. Teoh wrote:
> >> Didn't Walter already say that if somebody steps up to do it,
> >> he would
> >> endorse it?
> > 
> > Not what I've seen. At least not something more in those words.
> 
> What's needed is a core team of decision makers who have real decision making abilities. There's a reason why dictatorships usually perform poorly relative to other more advanced systems of decision making.

The benevolent dictator model is quite common in open source software development. There needs to be a team to support that if you want to really be a team project rather than one person's pet project, and it's not like the dictator decides everything, but having one person with the final say can be very beneficial.

http://en.wikipedia.org/wiki/Benevolent_Dictator_For_Life

But as it stands, there's plenty of decision making that goes on outside of Walter with regards to Phobos. In fact, he's not involved with Phobos much at all at this point. It's really just the language and the compiler over which Walter exercises that level of control.

- Jonathan M Davis

On Thursday, 29 November 2012 at 22:12:08 UTC, Jonathan M Davis wrote:
> The benevolent dictator model is quite common in open source software
> development. There needs to be a team to support that if you want to really be
> a team project rather than one person's pet project, and it's not like the
> dictator decides everything, but having one person with the final say can be
> very beneficial.

Fair enough, I can accept that, and will even agree with it.

> http://en.wikipedia.org/wiki/Benevolent_Dictator_For_Life
>
> But as it stands, there's plenty of decision making that goes on outside of
> Walter with regards to Phobos. In fact, he's not involved with Phobos much at
> all at this point. It's really just the language and the compiler over which
> Walter exercises that level of control.
>
> - Jonathan M Davis

In my view, the biggest problem that I see is how the project development is structured, so if anything is to change for the better in a significant way, it will be with changing the development process, and that should have no effect on Walter's status as a benevolent dictator (something which I have no reason at all to question), but it should create a sense of stability and a much smoother release process for everyone concerned.

Seriously, how many years has the D community been operating in this way, 10 or more?

There's not a heck of a lot here to debate other than to simply start the process of switching over to a more stable and efficient development process.


--rt

On 11/29/12, Rob T <rob@ucora.com> wrote:
> Seriously, how many years has the D community been operating in this way, 10 or more?

Not really, the D team switched to Git only recently (maybe 1+ years
now?). Imo what's really lacking is (wo)manpower, not the process
(which can of course always be improved).

On Friday, November 30, 2012 01:21:06 Andrej Mitrovic wrote:
> On 11/29/12, Rob T <rob@ucora.com> wrote:
> > Seriously, how many years has the D community been operating in this way, 10 or more?
> 
> Not really, the D team switched to Git only recently (maybe 1+ years
> now?). Imo what's really lacking is (wo)manpower, not the process
> (which can of course always be improved).

And D2 has only been around for about 5 years. Things have change a lot over time - particularly with the introduction of github. We have _far_ more community involvement than we used to. But the process definitely still needs improvement (e.g. we need to actually take advantage of git's branching capabilities). But historically, the main problem has always been a lack of manpower, and that's still an issue. It's just not as big an issue as it used to be.

If anything the problems with the current process stem from moving to github and getting more contributors. A lot of how the process has worked worked just fine with svn and fewer people. But the project is growing and we need to adjust.

- Jonathan M Davis

On Friday, 30 November 2012 at 00:21:17 UTC, Andrej Mitrovic wrote:
> On 11/29/12, Rob T <rob@ucora.com> wrote:
>> Seriously, how many years has the D community been operating in
>> this way, 10 or more?
>
> Not really, the D team switched to Git only recently (maybe 1+ years
> now?).

If the problem here is just some growing pains to deal with, then we're in a good position to move forward.

> Imo what's really lacking is (wo)manpower, not the process
> (which can of course always be improved).

If we're lacking in manpower, then how do we attract a larger force of talented and dedicated volunteers?

My answer is that an improved process that's done right will allow us to get more quality work done faster with the same work force, and that in turns helps to motivate new people to sign up and stay signed up. So what's primarily lacking is a good process, what follows will be an improved work force, and following that a growing work force.

Anyone have a better answer?

--rt

On 11/29/2012 11:44 PM, Rob T wrote:
> On Friday, 30 November 2012 at 00:21:17 UTC, Andrej Mitrovic wrote:
>> On 11/29/12, Rob T <rob@ucora.com> wrote:
>>> Seriously, how many years has the D community been operating in
>>> this way, 10 or more?
>>
>> Not really, the D team switched to Git only recently (maybe 1+ years
>> now?).
>
> If the problem here is just some growing pains to deal with, then we're
> in a good position to move forward.
>
>> Imo what's really lacking is (wo)manpower, not the process
>> (which can of course always be improved).
>
> If we're lacking in manpower, then how do we attract a larger force of
> talented and dedicated volunteers?
>
> My answer is that an improved process that's done right will allow us to
> get more quality work done faster with the same work force, and that in
> turns helps to motivate new people to sign up and stay signed up. So
> what's primarily lacking is a good process, what follows will be an
> improved work force, and following that a growing work force.
>
> Anyone have a better answer?
>
> --rt
>
>
>

Yes!  That's exactly how I feel.

On 11/28/2012 09:32 AM, bearophile wrote:
> Walter Bright:
>
>> I can see creating a stable D2 and a forward D2 for 6 months at a time
>> or so, as has been proposed here. I think that's a good idea. But only
>> after D1 is no longer supported.
>
> I am OK with such ideas. Below there are some musings.
>
> How do you want to call (release numbers) those two D2 versions
> (Stable-D and Development-D)? I prefer a simple Python-like numbering
> scheme, where the second digit denotes significant changes (every 6
> months?) and the third digit (plus alpha, beta, rc1, rc2, rc3, ...
> suffixes) refers to bug fixes that don't break much code. I think such
> numbering scheme is also able to make D look a little more mature and a
> bit more "professional".
>
> I also think it's a bad idea to create a "D3", at the moment. This means
> I suggest to eventually merge in the Stable-D all the changes of
> Development-D (unless testing of the Development version shows that it's
> better to abandon an idea in both D2 branches).
>
> I suggest to release Development-D quite often, like every 20-35 days,
> if it's possible.
>
> The presence of Development-D should allow for a more relaxed
> development, bug fixing and more. There are several things to fix. One
> of such possible changes is to remove the inliner from the D front-end
> (because ldc2 and gdc2 don't use it). Making the front-end a slimmer is
> good. There are other changes worth considering, like aligning D ABI and
> function calls (as other compilers refuse or can't do those things).
> LDC2 will be probably quite used on Windows64bit.
>
> Patches for Development-D should work in both D2 versions, unless the
> changes are about features not yet present in Stable-D.
>
> For simplicity I think the first thing to do to go toward the first
> Stable-D version should be strip away the D1 parts from the D2 Git
> sources, to clean and shorten the D2 code and make its updates simpler.
>
Added to my things first list.

> As others have said I think it's better to not keep a single
> Development-D trunk, but branch it when new features (or significant
> changes) are developed (like UDA).

>
> Bye,
> bearophile