On 29/07/12 13:43, Robert Clipsham wrote:
> On Sunday, 29 July 2012 at 06:08:18 UTC, Andrei Alexandrescu wrote:
>> Due to the upcoming release, there will be no regular pull
>> walk-through tomorrow. Thanks for the growing rate of contribution,
>> and let's resume the ritual next Sunday.
>>
>> Andrei
>
> I really can't shake the feeling that you guys just don't get git!
>
> You never need to freeze pulls with git. Ever! It just slows down
> development.
>
> The work flow is simple enough:
>
> 1. Time for a release
> 2. Create a release branch, it is feature frozen
> 3. You can keep pulling feature into master, no problem
> 4. You can pull regression/bug fixes into the release branch
> 5. A release is made, merge the release branch into master and continue.
>
> I don't know why I bothered typing this out - the discussion has been
> had time and time again with no progress made.

From a technical point of view, I think the main thing to be done relates to the auto-tester.
We want the autotester to run on the release branch, as well as the development branch.

Note of course that we have druntime and Phobos as well as DMD; they all need their own release branches.
I guess the easiest way to do this would be to have a single, permanent branch called 'release', that is used for all releases, rather than creating a release branch for each compiler version.

On 2012-07-30 10:31, Don Clugston wrote:

> I guess the easiest way to do this would be to have a single, permanent
> branch called 'release', that is used for all releases, rather than
> creating a release branch for each compiler version.

Yes, exactly. The only reason for keeping the branches would be if we wanted to apply bug fixes and release a new version only based on that, i.e. 2.059-patch132 or something like that. But since we don't do that there's no reason. We also have tags for finding a release.

-- 
/Jacob Carlborg

Le 29/07/2012 21:16, Jacob Carlborg a écrit :
> On 2012-07-29 16:28, Andrei Alexandrescu wrote:
>
>> I'm all for it. We're just too busy most of the time to stop and improve
>> our process. I think it's a good opportunity to do so right after 2.060.
>
> It should have happened a long time ago.
>

Ranting about error of the past isn't helpful. What you say is true, but it is now immutable.

Let's switch to a better workflow after 2.060 . It make perfect sense.

On 7/30/12 11:08 PM, deadalnix wrote:
> Le 29/07/2012 21:16, Jacob Carlborg a écrit :
>> On 2012-07-29 16:28, Andrei Alexandrescu wrote:
>>
>>> I'm all for it. We're just too busy most of the time to stop and improve
>>> our process. I think it's a good opportunity to do so right after 2.060.
>>
>> It should have happened a long time ago.
>>
>
> Ranting about error of the past isn't helpful. What you say is true, but
> it is now immutable.
>
> Let's switch to a better workflow after 2.060 . It make perfect sense.

Walter and I will dedicate time after 2.060 to improving the process.

Andrei

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.

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, 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!
-- 
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

On 2012-07-31 08:24, 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.
>
> 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, 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!
>

I completely agree.

-- 
/Jacob Carlborg

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!
>

On Tuesday, July 31, 2012 01:10:35 Walter Bright wrote:
> 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.

The complaint is that we're using git as if it were subversion. We never branch, whereas you usually branch quite heavily when using git. If we were using git like it's normally used, we'd be branching for betas (as well as splitting the new feature development branch from the bugfix branch). Instead, we have a single branch that we do everything on, forcing us to stop merging any pull requests when we do a beta. The typical way to do this with git involves using multiple branches, not doing everything on trunk/master.

The simplest way to do this would probably be to branch for a release whenever we do a beta. We then continue to merge stuff into master as normal. But when there's a fix that we need for the beta, we cherry pick it from master and put it in the release branch. And when the release is finally ready to go, we tag the appropriate commit on the release branch, and that's the release. That way, doing a beta does not halt normal development at all. Rather, it's done in parallel.

If we take this further as most large open source projects do and had a 2.x.y versioning model, then the work for x would be on master, and we'd cherry pick bug fixes to the y branch as we went along. Then at intervals, we'd branch y to create a release branch and do the beta and subsequent release from that. So, we'd be doing bug fix releases based on the y branch at regular intervals (probably monthly) which didn't include any new features at all. In theory, this promotes greater stability. So, we'd get 2.60.0, 2.60.1, 2.60.2, etc.

Then at some larger interval (generally 6 - 12 months, depending on the project; we'd probably want to do 6 months at this point), we'd branch x to create a new y branch and start using that as the bugfix branch. So, the first release from that would include all of the new features that had been being worked on over the previous 6 months. So, if we'd been releasing 2.60.y we'd get a 2.61.0 release at that point, and the subsequent releases would be 2.61.1, 2.61.2, etc.

That model is essentially what was being argued for in the newsgroup recently which ended up with dlang-stable being created.

There are a variety of articles online describing branching/release models along those lines, but that's typically what happens with git on the most basic level. You branch heavily (and actually, as described here, the number of branches is quite light for git). A more complicated scheme which was recently brought up in the newsgroup is described here:

http://nvie.com/posts/a-successful-git-branching-model/

But I very much doubt that we want to do anything quite that complicated.

Regardless, the fact that we don't even branch for a beta is a definite indicator that we're using git as if it were subversion. If we were _really_ using git as intended, then not only would we be branching for betas and for the releases, but we'd be creating temporary branches for new features as they're ironed out (merging them into master only when they're completed).

- Jonathan M Davis

On 2012-07-31 10:10, Walter Bright wrote:

> We're already using Git.

You completely missed the point. The point was not which VCS we use, it was how we're using it.

-- 
/Jacob Carlborg

Jacob Carlborg:

> You completely missed the point. The point was not which VCS we use, it was how we're using it.

Yeah, Walter has missed the point, but you aren't helping much. Why don't you give links that explain what a Git workflow is, in general? Or you explain the situation yourself.

This is not entry-level, so something simpler is probably needed:
http://github.com/downloads/nvie/gitflow/Git-branching-model.pdf

Bye,
bearophile