On Monday, 16 July 2012 at 01:06:16 UTC, Adam Wilson wrote:
> On Sun, 15 Jul 2012 18:01:41 -0700, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:
>
>> On 7/15/12 7:15 PM, Patrick Stewart wrote:
>>> We are coming back to dsource&  Tango graveyard story. D had equally
>>> capable and large community to. Its resources got wasted. People
>>> left. Huge amount of work just wasted for nothing.
>>
>> Actually a couple of weeks ago I was curious and collected a few statistics about the frequency of posts, number of posters, and such. The numbers are not yet in shape to be published, but from what I gathered so far there was no visible glitch around the D1/D2 divergence. There's a strong increase since 2011, but I couldn't yet gather an exponential trend.
>>
>>> On the other hand,
>>> Python has one of the largest *operational* standard library and tons
>>> of 3rd party ones. Why? Because with stable language, all those
>>> libraries stayed in the game.
>>
>> Agreed, we have much to learn from Python and other successful languages.
>>
>> I assume those procedures and protocols materialized together with strong growth of the community, and may be difficult to transplant to our team. Right now my main focus as an organizer is to make sure people's cycles are spent on productive, high-impact work. Right now Walter is working on Win64, which is of very high impact. A change of procedure right now would simply mean time taken away from that task.
>>
>> Finally, since you are interested in effecting durable positive change in D's development, I'll venture that perhaps you're not going the best way about it. Your posts attempt almost with no exception to inflame, and there's no contribution I know of in your name. That all reduces the credibility of your points, however merit there may be in them.
>>
>>
>> Thanks,
>>
>> Andrei
>
> I would like to state that I am all for waiting onr Win64; it's a huge project and trying to do this change in the middle of it would be the height of stupidity. However, directly after Win64 goes live I move that we make the dual branch model the default going forward as it solves too many long-standing community complaints to reasonably dismiss.

+1

I think that model proposed by deadalnix would drastically increase productivity  of D development cycle and would cover needs of those who like to feel "stable" with their software.

Lets learn from bigger, successful projects :)

On Sunday, July 15, 2012 21:11:12 Andrei Alexandrescu wrote:
> On 7/15/12 7:44 PM, Adam Wilson wrote:
> > I should note that we use this exact model for every project we have where I work and that it is been highly successful at keeping those five points of tension moderated. And our users can actually get work done without waiting for weeks and months because thing X is just plain broken, which in turn makes us look good. (Improving Loyalty)
> 
> Allow me to propose something.
> 
> Right now all dmd changes get merged in the head. Suppose we find a volunteer in the community who is:
> 
> 1. Highly motivated
> 
> 2. With a good understanding of D
> 
> 3. Expert with git
> 
> 4. Reliable
> 
> I wonder if it's possible that that person cherry-picks commits from HEAD into two separate branches: bugfixes and unstable. It should be easy to create installers etc. for those.
> 
> If we see this works well and gathers steady interest, we can improve it and make it the practice of the entire team.
> 
> Would this be possible?

I'm sure it's possible. The problem is that it requires someone who understands the compiler well enough to do it and is willing to take the time to do it. Such a person could be very hard to find. It would probably require that one of our primary contributors to the compiler use some of the time that they've been using for that to maintain the new bug fix-only branch. It may very well be worth it to do so, but we'll need a volunteer.

- Jonathan M Davis

On 16/07/2012 03:11, Andrei Alexandrescu wrote:
> On 7/15/12 7:44 PM, Adam Wilson wrote:
>> I should note that we use this exact model for every project we have
>> where I work and that it is been highly successful at keeping those five
>> points of tension moderated. And our users can actually get work done
>> without waiting for weeks and months because thing X is just plain
>> broken, which in turn makes us look good. (Improving Loyalty)
>
> Allow me to propose something.
>
> Right now all dmd changes get merged in the head. Suppose we find a
> volunteer in the community who is:
>
> 1. Highly motivated
>
> 2. With a good understanding of D
>
> 3. Expert with git
>
> 4. Reliable
>
> I wonder if it's possible that that person cherry-picks commits from
> HEAD into two separate branches: bugfixes and unstable. It should be
> easy to create installers etc. for those.
>
> If we see this works well and gathers steady interest, we can improve it
> and make it the practice of the entire team.
>
> Would this be possible?
>
>
> Andrei
>

What would be the difference betwwen dmd head and unstable ?

Isn't it more simple to merge in unstable only or both unstable and bugfix at first ?

On Sun, 15 Jul 2012 18:11:12 -0700, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:

