www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - Pull freeze

reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Jul 28 2012
next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2012-07-29 08:08, 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


Again, we _need_ to start using branches.

-- 
/Jacob Carlborg
Jul 29 2012
next sibling parent =?ISO-8859-1?Q?Alex_R=F8nne_Petersen?= <alex lycus.org> writes:
On 29-07-2012 13:11, Jacob Carlborg wrote:

 On 2012-07-29 08:08, 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


 Again, we _need_ to start using branches.


Amen.

There is no reason master should be frozen due to a release being made.

The way we do releases is completely backwards: We freeze master, do the 
release, and *then* make a tag in Git. It should be the other way 
around, but replace tag with branch.

The current release model may have seemed like a good idea during SVN 
times, but we're using Git now.

-- 
Alex Rønne Petersen
alex lycus.org
http://lycus.org
Jul 29 2012
prev sibling next sibling parent Dmitry Olshansky <dmitry.olsh gmail.com> writes:
On 29-Jul-12 15:11, Jacob Carlborg wrote:

 On 2012-07-29 08:08, 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


 Again, we _need_ to start using branches.


+1

-- 
Dmitry Olshansky
Jul 29 2012
prev sibling next sibling parent Russel Winder <russel winder.org.uk> writes:
On Sun, 2012-07-29 at 13:11 +0200, Jacob Carlborg wrote:

 On 2012-07-29 08:08, 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


=20
 Again, we _need_ to start using branches.


Although not personally involved, I do get the feeling that CVCS
workflow is being used with a DVCS system. Possible since CVCS < DVCS.

Keeping feature branches off the mainline is also a good move =E2=80=93 hav=
ing
feature branches on the mainline is a return to CVCS thinking.  Having
the mainline as a pristine representation of the official state of the
project (possibly with maintenance branches) is the best idea,
everything else can be done by people sharing and creating pull requests
when done.

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
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
Jul 29 2012
prev sibling parent Marco Leise <Marco.Leise gmx.de> writes:
Am Sun, 29 Jul 2012 13:11:08 +0200
schrieb Jacob Carlborg <doob me.com>:


 On 2012-07-29 08:08, 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


 
 Again, we _need_ to start using branches.


Ego cogito, ceterum censeo Carthaginem delendam esse!

-- 
Marco
Jul 29 2012
prev sibling parent reply "Robert Clipsham" <robert octarineparrot.com> writes:
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.
Jul 29 2012
next sibling parent reply "David Nadlinger" <see klickverbot.at> writes:
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
Jul 29 2012
parent "Jesse Phillips" <Jessekphillips+D gmail.com> writes:
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.
Aug 01 2012
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 7/29/12 7:43 AM, 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.


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.


Thanks,

Andrei
Jul 29 2012
parent reply Jacob Carlborg <doob me.com> writes:
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.

-- 
/Jacob Carlborg
Jul 29 2012
parent reply deadalnix <deadalnix gmail.com> writes:
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.
Jul 30 2012
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Jul 30 2012
parent reply Russel Winder <russel winder.org.uk> writes:
On Mon, 2012-07-30 at 23:40 -0400, Andrei Alexandrescu wrote:
[=E2=80=A6]

 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 =E2=80=93 which should be easy of a
truly DVCS process is put in place.=20

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! =20
--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
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
Jul 30 2012
next sibling parent Jacob Carlborg <doob me.com> writes:
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
Jul 31 2012
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
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!
Jul 31 2012
next sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
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:
 [=E2=80=A6]
=20

 Walter and I will dedicate time after 2.060 to improving the proce=






ss.

=20
 "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.


=20
 We're already using Git.


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


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

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

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

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

There are a variety of articles online describing branching/release mod=
els=20
along those lines, but that's typically what happens with git on the mo=
st=20
basic level. You branch heavily (and actually, as described here, the n=
umber=20
of branches is quite light for git). A more complicated scheme which wa=
s=20
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 complicate=
d.

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

- Jonathan M Davis
Jul 31 2012
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 7/31/12 4:57 AM, Jonathan M Davis wrote:

 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.


Yah, I think that's a good way to go. We should start that practice now 
and refine it (e.g. with x.y.z releases) later.

Andrei
Jul 31 2012
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
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
Jul 31 2012
parent reply "bearophile" <bearophileHUGS lycos.com> writes:
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
Jul 31 2012
parent Jacob Carlborg <doob me.com> writes:
On 2012-07-31 13:03, bearophile wrote:


 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


Russel just explained everything. Then Johnathan also explained 
everything a second time. Many other people of explained the same thing 
many times before as well.

