Next focus: PROCESS

[foobar]

On Friday, 21 December 2012 at 18:34:12 UTC, Rob T wrote:
> On Thursday, 20 December 2012 at 23:43:12 UTC, Joseph Cassman 
> wrote:
>> Just some food for thought.
>>
>> In the section about the "Branching model", the wiki currently 
>> has a staging branch in addition to the master branch. From 
>> what I understand, the idea seems to be to vet a release on 
>> staging until it is considered production level and then 
>> marked as the release.
>>
>> Another idea could be to keep the quality of the master branch 
>> at a high level so as to be able to branch into a release at 
>> any time, directly from master. Before feature branches are 
>> merged back into master, their quality is vetted so the 
>> quality of master is maintained.
>>
>> This idea seems similar to what is used for the vibe.d project 
>> (http://vibed.org/temp/branch-model-small.png). My apologies 
>> if I misunderstood their process.
>>
>> It looks like Xamarin has been using this process for a while 
>> and it seems to be working for them. 
>> http://tirania.org/blog/archive/2011/Oct-14.html
>>
>> Joseph
>
> Doesn't that just turn master into staging, and turn the 
> feature branches into a diluted and distributed version of 
> master?
>
> If there's no common development branch to work with that 
> integrates the most current features together, then how will 
> such a thing ever be properly tested before going into a high 
> quality common branch?
>
> We also need the ability to stop brand new poorly tested 
> features from making their way into a release, so at some point 
> a common pre-release branch needs to be frozen from receiving 
> any new features so that it can be honed into a high quality 
> product. If you use the master branch for such a thing, then no 
> new features can go into it, so with master frozen, what common 
> branch is available for the devs to merge their new work into?
>
> --rt

Precisely.
I think people just don't understand the purpose of these 
additional branches. The point being - integration.

The general flow of events should be:
1. Developer has cool idea/feature which he explores on a 
separate private "feature branch"
2. During development of the feature the developer can optionally 
collaborate with other developers. This can be done either by 
pulling from other developers' repositories directly or by 
pushing to a branch on github. Either way, this is an ad hoc "my 
new feature" branch.
3. First level of integration - feature is complete and is merged 
into official first level of integration - the "dev" branch 
(consensus was to use master for that)
4. Feature can than be further refined and _integration bugs_ can 
be fixed by the general dev team.
5. When the "dev" branch is considered stable enough by the team 
(exact criteria to be defined later), the changes are merged to 
the _2nd level of integration_ - the "staging" branch. This 
allows for a wider audience to test and provide real-world 
feedback.
6. when the 2nd level of integration is complete, the changes are 
stable enough to be released and the included features finalized.

Since git provides each developer with their own private copy of 
the entire repository there is *no need* to define any official 
processes prior to initial integration. The developers are free 
to collaborate by using ad hoc branches. The only common sense 
recommendation I'd give (again, NOT part of the _official 
process_) is to use meaningful branch names if they are meant to 
be shared with other people.