> On 7/15/12 7:44 PM, Adam Wilson wrote:
>> I should note that we use this exact model for every project we have
>> where I work and that it is been highly successful at keeping those five
>> points of tension moderated. And our users can actually get work done
>> without waiting for weeks and months because thing X is just plain
>> broken, which in turn makes us look good. (Improving Loyalty)
>
> Allow me to propose something.
>
> Right now all dmd changes get merged in the head. Suppose we find a volunteer in the community who is:
>
> 1. Highly motivated
>
> 2. With a good understanding of D
>
> 3. Expert with git
>
> 4. Reliable
>
> I wonder if it's possible that that person cherry-picks commits from HEAD into two separate branches: bugfixes and unstable. It should be easy to create installers etc. for those.
>
> If we see this works well and gathers steady interest, we can improve it and make it the practice of the entire team.
>
> Would this be possible?
>
>
> Andrei

I like this, A LOT! This is a nice twist on the proposed model and I think it improves on the process. It certainly means that no release is predicated on the state of HEAD, which is a fantastic achievement. And this process certainly wasn't possible prior to git.

It also achieves to goal of separate branches for unstable work and stable bugfixes.

I may just co-opt this for my projects at work!

However, this is all predicated on finding such a person, of which few exist. But I would argue that it should NOT fall on to someone in the core team (Walter, Kenji, Braddr, Don, etc.), they should be working on the compiler HEAD.

There must be someone out there with decent knowledge of the internals and yet doesn't consider themselves core team, but the biggest them I think is going to be the time, which is why I think it shouldn't be a core team member.

Actually, here is another idea. How about we train someone who maybe has some experience with the compiler but might not know what to do in all situations. If they had direct access to Walter and the Core Team, they could be quickly brought up to speed on the job so to speak. And it would widen our potential volunteer poll.
Plus it would widen the number of team members who are deeply involved with the compiler. Reducing our bus-factor is always a very good thing.

If the core team was willing to accept an apprentice, then I would be willing to learn. As far as git goes, the only thing I don't have much experience with is reversions, the rest I can handle, we use git internally at work so it's very familiar to me. But I'd want to see if anyone else more qualified than I was willing to volunteer first!

-- 
Adam Wilson
IRC: LightBender
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/

On 16-07-2012 03:11, Andrei Alexandrescu wrote:
> On 7/15/12 7:44 PM, Adam Wilson wrote:
>> I should note that we use this exact model for every project we have
>> where I work and that it is been highly successful at keeping those five
>> points of tension moderated. And our users can actually get work done
>> without waiting for weeks and months because thing X is just plain
>> broken, which in turn makes us look good. (Improving Loyalty)
>
> Allow me to propose something.
>
> Right now all dmd changes get merged in the head. Suppose we find a
> volunteer in the community who is:
>
> 1. Highly motivated
>
> 2. With a good understanding of D
>
> 3. Expert with git
>
> 4. Reliable
>
> I wonder if it's possible that that person cherry-picks commits from
> HEAD into two separate branches: bugfixes and unstable. It should be
> easy to create installers etc. for those.
>
> If we see this works well and gathers steady interest, we can improve it
> and make it the practice of the entire team.
>
> Would this be possible?
>
>
> Andrei
>

I propose a slight variation:

* master: This is the 'incoming' branch. Unstable, in-dev, etc. It's easier this way since pull requests will usually target this branch and build bots will test this.
* stable: This branch contains only bug fixes to existing language features, and enhancements that do not in any way impact existing features (or break code). Should be manually maintained based on master.

That's it. I don't see a need for any added complexity to this simple model. Feel free to destroy as you see fit, though!

-- 
Alex Rønne Petersen
alex@lycus.org
http://lycus.org

On Monday, July 16, 2012 03:38:37 Alex Rønne Petersen wrote:
> I propose a slight variation:
> 
> * master: This is the 'incoming' branch. Unstable, in-dev, etc. It's
> easier this way since pull requests will usually target this branch and
> build bots will test this.
> * stable: This branch contains only bug fixes to existing language
> features, and enhancements that do not in any way impact existing
> features (or break code). Should be manually maintained based on master.
> 
> That's it. I don't see a need for any added complexity to this simple model. Feel free to destroy as you see fit, though!

I agree that that's probably better, since I don't see much point in separating unstable from master either, but the main problem is still having someone who is able and willing to do the merging into the bug fix branch.

- Jonathan M Davis

On Sun, 15 Jul 2012 18:38:37 -0700, Alex Rønne Petersen <alex@lycus.org> wrote:

> On 16-07-2012 03:11, Andrei Alexandrescu wrote:
>> On 7/15/12 7:44 PM, Adam Wilson wrote:
>>> I should note that we use this exact model for every project we have
>>> where I work and that it is been highly successful at keeping those five
>>> points of tension moderated. And our users can actually get work done
>>> without waiting for weeks and months because thing X is just plain
>>> broken, which in turn makes us look good. (Improving Loyalty)
>>
>> Allow me to propose something.
>>
>> Right now all dmd changes get merged in the head. Suppose we find a
>> volunteer in the community who is:
>>
>> 1. Highly motivated
>>
>> 2. With a good understanding of D
>>
>> 3. Expert with git
>>
>> 4. Reliable
>>
>> I wonder if it's possible that that person cherry-picks commits from
>> HEAD into two separate branches: bugfixes and unstable. It should be
>> easy to create installers etc. for those.
>>
>> If we see this works well and gathers steady interest, we can improve it
>> and make it the practice of the entire team.
>>
>> Would this be possible?
>>
>>
>> Andrei
>>
>
> I propose a slight variation:
>
> * master: This is the 'incoming' branch. Unstable, in-dev, etc. It's easier this way since pull requests will usually target this branch and build bots will test this.
> * stable: This branch contains only bug fixes to existing language features, and enhancements that do not in any way impact existing features (or break code). Should be manually maintained based on master.
>
> That's it. I don't see a need for any added complexity to this simple model. Feel free to destroy as you see fit, though!

I think this would work very well. When it comes time to roll out new features, you could just merge master into stable and you've got a brand new stable release, tag it, build an installer, and you're done.

-- 
Adam Wilson
IRC: LightBender
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/

On Sun, 15 Jul 2012 18:28:36 -0700, Adam Wilson <flyboynw@gmail.com> wrote:

> On Sun, 15 Jul 2012 18:11:12 -0700, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:
>
>> On 7/15/12 7:44 PM, Adam Wilson wrote:
>>> I should note that we use this exact model for every project we have
>>> where I work and that it is been highly successful at keeping those five
>>> points of tension moderated. And our users can actually get work done
>>> without waiting for weeks and months because thing X is just plain
>>> broken, which in turn makes us look good. (Improving Loyalty)
>>
>> Allow me to propose something.
>>
>> Right now all dmd changes get merged in the head. Suppose we find a volunteer in the community who is:
>>
>> 1. Highly motivated
>>
>> 2. With a good understanding of D
>>
>> 3. Expert with git
>>
>> 4. Reliable
>>
>> I wonder if it's possible that that person cherry-picks commits from HEAD into two separate branches: bugfixes and unstable. It should be easy to create installers etc. for those.
>>
>> If we see this works well and gathers steady interest, we can improve it and make it the practice of the entire team.
>>
>> Would this be possible?
>>
>>
>> Andrei
>
> I like this, A LOT! This is a nice twist on the proposed model and I think it improves on the process. It certainly means that no release is predicated on the state of HEAD, which is a fantastic achievement. And this process certainly wasn't possible prior to git.
>
> It also achieves to goal of separate branches for unstable work and stable bugfixes.
>
> I may just co-opt this for my projects at work!
>
> However, this is all predicated on finding such a person, of which few exist. But I would argue that it should NOT fall on to someone in the core team (Walter, Kenji, Braddr, Don, etc.), they should be working on the compiler HEAD.
>
> There must be someone out there with decent knowledge of the internals and yet doesn't consider themselves core team, but the biggest them I think is going to be the time, which is why I think it shouldn't be a core team member.
>
> Actually, here is another idea. How about we train someone who maybe has some experience with the compiler but might not know what to do in all situations. If they had direct access to Walter and the Core Team, they could be quickly brought up to speed on the job so to speak. And it would widen our potential volunteer poll.
> Plus it would widen the number of team members who are deeply involved with the compiler. Reducing our bus-factor is always a very good thing.
>
> If the core team was willing to accept an apprentice, then I would be willing to learn. As far as git goes, the only thing I don't have much experience with is reversions, the rest I can handle, we use git internally at work so it's very familiar to me. But I'd want to see if anyone else more qualified than I was willing to volunteer first!
>

As an addition to my training proposal, I submit that we make it two people, to account for vacations and other times when one person may not be available. Although I imagine that anything beyond two people might be a little more than the core team can handle, and I can't see it being that much work that we'd need three people.

-- 
Adam Wilson
IRC: LightBender
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/

On 7/15/12 9:21 PM, deadalnix wrote:
> What would be the difference betwwen dmd head and unstable ?
>
> Isn't it more simple to merge in unstable only or both unstable and
> bugfix at first ?

I think you're right, we only need the "stable/bugfix" branch.

Andrei

On 2012-07-15 17:35, Walter Bright wrote:
> On 7/15/2012 10:25 AM, captaindet wrote:
>> pls make a fresh build available on a weekly or at least biweekly basis, just
>> with regressions fixed.
>
> 2.059 had only 3 outstanding regressions.

my bad. i got the impression regressions were a bigger issue.

just want to add that i am really happy 64bit for windows is about to happen. i should not whinge if this means other things have to slow down a bit for the time being. after all, i am not helping but just enjoying the free beer...

/det