On 7/30/2012 11:24 PM, Russel Winder wrote:
On Mon, 2012-07-30 at 23:40 -0400, Andrei Alexandrescu wrote:
[…]
Walter and I will dedicate time after 2.060 to improving the process.
"Improve" implies tinkering at the edges. This situation requires a
"change" or perhaps "revolution". I suggest just switching to a
ready-made DVCS / Git process that is known to work, and is well
documented, rather than trying to craft a new one based on CVCS /
Subversion / CVS history.
We're already using Git.
To be honest there is never a reason to freeze a repository, even with
Subversion, and definitely not with Git, Mercurial and Bazaar. With
these latter DVCSs, branching and cherry-picking, means that you just
branch from master to create the branch for the release. Whether this
becomes a full-blown maintenance branch or just a temporary release
branch that merges back post release is a fundamental question of
process on which there are opinions. Go has a "there will only ever be
the default branch" model,
Which is what we currently have with dmd on Git.
Groovy has gone with a "there will be
maintenance branches for each minor release" model. There are others.
I think the trick here is to plump for one, go with it. and then
"improve" in the light of actual experience. I also suggest the time for
debate is over, that it is now time for action. I suggest privately
polling the people who actually commit stuff to the D compiler codebase
and to Phobos, to see if there is a suitable process that those folk can
work with immediately. If not go with one of the publicized Git
processes that is documented to your satisfaction. People like me who
just waffle and don't deliver code amendments should not have a vote at
this time having chipped in to this point in time. People like me should
just adjust to the process put in place – which should be easy of a
truly DVCS process is put in place.
If there isn't a new process in place immediately 2.060 is released and
master tagged, this I think this would have to be considered a "red
flag". The corollary is, I guess, to delay releasing 2.060 till you have
a new process as well as the release being ready to ship.
Of course none of this stops people preparing evolutions of the mainline
now even during a mainline repository freeze, this is DVCS / Git and so
Subversion trunk rules just do not apply!
