On 8/1/12 3:44 AM, Russel Winder wrote:
On Tue, 2012-07-31 at 11:38 -0400, Andrei Alexandrescu wrote:
[…]
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?
As has been noted many time now I'm afraid, Git is currently being used
as though it were Subversion. Subversion mind set is being applied when
using Git commands. In changing from Subversion to Git all mindsets as
well as processes need to be changed. The revolution started with the
actual repository move, but sadly it was not carried through by amending
the processes.
We will amend the processes to branch for each release.
[…]
Agreed. But that means we'd need to use branching and tagging better,
not to "revolutionize" things.
Well actually there is an element of using branching and tagging at all.
Branching and tagging in Subversion is cheap in the database and very
expensive for clients. Worse merging still remains a problem for
Subversion hence branching is a tool of last resort. Branching, tagging
and merging are cheap for Git, but there needs to be a move from CVCS
thinking to DVCS thinking on the part of those people with write
permission to the mainline.
Well this doesn't do a lot in the way of substantiating. I do want to be
illuminated. I want to get DVCS! And my understanding is that we need to
branch whenever we plan a new release, and cherry-pick bugfixes from the
mainline, and such. Or (when we have multiple contributors) use one
branch per feature. When I ask you, you neither confirm nor deny that,
but instead go for the vague "well you need to change your mindset". I
hope you see how this is less than useful.
[…]
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.
This paragraph appears (apologies if I have it wrong) to highlight part
of the problem. The way you speak of committers and contributors
indicates Subversion hangover. DVCS is about having reviewers of
changesets, and gatekeepers who make the merges into the mainline. The D
process has much of this already but at the core the approach to the
mainline is CVCS not DVCS mindset.
DVCS is a lot about "D" - many people working on the project. We don't
have all that many, and it might help if I explained to you what I meant
by "pull freeze this Sunday". It appears to me that you made your
comments in neglect of the dynamics of this project.
There are only a few contributors and gatekeepers to Druntime, Phobos,
tools, and dlang.org - the repos I manage. Pardon me if I use the wrong
vocabulary, since "contributors" seems to be the wrong thing and coming
from the wrong mindset. Let's say "people who make pull requests". I'd
used them all with the mini-ceremony of making a thorough pass through
each and every pull request each Sunday afternoon.
This has had beneficial effects. People know that their pull requests
will be looked at and either commented on or merged. There is a sense of
progress and of thoroughness. At the end of the day, even if we used the
mother of all processes, I'd still need to put the same amount of time
into actually looking at the code. This (which is the bulk of the time
I'm spending on these projects) cannot be optimized through process.
Clearly if we'd used branching for release I could have done the merging
last Sunday too. Since we don't have that yet (we should), last Sunday I
left I got a babysitter, had a nice dinner with my wife, and watched
some 80% of "The Watch". My perception is that there was no major
disruption for contributors aside from missing feedback from me (which,
again, is a reviewer time issue rather than a process issue). Otherwise
they could have continued work on their branches, or create new ones.
This was the meaning of "pull freeze". I meant to tell I won't be
looking at stuff this Sunday.
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.
If the road to 2.061 starts without the new process mostly in place, the
danger is there will a mainline freeze to put out 2.061.
The new process is to branch when we decide to release 2.061. Please let
me know whether this is true or false.
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.
Sorry but if you haven't got the points already, then my points are more
than valid.
Well the alternative route might have been to reckon the conveyance of
said point could have been improved.
Anyway, it is clear you are asking me to shut up on this topic so this
will be my last post on it.
Sorry Russel but this is just being smug. This conversation goes like this:
RW: "You need to change everything! Everything!"
AA: "Well so I understand from other people, step 1 is to branch for
each release. Great."
RW: "Yes and no! There is step 1 and no step 1! It's a revolution!"
AA: "OK so what do I need to do?"
RW: "You're hopelessly anchored in the wrong mindset! You don't
understand! It's the second coming man!"
AA: "Well this does little in the way of illuminating me."
RW: "You're dumb and a bully. I'm not talking anymore."
If you want to help, I'd be in your debt if you were just a tiny bit
more concrete than telling me how hopeless I am.
Thanks,
Andrei
