D versionning

[Adam Wilson]

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

> On Sun, 15 Jul 2012 18:11:12 -0700, Andrei Alexandrescu  
> <SeeWebsiteForEmail at 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/