-- 
/Jacob Carlborg
Jul 31 2012
prev sibling next sibling parent reply "David Nadlinger" <see klickverbot.at> writes:
On Tuesday, 31 July 2012 at 08:11:05 UTC, Walter Bright wrote:

 We're already using Git.


Sorry, but this is completely irrelevant for the discussion. As 
far as handling the »main repository« is concerned, Git and SVN 
are not that different – you can do branches in both, even if 
they are more comfortable to use in Git.


 Go has a "there will only ever be
 the default branch" model,


 Which is what we currently have with dmd on Git.


No. The Go guys also use a separate Mercurial branch for 
preparing releases, while development continues on the main 
branch.

David
Jul 31 2012
parent Russel Winder <russel winder.org.uk> writes:
On Tue, 2012-07-31 at 21:45 +0200, David Nadlinger wrote:
[=E2=80=A6]

 No. The Go guys also use a separate Mercurial branch for=20
 preparing releases, while development continues on the main=20
 branch.


Just to note that Mercurial and Git differ crucially in how to work with
branches. The Go process is a Mercurial one that does not transfer well
to Git.

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
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
Aug 01 2012
prev sibling next sibling parent Russel Winder <russel winder.org.uk> writes:
On Tue, 2012-07-31 at 01:10 -0700, Walter Bright wrote:
[=E2=80=A6]

=20
 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.


 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,


=20
 Which is what we currently have with dmd on Git.


I don't see how you can be doing a freeze-free process if you declare a
freeze. There are fundamental and crucial differences between master
HEAD in Git and trunk in Subversion. This whole thread is about not
using Subversion trunk thinking when using Git master HEAD.

To say more would be to repeat what has already been repeated.

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
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
Aug 01 2012
prev sibling parent Brad Roberts <braddr puremagic.com> writes:
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.
Aug 01 2012
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Jul 31 2012
next sibling parent reply deadalnix <deadalnix gmail.com> writes:
Le 31/07/2012 17:38, Andrei Alexandrescu a écrit :

 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?


That would result in a fork. Is that really what we want/need ?


 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.


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.
Jul 31 2012
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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?

Andrei
Jul 31 2012
next sibling parent reply deadalnix <deadalnix gmail.com> writes:
Le 31/07/2012 17:54, Andrei Alexandrescu a écrit :

 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?

 Andrei


I have tested this workflow on a big project at work. This is working, 
and much better than what we have now, but still have some limitation.

As the dev in made in master, it is sometime broken, which is a problem 
for all developers. Additionally, it become hard to apply fixes in all 
release branches.

We have found the following more successful :
  - Developing in branches. 1 branch per functionality.
  - Dev branches are often rebased on master.
  - When a feature is ready, it is integrated into master.

  - Each version have its branch (ie 2.61 is a version).
  - A version branch is often rebased on the previous version branch (ie 
2.60).
  - master is often rebased on the latest version branch.
  - A version branch is tagged to create a new release, a revision is 
added to the tag name (ie 2.61.4).

  - When a bug exists in a version branch, it is fixed in the oldest 
version where the problem appears (and that is still supported). Bugfix 
include a testcase if appropriate.

  - When several new feature want to be tested together, they are all 
merged into a branch. This is handy for testing purpose. This is usually 
done before including features in master to make sure everything is fine.

It have advantages :
  - The master is almost always in good shape. It helps all developers 
because they work on a reliable base.
  - Bug fixes bubble up from the old version to the newer one and to dev 
branches. It is easy to automate such bubbling to master with scripting.
  - It is easy to produce custom versions for testing purpose.
  - It is easy to keep several version of the product maintained, which 
a massive plus when backward compatibility is important.

Still, I'm all for what you propose, this is an improvement over what we 
have now. But the shift from « we dev in master » and « we merge dev in 
master, which is a realiable branch » can't be done in 2 steps.
Jul 31 2012
parent reply "Tobias Pankrath" <tobias pankrath.net> writes:
I'm not that fluent in git. Could you explain your approach 
further?

On Tuesday, 31 July 2012 at 16:43:19 UTC, deadalnix wrote:>

 We have found the following more successful :
  - Developing in branches. 1 branch per functionality.
  - Dev branches are often rebased on master.


Does that mean that you do

