Next focus: PROCESS

[Dmitry Olshansky]

12/14/2012 3:34 AM, deadalnix пишет:
> On Thursday, 13 December 2012 at 20:48:30 UTC, deadalnix wrote:
>> On Thursday, 13 December 2012 at 20:04:50 UTC, Dmitry Olshansky wrote:
>>> I think it's good.
>>>
>>> But personally I'd expect:
>>>
>>> * master to be what you define as dev, because e.g. GitHub puts
>>> master as default target branch when making pull requests. Yeah, I
>>> know it's their quirk that it's easy to miss. Still leaving less
>>> burden to check the branch label for both reviewers and pull authors
>>> is a net gain.
>>>
>>> * And what you describe as master (it's a snapshot or a pre-release
>>> to me) to be named e.g. staging.
>>>
>>> And we can as well drop the dead branch 'dev' then.
>>
>> That sound also like a good plan to me.
>
> Updated to follow the idea, plus added bunch of process description.
> Feel free to comment in order to refine this.
>
> http://wiki.dlang.org/Release_Process

I wasn't comfortable doing speculative edits to the wiki directly so 
here a few more comments:

I think one of major goals is to be able to continue ongoing development 
while at the _same time_ preparing a release. To me number one problem 
is condensed in the statement "we are going to release do not merge 
anything but regressions" the process should sidestep this "lock-based" 
work-flow. Could be useful to add something along these line to goals 
section. (i.e. the speed and smoothness is a goal)

Second point is about merging master into staging - why not just rewrite 
it with master branch altogether after each release?
master is the branch with correct history (all new stuff is rebased on 
it) thus new staging will have that too.

-- 
Dmitry Olshansky