August 01, 2012
On Tue, 2012-07-31 at 19:46 +0200, Tobias Pankrath wrote: […]
> Does that mean that you do
> 
> git checkout featurebranch
> git rebase master
> git merge featurebranch // fast forward?

Rule 0: Never use rebase on a published repository.
Rule 1: Never use rebase on a published repository.
Rule 2: Never use rebase on a published repository.
…

but yes many people do use rebase on a private repository to create changesets for submission to review. There are many who think this is anathema as it changes history, but unless the repository has been published no-one can actually observe that.

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder


August 01, 2012
On Wed, 01 Aug 2012 08:24:57 +0200
Jacob Carlborg <doob@me.com> wrote:

> On 2012-08-01 00:55, Nick Sabalausky wrote:
> 
> > +1 ALL
> >
> > Along those lines, I really think dmd-beta should me moved to the newsgroups. Granted, I am biased since I hate mailing lists. But moving it to NG means:
> >
> > - Consistency with the rest of the D traffic.
> > - Easier to find/discover/subscribe.
> > - Easier to follow the branches of discussion: Not everyone's email
> >    client does threading, but it's standard on NG readers.
> > - We get forum.dlang.org integration and the associated visibility
> > and google/bing-ability basically for free.
> 
> I completely agree. I think Walter once said it was a mailing list to keep it more hidden.
> 

Maybe that was a good move at the time, but at this point, I think we need to encourage more people to participate in the betas. And that means more visibility.

August 01, 2012
> Along those lines, I really think dmd-beta should me moved to the
> newsgroups.

the newsgroup is already available via gmane.comp.lang.d.dmd.beta

August 01, 2012
On 2012-08-01 10:42, Mirko Pilger wrote:

> the newsgroup is already available via gmane.comp.lang.d.dmd.beta

It's read only.

-- 
/Jacob Carlborg
August 01, 2012
On Tue, 31 Jul 2012 16:54:17 +0100, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:

> On 7/31/12 11:46 AM, deadalnix wrote:
>> We actually have to « reverse » the way thing are done. You can't go to
>> the other side of a gap in 2 steps. We face a change that cannot be
>> gradually adopted.
>
> Then I need more education. I thought a good thing to do is use branching for releases, and that we can start doing that without much difficulty. No?

If not, then someone or several someones need to produce a good document to describe the process they're suggesting.  It seems that some people here agree on a process, but others have slightly differing ideas.  The issue is deciding on the best model for D, and making it clear to everyone.

So, definition is step 1, education is step 2 and implementation is steps 3+.

I think a wiki page which is editable by those with concerns might be a good idea, or even a DIP.  It should describe the ideal workflow and give concrete examples of common processes i.e. releases, dealing with merges/rebases etc for bug fixes etc.

I've never used GIT, nor do I contribute to D at present or I might have had a crack at this, someone else would definitely be better suited.

R

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/
August 01, 2012
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
August 01, 2012
On Sunday, 29 July 2012 at 12:00:16 UTC, David Nadlinger wrote:
> On Sunday, 29 July 2012 at 11:43:41 UTC, Robert Clipsham wrote:
>> 4. You can pull regression/bug fixes into the release branch
>
> Just to clarify: »Pulling« in this context means cherry-picking individual bug fixes critical for the release from the main branch. Virtually all changes and pull requests still go on the main branch first, and are then »backported« onto the release branch.
>
> And by the way, you don't even need a DVCS for that. Many SVN-based open source projects use a »branch-before-release« workflow as well.
>
> David

That couldn't possibly be clarification. Otherwise step 5 wouldn't be needed.

I don't know much about using cherry picking, but it doesn't really seem like what we'd want.

Walter would need to pull into master then cherry pick it into release. Those trying to resolve a regression will be thrown into any changes being made against master, which could be a refactoring of const...

It seems to me cherry picking works better for a living branch. Release will be short lived. If we went with a stable branch... then I could see the cherry picking come into play.
August 01, 2012
On Wednesday, 1 August 2012 at 11:56:48 UTC, Andrei Alexandrescu wrote:
> 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.

Disregard what I said about cherry-picking – while it would work, I was thinking too much in terms of SVN here. With Git, the better choice usually is to make all the commits which should end up in the release directly on the release branch, and merge that branch periodically back to master. If all the commits from the release branch should also make it into master, which is usually the case, you don't end up with two logically separate commits in the same repository this way.

David
August 01, 2012
On 8/1/2012 12:30 AM, Russel Winder wrote:
> On Tue, 2012-07-31 at 01:10 -0700, Walter Bright wrote: […]
>>
>> We're already using Git.
> 
> I will be "robust".
> 
> You may be making use of Git commands but you are still using Subversion, you are not using Git.

You keep blaming it on using subversion or subversion mentality.  It has nothing to do with subversion in the slightest.
 It has everything to do with the evolution of the development process.  We were only using SVN for a short period of
time and the use of it was a direct evolution from the not using any scm at all, no branching, etc, development process
that existed prior to that point.

Please, ignore that svn exists, it's irrelevant to D at this point.

August 01, 2012
On Wednesday, 1 August 2012 at 17:04:06 UTC, David Nadlinger wrote:
> On Wednesday, 1 August 2012 at 11:56:48 UTC, Andrei Alexandrescu wrote:
>> 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.
>
> Disregard what I said about cherry-picking – while it would work, I was thinking too much in terms of SVN here. With Git, the better choice usually is to make all the commits which should end up in the release directly on the release branch, and merge that branch periodically back to master. If all the commits from the release branch should also make it into master, which is usually the case, you don't end up with two logically separate commits in the same repository this way.
>
> David

Yeah, this is exactly how it should be done. cherry-picking should only be needed in very special cases, not as part of a regular workflow.

Basically like this:

1. Walter posts the usual "Time for a beta" message and does `checkout -b release-2.061 master` and `git push origin release-2.061` to put it on GitHub.

2. During the beta period as people find regressions and bugs that must be fixed before release they make pull requests targeting release-2.061 instead of master. People doing regular, non-release-blocking changes just target master as usual.

3. Once the final release is made and out the door a tag is made, release-2.061 is merged into develop and deleted: git checkout master; git merge release-2.061; git branch -d release-2.061; git push origin :release-2.061 (this is all safe to do, git prevents you from deleting branches with unmerged changes by default).

If master does need bugfixes from the release branch (I think this would be rare) you can merge the release branch or cherry-pick. Either works fine. This solves the freeze problem (to be honest, I don't think the freezing problem is really that huge of deal).

I still think a more important change is using feature/issue branches instead of committing partial work to master. master should always be in a position where it's ready for a release, even if some project someone is working on isn't ready yet (and this is mostly the case now due to the nature of GitHub).