Next focus: PROCESS

[H. S. Teoh]

On Mon, Dec 10, 2012 at 06:41:25PM -0500, Andrei Alexandrescu wrote:
> Hello all,
> 
> Walter and I have had a long discussion following his trip to
> Australia. Following the current sprint for Win64 (which we all, I
> think, agree was long overdue and had to be done), the main area we
> need to work on (as I'm sure many would agree) is improving our
> process, in particular the approach to releasing the compiler and
> standard library.

*applause* It's about time we did this right.


> Walter has delegated me to lead this effort, and agreed to obey with
> whatever process comes forward as long as it's reasonably clear and
> simple.

Good to know.


> 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.

Sounds OK to me, though it seems unnecessarily complicated. What's wrong
with just doing things like:

	# New feature
	git checkout develop	# latest dev branch
	git branch -b brand_new_feature
	# implement said feature
	git commit -a

	# Merge feature into dev branch
	git checkout develop
	git merge brand_new_feature

	# New release candidate
	git checkout develop
	git branch -b 2.062-rc1
	# prepare code for release
	git commit -a

	# Release
	git checkout master
	git merge 2.062-rc1

Seems to me these are all straightforward everyday git commands. The
whole selling point of git is that branching/merging is so easy that you
could do it multiple times a day within a single implementation effort.
For example, I frequently find myself doing things like this:

	# I want to implement feature X today
	git checkout master

	# Implementation attempt #1
	git checkout -b feature_X_1
	vim feature.d  # code code code

	# While coding feature.d, I got inspired by an idea of an
	# alternative implementation. So, put current code aside and
	# test idea on new branch.
	git commit -a
	git checkout -b feature_X_alt_impl
	vim feature.d  # implement alternative approach

	# Turns out, alternate approach doesn't work. Go back to
	# original approach. (But leave alt_impl in case I decide later
	# to go back to it.)
	git checkout feature_X_1
	vim feature.d  # more code

	# I hit a difficult spot in the code. Put it aside and work on
	# other stuff first.
	git commit -a
	git checkout master
	vim main.d  # do some routine maintenance, bugfixes, etc.
	git commit -a

	# Take afternoon nap. While resting I got another idea for
	# feature X.
	git checkout feature_X_1
	vim feature.d  # try out new idea

	# Turns out, it needs a big change. So don't commit to
	# feature_X_1, but use a separate branch.
	git checkout -b feature_X_new_idea
	vim feature.d  # more code
	git commit -a

	# I decide that feature_X_new_idea is the way to go. So fold
	# into feature X branch.
	git checkout -b feature_X_1
	git merge feature_X_new_idea

	# I don't need the new idea branch anymore now that it's been
	# adopted as the "official" way to implement X. Also, the
	# previous alternative approach was a dead-end, so junk that as
	# well.
	git branch -d feature_X_new_idea
	git branch -d feature_X_alt_impl

	# Continue working on X
	vim feature.d
	git commit -a

	# I decide that it's now stable enough to merge into the
	# mainline code.
	git checkout master
	git merge feature_X_1

This can happen several times a day when I'm doing a lot of coding.


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

Glanced at it briefly. I think the basic ideas behind it are sound.
Whether or not we should adopt all of the specifics is up for
discussion, but I think we should definitely incorporate the main ideas:
(1) have a release-ready branch, (2) a separate dev branch, and (3)
always use a separate branch for new features so that if things go wrong
or it takes too long to finish implementation, development work on other
stuff can continue without being held up by bugs in the new feature.

Furthermore, in a git environment it's perfectly normal to have multiple
"exploratory" or "sub-feature" branches within a single feature branch,
like I illustrated above in exploring how to implement feature X. These
are usually just local branches, but if the feature is complex enough,
it can warrant pushing to github so that other devs can also play around
with the alternative implementation approaches. Eventually the best
approach can be merged back to the feature branch and the others
discarded.

Personally, I find that this approach is very profitable, because you
don't have to worry that a particular breaking change may turn out to be
a dead-end; do the experiment in a sub-branch and throw it away if it
doesn't work. The cheapness of doing this allows one to explore
ambitious or risky approaches without affecting the stable "traditional"
implementation, and so opens up the possibility of discovering new and
novel ways of doing things that are usually left unexplored.


T

-- 
It said to install Windows 2000 or better, so I installed Linux instead.