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

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

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

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.

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

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.

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?

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.

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

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