On 7/31/12 2:24 AM, 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.
You can't suggest a revolution - only carry it through. But I'm a bit
confused. We already use git, and the idea is to use it better. What's
the thing with subversion etc? Where's the revolution?
To be honest there is never a reason to freeze a repository, even with
Subversion, and definitely not with Git, Mercurial and Bazaar.
Agreed. But that means we'd need to use branching and tagging better,
not to "revolutionize" things.
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, 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.
But that's what we did! And now we want to improve it.
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.
To be honest I think we've reaped a lot of low-hanging fruit so far.
Improving the process will bring some marginal efficiency improvements,
but adding more good committers and contributors would be much more
impactful. As far as I can tell there's not (there used to be) a hoard
of disgruntled contributors unable to push things forward.
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.
Why do you think that would be a good decision? There's a lot of value
added right now and a lot of pent-up demand for the many bug fixes and
improvements.
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!
Sure. I agree that should (and can easily) change. But I fail to get the
overarching theme of your post - I just see agitation, agitation,
agitation, but no coherence.
Andrei
