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 parent Russel Winder <russel winder.org.uk> writes:
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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

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 next 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 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
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 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 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 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 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 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.

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 next sibling parent 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
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 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
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
prev sibling next sibling parent "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
prev sibling next 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 next sibling parent Russel Winder <russel winder.org.uk> writes:
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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
prev sibling next sibling parent 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=



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

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
prev sibling next sibling parent "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
prev sibling next sibling parent "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.

git checkout featurebranch git rebase master git merge featurebranch // fast forward?
Jul 31 2012
prev sibling next sibling parent "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
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 =?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 next sibling parent 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?

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
prev sibling 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
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 "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
prev sibling next sibling parent 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
prev sibling next sibling parent Russel Winder <russel winder.org.uk> writes:
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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,

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 next sibling parent Russel Winder <russel winder.org.uk> writes:
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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:
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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=

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

 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=

 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=


 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.
 Of course none of this stops people preparing evolutions of the mainlin=


 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,=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
prev sibling next sibling parent Russel Winder <russel winder.org.uk> writes:
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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


 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 next sibling 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 "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
prev sibling next 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 next sibling 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 Russel Winder <russel winder.org.uk> writes:
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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=

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

=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