View mode: basic / threaded / horizontal-split · Log in · Help
July 30, 2012
Re: Pull freeze
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.
July 30, 2012
Re: Pull freeze
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
July 31, 2012
Re: Pull freeze
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.
July 31, 2012
Re: Pull freeze
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
July 31, 2012
Re: Pull freeze
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
July 31, 2012
Re: Pull freeze
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
July 31, 2012
Re: Pull freeze
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!
>
July 31, 2012
Re: Pull freeze
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
July 31, 2012
Re: Pull freeze
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
July 31, 2012
Re: Pull freeze
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
1 2 3 4 5 6
Top | Discussion index | About this forum | D home