git checkout featurebranch
git rebase master
git merge featurebranch // fast forward?
Jul 31 2012
next sibling parent deadalnix <deadalnix gmail.com> writes:
Le 31/07/2012 19:46, Tobias Pankrath a écrit :

 I'm not that fluent in git. Could you explain your approach further?

 On Tuesday, 31 July 2012 at 16:43:19 UTC, deadalnix wrote:>

 We have found the following more successful :
 - Developing in branches. 1 branch per functionality.
 - Dev branches are often rebased on master.


 Does that mean that you do

 git checkout featurebranch
 git rebase master
 git merge featurebranch // fast forward?


You usually don't need to merge.

You also don't need to rebase master all the time, just on a regularly 
basis to not be left behind.
Jul 31 2012
prev sibling parent Russel Winder <russel winder.org.uk> writes:
On Tue, 2012-07-31 at 19:46 +0200, Tobias Pankrath wrote:
[=E2=80=A6]

 Does that mean that you do
=20
 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.
=E2=80=A6

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.=20

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
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
Aug 01 2012
prev sibling next sibling parent reply "David Nadlinger" <see klickverbot.at> writes:
On Tuesday, 31 July 2012 at 15:54:18 UTC, Andrei Alexandrescu 
wrote:

 I thought a good thing to do is use branching for releases, and 
 that we can start doing that without much difficulty. No?


I think doing that would be a good idea. Some people might prefer 
fancier branching schemes, given that handling them is much more 
painless with Git than with SVN, but this doesn't prevent us from 
implementing release branches as a first step.

What's also important from a »million users« point of view is 
that the origins of every release artifact is traceable, both 
internally and for users, both in terms of source code and 
tools/commands to prepare the archives. This also applies to beta 
releases: Please, PLEASE let's start to properly name them 
(dmd-2.060-beta1.zip) along with tagging the respective revisions 
in Git and keeping the old versions around, instead of just 
overwriting a single archive with unknown (and routinely broken) 
contents. Otherwise things are bound to become chaotic once more 
than us 15-ish people actually test the betas.

Which reminds me: We really need to announce the beta releases 
more publicly, i.e. in the forums, on the website, on Twitter, 
IRC, etc. Once a release is out, we can't take it back, but I'm 
sure there are many enthusiastic D users who wouldn't mind 
running their projects/test suites against the compiler once 
before the official release if they were only asked to. It's easy 
to forget if you are subscribed to all the mailing lists, but the 
visibility of an upcoming release is almost zero until it is out 
of the door. Yes, we have [dmd-beta], but it takes extra effort 
to subscribe to it – more people are subscribed to 
digitalmars.D.announce via the mail gateway then to the 
low-volume beta list!

David
Jul 31 2012
parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Tue, 31 Jul 2012 22:46:52 +0200
"David Nadlinger" <see klickverbot.at> wrote:


 On Tuesday, 31 July 2012 at 15:54:18 UTC, Andrei Alexandrescu=20
 wrote:

 I thought a good thing to do is use branching for releases, and=20
 that we can start doing that without much difficulty. No?


=20
 I think doing that would be a good idea. Some people might prefer=20
 fancier branching schemes, given that handling them is much more=20
 painless with Git than with SVN, but this doesn't prevent us from=20
 implementing release branches as a first step.
=20
 What's also important from a =C2=BBmillion users=C2=AB point of view is=20
 that the origins of every release artifact is traceable, both=20
 internally and for users, both in terms of source code and=20
 tools/commands to prepare the archives. This also applies to beta=20
 releases: Please, PLEASE let's start to properly name them=20
 (dmd-2.060-beta1.zip) along with tagging the respective revisions=20
 in Git and keeping the old versions around, instead of just=20
 overwriting a single archive with unknown (and routinely broken)=20
 contents. Otherwise things are bound to become chaotic once more=20
 than us 15-ish people actually test the betas.
=20
 Which reminds me: We really need to announce the beta releases=20
 more publicly, i.e. in the forums, on the website, on Twitter,=20
 IRC, etc. Once a release is out, we can't take it back, but I'm=20
 sure there are many enthusiastic D users who wouldn't mind=20
 running their projects/test suites against the compiler once=20
 before the official release if they were only asked to. It's easy=20
 to forget if you are subscribed to all the mailing lists, but the=20
 visibility of an upcoming release is almost zero until it is out=20
 of the door. Yes, we have [dmd-beta], but it takes extra effort=20
 to subscribe to it =E2=80=93 more people are subscribed to=20
 digitalmars.D.announce via the mail gateway then to the=20
 low-volume beta list!
=20


+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.
Jul 31 2012
next sibling parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Tuesday, July 31, 2012 18:55:33 Nick Sabalausky wrote:

 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 didn't realize that beta was any different from the rest (I always use the 
