View mode: basic / threaded / horizontal-split · Log in · Help
July 16, 2012
Re: D versionning
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 :)
July 16, 2012
Re: D versionning
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
July 16, 2012
Re: D versionning
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 ?
July 16, 2012
Re: D versionning
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/
July 16, 2012
Re: D versionning
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
July 16, 2012
Re: D versionning
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
July 16, 2012
Re: D versionning
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/
July 16, 2012
Re: D versionning
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/
July 16, 2012
Re: D versionning
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
July 16, 2012
Re: D versionning
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
5 6 7 8 9 10 11 12 13
Top | Discussion index | About this forum | D home