On 11/13/2013 4:38 PM, Manu wrote:
> How about the rvalue-temp -> ref thing? That's getting REALLY tired.

I know, I know :-(

On 14 November 2013 20:51, Walter Bright <newshound2@digitalmars.com> wrote:

> On 11/13/2013 4:38 PM, Manu wrote:
>
>> How about the rvalue-temp -> ref thing? That's getting REALLY tired.
>>
>
> I know, I know :-(
>

So, 2.065 then :P

On Saturday, 9 November 2013 at 00:32:56 UTC, Walter Bright wrote:
> On 11/8/2013 3:33 PM, deadalnix wrote:
>> Getting a build master :D
>
> We clearly need a better title!

There is a title for that already in the IT world: RELEASE MANAGER.

However, D project is chaos without any kind of management... Moving to GitHub improved little bit, but from a software engineering point of view it is far from a serious thing.

This "Agenda" is what agile world typically calls a SPRINT/ITERATION BACKLOG. As far as I know, nobody grooms the DMD/Phobos backlog, people take items they like, or feel challenged by.

I know many people have bad opinion about agile process tools such as Scrum, Kanban, XP, etc, but any organised way of doing things is better than chaos, unless you prefer the anarchy as seen in the Fred George's presentation (which I recommend - http://www.youtube.com/watch?v=uk-CF7klLdA). Do not get me wrong, I actually agree with Fred, but we do not have the environment that is clearly needed for his kind of "software anarchy".

Are bugzilla votes respected btw?

On Thursday, 14 November 2013 at 12:00:26 UTC, Dejan Lekic wrote:
> On Saturday, 9 November 2013 at 00:32:56 UTC, Walter Bright wrote:
>> On 11/8/2013 3:33 PM, deadalnix wrote:
>>> Getting a build master :D
>>
>> We clearly need a better title!
>
> There is a title for that already in the IT world: RELEASE MANAGER.
>
> However, D project is chaos without any kind of management... Moving to GitHub improved little bit, but from a software engineering point of view it is far from a serious thing.
>
> This "Agenda" is what agile world typically calls a SPRINT/ITERATION BACKLOG. As far as I know, nobody grooms the DMD/Phobos backlog, people take items they like, or feel challenged by.
>
> I know many people have bad opinion about agile process tools such as Scrum, Kanban, XP, etc, but any organised way of doing things is better than chaos, unless you prefer the anarchy as seen in the Fred George's presentation (which I recommend - http://www.youtube.com/watch?v=uk-CF7klLdA). Do not get me wrong, I actually agree with Fred, but we do not have the environment that is clearly needed for his kind of "software anarchy".
>
> Are bugzilla votes respected btw?

Scrum etc is for commercial software development. It does not really work for Open Source development, because people will always work on what they personally consider most important and most interesting. In the agile world there is a customer, who prioritizes work items. This cannot be applied here.

Bugzilla votes and stuff are nice to let devs know about bugs, but not necessarily motivates to fix them.

> Scrum etc is for commercial software development. It does not really work for Open Source development, because people will always work on what they personally consider most important and most interesting. In the agile world there is a customer, who prioritizes work items. This cannot be applied here.
>
> Bugzilla votes and stuff are nice to let devs know about bugs, but not necessarily motivates to fix them.

My Scrum experience tells me to humbly disagree because Scrum like all other agile process tools is all about experimentation. Almost all Scrum practices are applicable in open-source world. No Scrum team works the same as the other, they all have different ways of applying Scrum (that is why it is called a "process tool", not a methodology as many people use to call it).

Kanban is (IMHO) even more applicable in the open-source world as it has only two prescribed practices, the rest is up to the team to apply any agile practice they think will help the project...

Take a look how "big open-source guys" do things. Their core team (typically full-time employed) works on whatever is on the sprint backlog, while contributors all around the world take whatever they like working on (with help of mentors quite often). So, it is possible to have a nicely organised open-source project, if people are willing to do so.

On 11/14/13 10:23 AM, Dejan Lekic wrote:
>> Scrum etc is for commercial software development. It does not really work for Open Source
>> development, because people will always work on what they personally consider most important and
>> most interesting. In the agile world there is a customer, who prioritizes work items. This cannot
>> be applied here.
>>
>> Bugzilla votes and stuff are nice to let devs know about bugs, but not necessarily motivates to
>> fix them.
>
> My Scrum experience tells me to humbly disagree because Scrum like all other agile process tools is
> all about experimentation. Almost all Scrum practices are applicable in open-source world. No Scrum
> team works the same as the other, they all have different ways of applying Scrum (that is why it is
> called a "process tool", not a methodology as many people use to call it).
>
> Kanban is (IMHO) even more applicable in the open-source world as it has only two prescribed
> practices, the rest is up to the team to apply any agile practice they think will help the project...
>
> Take a look how "big open-source guys" do things. Their core team (typically full-time employed)
> works on whatever is on the sprint backlog, while contributors all around the world take whatever
> they like working on (with help of mentors quite often). So, it is possible to have a nicely
> organised open-source project, if people are willing to do so.

Which is pretty much exactly what we have.  All the paid developers (no one) follow a core mission, and all the volunteers scratch the itch they want to address the most.

More seriously, can you look at the linux kernel, or any of the major browser projects, or any of the major gui tool kits, or... and find a nice clear list of what's going to be in them before they release?  Maybe close to the end of the release, but before or at the beginning of the cycle?

More organization would be nice, but let's not ascribe too much faith that we're all _that_ different from many other projects.  I think a key difference is that we have so many more big things that aren't near where we want them to be that it's easier to be unhappy.