Next focus: PROCESS

[deadalnix]

On Thursday, 20 December 2012 at 04:11:00 UTC, Jesse Phillips 
wrote:
> On Wednesday, 19 December 2012 at 23:05:59 UTC, deadalnix wrote:
>
>> master : used as a base for development. New feature are 
>> merged here.
>> staging : used to provide a view of what the next version will 
>> look like. Regular snapshot of that branch are made so public 
>> can use the last features.
>> version : used to contain a version that will have a support 
>> for an extended period of time.
>
> I do not see how development in master is moved to staging 
> based on this description. I'll try and be more specific.
>
> I realize you don't like features, but we need to talk about 
> Phobos additions, @property mechanics, and other highly 
> disruptive bugs. I'll call it the major-change.
>
> The major-change branch is generally developed to completion 
> and may just be a pull requests from developer342's master.
>
> From the sound of it this request is pulled into master. We 
> continue to pull many of these changes in. How do we decide 
> they should be placed into staging, when we pull them into 
> master?. If we wait for some 'magic time' how do we pull it 
> into staging, does that mean we now cherry pick commits of 
> master?
>
> Another issue is it sounds like master becomes a "phantom" 
> branch. At no point in time would master resemble what is 
> released. I see this as a problem because it is the branch 
> people are developing off of, it means nothing to test in 
> master as staging has the actual state that will be released.

That is very true. With the given modification master and 
stagging become redundant with one another. Why not get rid of 
stagging ?