Next focus: PROCESS

[foobar]

On Wednesday, 19 December 2012 at 21:53:04 UTC, H. S. Teoh wrote:
> On Wed, Dec 19, 2012 at 04:48:22PM -0500, Andrei Alexandrescu 
> wrote:
>> On 12/19/12 4:40 PM, deadalnix wrote:
>> >On Wednesday, 19 December 2012 at 21:30:44 UTC, Andrei 
>> >Alexandrescu wrote:
>> >>On 12/19/12 4:23 PM, foobar wrote:
> [...]
>> >>>Let's generalize this point for the sake of reaching 
>> >>>consensus - we
>> >>>need _at least one_ "stable" branch which is separate from
>> >>>"staging". We are still conflicted as to what should be the 
>> >>>maximum
>> >>>amount. For the record, I'm with the camp advocating at 
>> >>>most a
>> >>>fixed amount countable on one hand. That's an O(1) with a 
>> >>>very
>> >>>small constant as opposed to the O(n) suggestion by Andrei. 
>> >>>I hope
>> >>>Andrei appreciates the order of efficiency here.
>> >>
>> >>I agree with one "stable" branch.
>> >>
>> >
>> >This does conflict with the requirement you gave before about 
>> >being
>> >able to support anything, as previous stable version cannot be
>> >revised.
>> >
>> >Or does stable here mean supported ? (which means we still 
>> >have
>> >branch per version, but only one version is supported)
>> 
>> Walter needs to chime in about that. One possibility is to 
>> continue
>> using tags for marking releases, and then branch for the few
>> important releases that we want to patch.
> [...]
>
> This is a good idea, to avoid cluttering the git repo with 
> branches.
> (But then again, branches in git are cheap so I don't think 
> this is
> really that big of a deal.)
>
>
> T

This has nothing to do with repository size, git optimizes that 
anyway.

This is a very good decision which I endorse (well, I suggested 
it in the first place..). Having a single stable branch helps 
integration and minimizes human error in the process.