mailing list). It _is_ part of forum.dlang.org already though.

- Jonathan M Davis
Jul 31 2012
next sibling parent =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <alex lycus.org> writes:
On 01-08-2012 01:05, Jonathan M Davis wrote:

 On Tuesday, July 31, 2012 18:55:33 Nick Sabalausky wrote:

 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 didn't realize that beta was any different from the rest (I always use the
 mailing list). It _is_ part of forum.dlang.org already though.

 - Jonathan M Davis


Yeah, but in e.g. Thunderbird you get a nifty overview of lists on the 
NG in a side bar which makes for super easy navigation.

-- 
Alex Rønne Petersen
alex lycus.org
http://lycus.org
Jul 31 2012
prev sibling parent reply "Kapps" <opantm2+spam gmail.com> writes:
On Tuesday, 31 July 2012 at 23:06:00 UTC, Jonathan M Davis wrote:

 On Tuesday, July 31, 2012 18:55:33 Nick Sabalausky wrote:

 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 didn't realize that beta was any different from the rest (I 
 always use the
 mailing list). It _is_ part of forum.dlang.org already though.

 - Jonathan M Davis


But you can't make replies, just like to the 
phobos/druntime/internals lists. I'd say that likely prevents 
people from giving feedback about the beta; it has a high barrier 
to entry.
Jul 31 2012
parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Wednesday, August 01, 2012 03:00:51 Kapps wrote:

 But you can't make replies, just like to the
 phobos/druntime/internals lists.


Really? That should definitely be fixed then.

- Jonathan M Davis
Jul 31 2012
parent Jacob Carlborg <doob me.com> writes:
On 2012-08-01 04:39, Jonathan M Davis wrote:


 Really? That should definitely be fixed then.


Yeah, you can't post via the newsgroup interface either (news.gmane.org).

-- 
/Jacob Carlborg
Jul 31 2012
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
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.

-- 
/Jacob Carlborg
Jul 31 2012
parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
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.
Aug 01 2012
prev sibling parent reply Mirko Pilger <pilger cymotec.de> writes:
 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
Aug 01 2012
parent Jacob Carlborg <doob me.com> writes:
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
Aug 01 2012
prev sibling parent "Regan Heath" <regan netmail.co.nz> writes:
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 =AB reverse =BB 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 everyo=
ne.

So, definition is step 1, education is step 2 and implementation is step=
s  =

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 giv=
e  =

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/
Aug 01 2012
prev sibling parent reply Russel Winder <russel winder.org.uk> writes:
On Tue, 2012-07-31 at 11:38 -0400, Andrei Alexandrescu wrote:
[=E2=80=A6]

 You can't suggest a revolution - only carry it through. But I'm a bit=20
 confused. We already use git, and the idea is to use it better. What's=


=20

 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.

[=E2=80=A6]

 Agreed. But that means we'd need to use branching and tagging better,=20
 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.

[=E2=80=A6]

 To be honest I think we've reaped a lot of low-hanging fruit so far.=20
 Improving the process will bring some marginal efficiency improvements,=


=20

 but adding more good committers and contributors would be much more=20
 impactful. As far as I can tell there's not (there used to be) a hoard=


=20

 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.=20


 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 hav=




e

 a new process as well as the release being ready to ship.


=20
 Why do you think that would be a good decision? There's a lot of value=


=20

 added right now and a lot of pent-up demand for the many bug fixes and=


=20

 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.


 Of course none of this stops people preparing evolutions of the mainlin=




e

 now even during a mainline repository freeze, this is DVCS / Git and so
 Subversion trunk rules just do not apply!


=20
 Sure. I agree that should (and can easily) change. But I fail to get the=


=20

 overarching theme of your post - I just see agitation, agitation,=20
 agitation, but no coherence.


Sorry but if you haven't got the points already, then my points are more
than valid.

Anyway, it is clear you are asking me to shut up on this topic so this
will be my last post on it.

