Pull freeze

[Andrei Alexandrescu]

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