Next focus: PROCESS

[Jesse Phillips]

On Monday, 10 December 2012 at 23:41:25 UTC, Andrei Alexandrescu 
wrote:
> In turn, I'll be collecting thoughts and opinions in this 
> thread, distilled from previous discussions. We should develop 
> a few simple git scripts (such as git-start-new-feature or 
> git-start-bugfix etc) supported by an equally simple piece of 
> documentation describing how to start a new release, fix a bug, 
> experiment with a new feature, and such.

There may be some helpful scripts to facilitate a new workflow, 
but the examples given I feel just translate to learning a D 
specific git commands. Seriously you'll end up with a layer of 
abstraction that will make it harder for those familiar with git 
to understand and limit the ability of newer users to understand 
the state their working copy is in.

git-start-new-feature:
$ git checkout devbranch
$ git checkout -b newfeaturename

git-start-bugfix:
$ git checkout stablebranch
$ git checkout -b fixbugxxx

How these should be folded back is the harder part. For example 
the bug fix should then be into stablebranch and devbranch.

There is also the matter of pulling in changes of your stable or 
dev branch as you work, this is done with the add --rebase switch 
(and I believe opens the doors for more merge conflicts than a 
standard merge).

> (One piece that has been brought forward is 
> http://nvie.com/posts/a-successful-git-branching-model/ - 
> something to keep in mind.)

I would like to note that these simple flows do not mimic our 
world. We have three projects that need to be marked for release 
in tandem. It doesn't need address now, but it should be noted.

I think it would be cool if the idea behind workbench project 
someone started was used officially to sync dmd/phobos/dlang.org 
and provide any of these needed deployment scripts. It would add 
to the complexity but much of it is already there this would just 
make it more apparent.