Back to Java :-((

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
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
Aug 01 2012
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Aug 01 2012
next sibling parent reply "David Nadlinger" <see klickverbot.at> writes:
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
Aug 01 2012
parent "Brad Anderson" <eco gnuk.net> writes:
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).
Aug 01 2012
prev sibling parent reply Russel Winder <russel winder.org.uk> writes:
On Wed, 2012-08-01 at 07:56 -0400, Andrei Alexandrescu wrote:
[=E2=80=A6.]

 Well this doesn't do a lot in the way of substantiating. I do want to be=


=20

 illuminated. I want to get DVCS! And my understanding is that we need to=


=20

 branch whenever we plan a new release, and cherry-pick bugfixes from the=


=20

 mainline, and such. Or (when we have multiple contributors) use one=20
 branch per feature. When I ask you, you neither confirm nor deny that,=


=20

 but instead go for the vague "well you need to change your mindset". I=


=20

 hope you see how this is less than useful.


I am not sure how to respond to this. An email is not the place for a
tutorial on DVCS, and anyway there are a lot of pre-prepared ones
available as books or even on the Web. Moreover there has been a huge
amount of material by many people on this on this list already, there is
little point in just repeating it.

Some simple Web searching reveals:

http://sixrevisions.com/resources/git-tutorials-beginners/

http://learn.github.com/p/intro.html
http://gitready.com/

http://git.or.cz/course/svn.html
http://www.ibm.com/developerworks/linux/library/l-git-subversion-1/

http://www.slideshare.net/skoop/git-for-subversion-users-zendcon-2011

Sadly some of the stuff to be found on the Web is total rubbish, but
there is some good stuff albeit a little old sometimes. Old here is a
problem because Git in 2009 was crap in comparison to Git in 2012.

Dead tree materials available from Amazon (US rather than the more
expensive UK, obviously :-):

http://www.amazon.com/Distributed-Version-Control-Git-ebook/dp/B0067QNR56/r=
ef=3Dsr_1_5?s=3Dbooks&ie=3DUTF8&qid=3D1343896115&sr=3D1-5&keywords=3DGit
http://www.amazon.com/Pragmatic-Guide-Git-Programmers/dp/1934356727/ref=3Ds=
r_1_4?s=3Dbooks&ie=3DUTF8&qid=3D1343896115&sr=3D1-4&keywords=3DGit
http://www.amazon.com/Version-Control-Git-collaborative-development/dp/1449=
316387/ref=3Dsr_1_3?s=3Dbooks&ie=3DUTF8&qid=3D1343896115&sr=3D1-3&keywords=
=3DGit
http://www.amazon.com/Pro-Git-Scott-Chacon/dp/1430218339/ref=3Dsr_1_1?s=3Db=
ooks&ie=3DUTF8&qid=3D1343896115&sr=3D1-1&keywords=3DGit

[=E2=80=A6]

=20
 Sorry Russel but this is just being smug. This conversation goes like thi=


s:

=20
 RW: "You need to change everything! Everything!"
=20
 AA: "Well so I understand from other people, step 1 is to branch for=20
 each release. Great."
=20
 RW: "Yes and no! There is step 1 and no step 1! It's a revolution!"
=20
 AA: "OK so what do I need to do?"
=20
 RW: "You're hopelessly anchored in the wrong mindset! You don't=20
 understand! It's the second coming man!"
=20
 AA: "Well this does little in the way of illuminating me."
=20
 RW: "You're dumb and a bully. I'm not talking anymore."
=20
 If you want to help, I'd be in your debt if you were just a tiny bit=20
 more concrete than telling me how hopeless I am.


The above is not exactly the best way of appealing to a person's better
nature.

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
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
Aug 02 2012
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 8/2/12 5:00 AM, Russel Winder wrote:

 On Wed, 2012-08-01 at 07:56 -0400, 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. 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.


 I am not sure how to respond to this.


Pardon my accent in the suggestion that follows: "Indeed that wasn't one 
of my best posts, but you know that happens to any and all of us. I now 
understand the dynamics and needs of this projects a little better, and 
I probably should one day contribute a exactly one line to it so I get a 
better feel for the whole process. I agree that disciplined use of 
branching for each release is a good start, as others pointed out."


Andrei
Aug 02 2012
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 8/2/12 8:47 AM, Andrei Alexandrescu wrote:

 On 8/2/12 5:00 AM, Russel Winder wrote:

 On Wed, 2012-08-01 at 07:56 -0400, 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. 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.


 I am not sure how to respond to this.


 Pardon my accent in the suggestion that follows: "Indeed that wasn't one
 of my best posts, but you know that happens to any and all of us. I now
 understand the dynamics and needs of this projects a little better, and
 I probably should one day contribute a exactly one line to it so I get a
 better feel for the whole process. I agree that disciplined use of
 branching for each release is a good start, as others pointed out."


s/a exactly/exactly/
Aug 02 2012
prev sibling parent reply Don Clugston <dac nospam.com> writes:
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.
Jul 30 2012
parent Jacob Carlborg <doob me.com> writes:
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
Jul 30 2012