Hi All,
I need to be able to push fixes to Cog into general circulation and for this I'd like to maintain a Cog branch in the Subversion tree. But how do I get permission and/or credentials? What's the process to add me to those allowed to write to the repository? Or is there simply a secret username and password that's told to a few? If the later can some kind soul let me have the password. I faithfully promise not to abuse the privilege.
best Eliot
Ignore this. David and I hit send at the same time. Its being taken case of.
Apologies.
On Wed, Jun 23, 2010 at 11:48 AM, Eliot Miranda eliot.miranda@gmail.comwrote:
Hi All,
I need to be able to push fixes to Cog into general circulation and forthis I'd like to maintain a Cog branch in the Subversion tree. But how do I get permission and/or credentials? What's the process to add me to those allowed to write to the repository? Or is there simply a secret username and password that's told to a few? If the later can some kind soul let me have the password. I faithfully promise not to abuse the privilege.
best Eliot
Hi Eliot,
Eliot Miranda wrote:
Ignore this. David and I hit send at the same time. Its being taken case of.
Apologies.
This is nothing to ignore, or to apologize for. This is good news!
I'm a very small contributor in the VM arena, but indeed you are a core developer here.
Thanks, Juan Vuletich
On Wed, Jun 23, 2010 at 11:48 AM, Eliot Miranda <eliot.miranda@gmail.com mailto:eliot.miranda@gmail.com> wrote:
Hi All, I need to be able to push fixes to Cog into general circulation and for this I'd like to maintain a Cog branch in the Subversion tree. But how do I get permission and/or credentials? What's the process to add me to those allowed to write to the repository? Or is there simply a secret username and password that's told to a few? If the later can some kind soul let me have the password. I faithfully promise not to abuse the privilege. best Eliot
Eliot, how about using github for it? It would be much convenient for use, since it supports branching and no need for someone to be added to 'official' list of contributors in order to push own patches. Anyone could make own fork at any time, and at any time, a core developer could backport the changes into official repository. I think github model is very good for community development. Then i, for instance, could push my own changes into my branch, and it will be easy to track, exchange and port the code between forks and official repository.
On 23 June 2010 21:48, Eliot Miranda eliot.miranda@gmail.com wrote:
Hi All, I need to be able to push fixes to Cog into general circulation and for this I'd like to maintain a Cog branch in the Subversion tree. But how do I get permission and/or credentials? What's the process to add me to those allowed to write to the repository? Or is there simply a secret username and password that's told to a few? If the later can some kind soul let me have the password. I faithfully promise not to abuse the privilege. best Eliot
On Thu, Jun 24, 2010 at 8:13 AM, Igor Stasenko siguctua@gmail.com wrote:
Eliot, how about using github for it?
I think that's great for the whole Squeak VM not just Cog. I'm not doing this now because I think Cog should live with the rest of the Squeak VM. Let's start a separate discussion on whether we should move http://squeakvm.org/svn/squeak to github, or at least to git with a home on machines we control..
It would be much convenient for use, since it supports branching and no need for someone to be added to 'official' list of contributors in order to push own patches. Anyone could make own fork at any time, and at any time, a core developer could backport the changes into official repository. I think github model is very good for community development. Then i, for instance, could push my own changes into my branch, and it will be easy to track, exchange and port the code between forks and official repository.
Agreed. Git and/or Mercurial is much better than svn.
best Eliot
On 23 June 2010 21:48, Eliot Miranda eliot.miranda@gmail.com wrote:
Hi All, I need to be able to push fixes to Cog into general circulation and
for this I'd like to maintain a Cog branch in the Subversion tree. But how do I get permission and/or credentials? What's the process to add me to those allowed to write to the repository? Or is there simply a secret username and password that's told to a few? If the later can some kind soul let me have the password. I faithfully promise not to abuse the privilege.
best Eliot
-- Best regards, Igor Stasenko AKA sig.
+1 Mercurial, -1 Git.
Cheers, Josh
On Jun 24, 2010, at 3:43 PM, Eliot Miranda wrote:
On Thu, Jun 24, 2010 at 8:13 AM, Igor Stasenko siguctua@gmail.com wrote:
Eliot, how about using github for it?
I think that's great for the whole Squeak VM not just Cog. I'm not doing this now because I think Cog should live with the rest of the Squeak VM. Let's start a separate discussion on whether we should move http://squeakvm.org/svn/squeak to github, or at least to git with a home on machines we control..
It would be much convenient for use, since it supports branching and no need for someone to be added to 'official' list of contributors in order to push own patches. Anyone could make own fork at any time, and at any time, a core developer could backport the changes into official repository. I think github model is very good for community development. Then i, for instance, could push my own changes into my branch, and it will be easy to track, exchange and port the code between forks and official repository.
Agreed. Git and/or Mercurial is much better than svn.
best Eliot
On 23 June 2010 21:48, Eliot Miranda eliot.miranda@gmail.com wrote:
Hi All, I need to be able to push fixes to Cog into general circulation and for this I'd like to maintain a Cog branch in the Subversion tree. But how do I get permission and/or credentials? What's the process to add me to those allowed to write to the repository? Or is there simply a secret username and password that's told to a few? If the later can some kind soul let me have the password. I faithfully promise not to abuse the privilege. best Eliot
-- Best regards, Igor Stasenko AKA sig.
Does Mercurial provides an infrastructure like github? I mean, if it doesn't , then it is nothing better than svn (the fact that i could have a full copy of repository locally doesn't much matters). I really don't care what version control system used as a backend, i care about infrastructure around it. On a github its ultimately easy to get started and make own fork(s) of existing projects, and moreover, all such things are tracked, not just sources. So, users could see how much forks there, and could navigate through them etc etc. The fancy & clever diff/merge etc things is cool, but used seldom, because 99% of times you just doing edit/commit.
On 25 June 2010 02:46, Josh Gargus josh@schwa.ca wrote:
+1 Mercurial, -1 Git. Cheers, Josh
On Jun 24, 2010, at 3:43 PM, Eliot Miranda wrote:
On Thu, Jun 24, 2010 at 8:13 AM, Igor Stasenko siguctua@gmail.com wrote:
Eliot, how about using github for it?
I think that's great for the whole Squeak VM not just Cog. I'm not doing this now because I think Cog should live with the rest of the Squeak VM. Let's start a separate discussion on whether we should move http://squeakvm.org/svn/squeak to github, or at least to git with a home on machines we control..
It would be much convenient for use, since it supports branching and no need for someone to be added to 'official' list of contributors in order to push own patches. Anyone could make own fork at any time, and at any time, a core developer could backport the changes into official repository. I think github model is very good for community development. Then i, for instance, could push my own changes into my branch, and it will be easy to track, exchange and port the code between forks and official repository.
Agreed. Git and/or Mercurial is much better than svn. best Eliot
On 23 June 2010 21:48, Eliot Miranda eliot.miranda@gmail.com wrote:
Hi All, I need to be able to push fixes to Cog into general circulation and for this I'd like to maintain a Cog branch in the Subversion tree. But how do I get permission and/or credentials? What's the process to add me to those allowed to write to the repository? Or is there simply a secret username and password that's told to a few? If the later can some kind soul let me have the password. I faithfully promise not to abuse the privilege. best Eliot
-- Best regards, Igor Stasenko AKA sig.
On Jun 24, 2010, at 5:17 PM, Igor Stasenko wrote:
Does Mercurial provides an infrastructure like github?
Google Code hosting supports Mercurial. I'm not sure specifically what infrastructure you're talking about; does Google Code meet your needs?
I mean, if it doesn't , then it is nothing better than svn (the fact that i could have a full copy of repository locally doesn't much matters). I really don't care what version control system used as a backend, i care about infrastructure around it. On a github its ultimately easy to get started and make own fork(s) of existing projects,
Not sure how well Google Code meets that need. Anyone?
Cheers, Josh
and moreover, all such things are tracked, not just sources. So, users could see how much forks there, and could navigate through them etc etc. The fancy & clever diff/merge etc things is cool, but used seldom, because 99% of times you just doing edit/commit.
On 25 June 2010 02:46, Josh Gargus josh@schwa.ca wrote:
+1 Mercurial, -1 Git. Cheers, Josh
On Jun 24, 2010, at 3:43 PM, Eliot Miranda wrote:
On Thu, Jun 24, 2010 at 8:13 AM, Igor Stasenko siguctua@gmail.com wrote:
Eliot, how about using github for it?
I think that's great for the whole Squeak VM not just Cog. I'm not doing this now because I think Cog should live with the rest of the Squeak VM. Let's start a separate discussion on whether we should move http://squeakvm.org/svn/squeak to github, or at least to git with a home on machines we control..
It would be much convenient for use, since it supports branching and no need for someone to be added to 'official' list of contributors in order to push own patches. Anyone could make own fork at any time, and at any time, a core developer could backport the changes into official repository. I think github model is very good for community development. Then i, for instance, could push my own changes into my branch, and it will be easy to track, exchange and port the code between forks and official repository.
Agreed. Git and/or Mercurial is much better than svn. best Eliot
On 23 June 2010 21:48, Eliot Miranda eliot.miranda@gmail.com wrote:
Hi All, I need to be able to push fixes to Cog into general circulation and for this I'd like to maintain a Cog branch in the Subversion tree. But how do I get permission and/or credentials? What's the process to add me to those allowed to write to the repository? Or is there simply a secret username and password that's told to a few? If the later can some kind soul let me have the password. I faithfully promise not to abuse the privilege. best Eliot
-- Best regards, Igor Stasenko AKA sig.
-- Best regards, Igor Stasenko AKA sig.
Bazaar is better than mercurial, one of the launchpad team is a squeaker.
Launchpad is better than github.
Keith
On 25 Jun 2010, at 02:26, Josh Gargus wrote:
On Jun 24, 2010, at 5:17 PM, Igor Stasenko wrote:
Does Mercurial provides an infrastructure like github?
Google Code hosting supports Mercurial. I'm not sure specifically what infrastructure you're talking about; does Google Code meet your needs?
I mean, if it doesn't , then it is nothing better than svn (the fact that i could have a full copy of repository locally doesn't much matters). I really don't care what version control system used as a backend, i care about infrastructure around it. On a github its ultimately easy to get started and make own fork(s) of existing projects,
Not sure how well Google Code meets that need. Anyone?
Cheers, Josh
and moreover, all such things are tracked, not just sources. So, users could see how much forks there, and could navigate through them etc etc. The fancy & clever diff/merge etc things is cool, but used seldom, because 99% of times you just doing edit/commit.
On 25 June 2010 02:46, Josh Gargus josh@schwa.ca wrote:
+1 Mercurial, -1 Git. Cheers, Josh
On Jun 24, 2010, at 3:43 PM, Eliot Miranda wrote:
On Thu, Jun 24, 2010 at 8:13 AM, Igor Stasenko siguctua@gmail.com wrote:
Eliot, how about using github for it?
I think that's great for the whole Squeak VM not just Cog. I'm not doing this now because I think Cog should live with the rest of the Squeak VM. Let's start a separate discussion on whether we should move http://squeakvm.org/svn/squeak to github, or at least to git with a home on machines we control..
It would be much convenient for use, since it supports branching and no need for someone to be added to 'official' list of contributors in order to push own patches. Anyone could make own fork at any time, and at any time, a core developer could backport the changes into official repository. I think github model is very good for community development. Then i, for instance, could push my own changes into my branch, and it will be easy to track, exchange and port the code between forks and official repository.
Agreed. Git and/or Mercurial is much better than svn. best Eliot
On 23 June 2010 21:48, Eliot Miranda eliot.miranda@gmail.com wrote:
Hi All, I need to be able to push fixes to Cog into general circulation and for this I'd like to maintain a Cog branch in the Subversion tree. But how do I get permission and/or credentials? What's the process to add me to those allowed to write to the repository? Or is there simply a secret username and password that's told to a few? If the later can some kind soul let me have the password. I faithfully promise not to abuse the privilege. best Eliot
-- Best regards, Igor Stasenko AKA sig.
-- Best regards, Igor Stasenko AKA sig.
On Fri, Jun 25, 2010 at 4:03 AM, keith keith_hodges@yahoo.co.uk wrote:
Bazaar is better than mercurial, one of the launchpad team is a squeaker.
Launchpad is better than github.
I have never used bazaar, but Launchpad looks great. https://launchpad.net/+tour/index
Ubuntu integration + translation + API are worthwhile
Laurent
Keith
On 25 Jun 2010, at 02:26, Josh Gargus wrote:
On Jun 24, 2010, at 5:17 PM, Igor Stasenko wrote:
Does Mercurial provides an infrastructure like github?
Google Code hosting supports Mercurial. I'm not sure specifically what infrastructure you're talking about; does Google Code meet your needs?
I mean, if it doesn't , then it is nothing better than svn (the fact
that i could have a full copy of repository locally doesn't much matters). I really don't care what version control system used as a backend, i care about infrastructure around it. On a github its ultimately easy to get started and make own fork(s) of existing projects,
Not sure how well Google Code meets that need. Anyone?
Cheers, Josh
and moreover, all such things are tracked, not just sources.
So, users could see how much forks there, and could navigate through them etc etc. The fancy & clever diff/merge etc things is cool, but used seldom, because 99% of times you just doing edit/commit.
On 25 June 2010 02:46, Josh Gargus josh@schwa.ca wrote:
+1 Mercurial, -1 Git. Cheers, Josh
On Jun 24, 2010, at 3:43 PM, Eliot Miranda wrote:
On Thu, Jun 24, 2010 at 8:13 AM, Igor Stasenko siguctua@gmail.com wrote:
Eliot, how about using github for it?
I think that's great for the whole Squeak VM not just Cog. I'm not doing this now because I think Cog should live with the rest of the Squeak VM. Let's start a separate discussion on whether we should move http://squeakvm.org/svn/squeak to github, or at least to git with a home on machines we control..
It would be much convenient for use, since it supports branching and no need for someone to be added to 'official' list of contributors in order to push own patches. Anyone could make own fork at any time, and at any time, a core developer could backport the changes into official repository. I think github model is very good for community development. Then i, for instance, could push my own changes into my branch, and it will be easy to track, exchange and port the code between forks and official repository.
Agreed. Git and/or Mercurial is much better than svn. best Eliot
On 23 June 2010 21:48, Eliot Miranda eliot.miranda@gmail.com wrote:
Hi All, I need to be able to push fixes to Cog into general circulation and for this I'd like to maintain a Cog branch in the Subversion tree. But how do I get permission and/or credentials? What's the process to add me to those allowed to write to the repository? Or is there simply a secret username and password that's told to a few? If the later can some kind soul let me have the password. I faithfully promise not to abuse the privilege. best Eliot
-- Best regards, Igor Stasenko AKA sig.
-- Best regards, Igor Stasenko AKA sig.
Arguments about which DVCS is better should be avoided, because they all provide more or less the same features.
About the hosting platforms: The free plan in BitBucket seems too limited (1Gb may not be enough for the VM and all of its history). GitHub is really great for its support of forks, but the additional services like issue tracking are not that great. Launchpad has a good bug tracking system, and I like the code review workflow directly integrated in the platform.
<ignore the troll>I like Git because I'm used to it, I like Hg because I can tweak it, I don't like bzr because I don't know it</ignore the troll>
On Fri, Jun 25, 2010 at 8:05 AM, laurent laffont laurent.laffont@gmail.com wrote:
On Fri, Jun 25, 2010 at 4:03 AM, keith keith_hodges@yahoo.co.uk wrote:
Bazaar is better than mercurial, one of the launchpad team is a squeaker.
Launchpad is better than github.
I have never used bazaar, but Launchpad looks great. https://launchpad.net/+tour/index Ubuntu integration + translation + API are worthwhile Laurent
Keith
On 25 Jun 2010, at 02:26, Josh Gargus wrote:
On Jun 24, 2010, at 5:17 PM, Igor Stasenko wrote:
Does Mercurial provides an infrastructure like github?
Google Code hosting supports Mercurial. I'm not sure specifically what infrastructure you're talking about; does Google Code meet your needs?
I mean, if it doesn't , then it is nothing better than svn (the fact that i could have a full copy of repository locally doesn't much matters). I really don't care what version control system used as a backend, i care about infrastructure around it. On a github its ultimately easy to get started and make own fork(s) of existing projects,
Not sure how well Google Code meets that need. Anyone?
Cheers, Josh
and moreover, all such things are tracked, not just sources. So, users could see how much forks there, and could navigate through them etc etc. The fancy & clever diff/merge etc things is cool, but used seldom, because 99% of times you just doing edit/commit.
On 25 June 2010 02:46, Josh Gargus josh@schwa.ca wrote:
+1 Mercurial, -1 Git. Cheers, Josh
On Jun 24, 2010, at 3:43 PM, Eliot Miranda wrote:
On Thu, Jun 24, 2010 at 8:13 AM, Igor Stasenko siguctua@gmail.com wrote:
Eliot, how about using github for it?
I think that's great for the whole Squeak VM not just Cog. I'm not doing this now because I think Cog should live with the rest of the Squeak VM. Let's start a separate discussion on whether we should move http://squeakvm.org/svn/squeak to github, or at least to git with a home on machines we control..
It would be much convenient for use, since it supports branching and no need for someone to be added to 'official' list of contributors in order to push own patches. Anyone could make own fork at any time, and at any time, a core developer could backport the changes into official repository. I think github model is very good for community development. Then i, for instance, could push my own changes into my branch, and it will be easy to track, exchange and port the code between forks and official repository.
Agreed. Git and/or Mercurial is much better than svn. best Eliot
On 23 June 2010 21:48, Eliot Miranda eliot.miranda@gmail.com wrote: > > Hi All, > I need to be able to push fixes to Cog into general circulation and for this I'd like to maintain a Cog branch in the Subversion tree. But how do I get permission and/or credentials? What's the process to add me to those allowed to write to the repository? Or is there simply a secret username and password that's told to a few? If the later can some kind soul let me have the password. I faithfully promise not to abuse the privilege. > best > Eliot >
-- Best regards, Igor Stasenko AKA sig.
-- Best regards, Igor Stasenko AKA sig.
On 25 June 2010 04:26, Josh Gargus josh@schwa.ca wrote:
On Jun 24, 2010, at 5:17 PM, Igor Stasenko wrote:
Does Mercurial provides an infrastructure like github?
Google Code hosting supports Mercurial. I'm not sure specifically what infrastructure you're talking about; does Google Code meet your needs?
I advise to take a glance at github. A google code is a project-centric thingy. Its all about creating a public place for single project i.e. wiki, issue tracker etc. Github is user(developer) centric. One user could create a project, then others may create forks or subforks of his project(s) and continue development by own, without the need of permission or any administering of original project owner, and github tracking all connections and history between forks.
I mean, if it doesn't , then it is nothing better than svn (the fact that i could have a full copy of repository locally doesn't much matters). I really don't care what version control system used as a backend, i care about infrastructure around it. On a github its ultimately easy to get started and make own fork(s) of existing projects,
Not sure how well Google Code meets that need. Anyone?
Cheers, Josh
and moreover, all such things are tracked, not just sources. So, users could see how much forks there, and could navigate through them etc etc. The fancy & clever diff/merge etc things is cool, but used seldom, because 99% of times you just doing edit/commit.
On 25 June 2010 02:46, Josh Gargus josh@schwa.ca wrote:
+1 Mercurial, -1 Git. Cheers, Josh
On Jun 24, 2010, at 3:43 PM, Eliot Miranda wrote:
On Thu, Jun 24, 2010 at 8:13 AM, Igor Stasenko siguctua@gmail.com wrote:
Eliot, how about using github for it?
I think that's great for the whole Squeak VM not just Cog. I'm not doing this now because I think Cog should live with the rest of the Squeak VM. Let's start a separate discussion on whether we should move http://squeakvm.org/svn/squeak to github, or at least to git with a home on machines we control..
It would be much convenient for use, since it supports branching and no need for someone to be added to 'official' list of contributors in order to push own patches. Anyone could make own fork at any time, and at any time, a core developer could backport the changes into official repository. I think github model is very good for community development. Then i, for instance, could push my own changes into my branch, and it will be easy to track, exchange and port the code between forks and official repository.
Agreed. Git and/or Mercurial is much better than svn. best Eliot
On 23 June 2010 21:48, Eliot Miranda eliot.miranda@gmail.com wrote:
Hi All, I need to be able to push fixes to Cog into general circulation and for this I'd like to maintain a Cog branch in the Subversion tree. But how do I get permission and/or credentials? What's the process to add me to those allowed to write to the repository? Or is there simply a secret username and password that's told to a few? If the later can some kind soul let me have the password. I faithfully promise not to abuse the privilege. best Eliot
-- Best regards, Igor Stasenko AKA sig.
-- Best regards, Igor Stasenko AKA sig.
On Jun 24, 2010, at 7:16 PM, Igor Stasenko wrote:
On 25 June 2010 04:26, Josh Gargus josh@schwa.ca wrote:
On Jun 24, 2010, at 5:17 PM, Igor Stasenko wrote:
Does Mercurial provides an infrastructure like github?
Google Code hosting supports Mercurial. I'm not sure specifically what infrastructure you're talking about; does Google Code meet your needs?
I advise to take a glance at github. A google code is a project-centric thingy. Its all about creating a public place for single project i.e. wiki, issue tracker etc. Github is user(developer) centric. One user could create a project, then others may create forks or subforks of his project(s) and continue development by own, without the need of permission or any administering of original project owner, and github tracking all connections and history between forks.
OK, will do. I don't like git too much, but github may make it worthwhile.
Thanks, Josh
On 6/24/2010 7:16 PM, Igor Stasenko wrote:
One user could create a project, then others may create forks or subforks of his project(s)
How exactly is this a good thing? I don't want 200 forked Squeak VM versions; I want one canonical source that people can build from.
Cheers, - Andreas
On Fri, Jun 25, 2010 at 9:53 AM, Andreas Raab andreas.raab@gmx.de wrote:
On 6/24/2010 7:16 PM, Igor Stasenko wrote:
One user could create a project, then others may create forks or subforks of his project(s)
How exactly is this a good thing? I don't want 200 forked Squeak VM versions; I want one canonical source that people can build from.
Forks can be really useful for people who have to maintain a set of patches that may not be accepted in the repository (applications requiring a specific VM configuration, servers, etc). With the branching workflows in DVCS, you can still get updates from the main repository, develop new features in parallel, and maintain your patches without impacting the rest of the developers.
With SVN, if you don't have commit access, you only have two possibilities: store a lot of patches, and reapply them by hand at each update, or use a dirty trick like git-svn. I'm using git-svn right now: it is great to be able to commit locally, but it's a bit heavy to use.
On 6/25/2010 1:05 AM, Geoffroy Couprie wrote:
On Fri, Jun 25, 2010 at 9:53 AM, Andreas Raabandreas.raab@gmx.de wrote:
On 6/24/2010 7:16 PM, Igor Stasenko wrote:
One user could create a project, then others may create forks or subforks of his project(s)
How exactly is this a good thing? I don't want 200 forked Squeak VM versions; I want one canonical source that people can build from.
Forks can be really useful for people who have to maintain a set of patches that may not be accepted in the repository (applications requiring a specific VM configuration, servers, etc).
Do we have this problem? What patches do you or anyone else have that can or should not be integrated in the main source?
Cheers, - Andreas
With the branching workflows in DVCS, you can still get updates from the main repository, develop new features in parallel, and maintain your patches without impacting the rest of the developers.
With SVN, if you don't have commit access, you only have two possibilities: store a lot of patches, and reapply them by hand at each update, or use a dirty trick like git-svn. I'm using git-svn right now: it is great to be able to commit locally, but it's a bit heavy to use.
immutability bit if people want to play with it and that not everybody wants that? Cmake fixes proposed by geoffroy some weeks ago?
Stef
On Jun 25, 2010, at 10:09 AM, Andreas Raab wrote:
On 6/25/2010 1:05 AM, Geoffroy Couprie wrote:
On Fri, Jun 25, 2010 at 9:53 AM, Andreas Raabandreas.raab@gmx.de wrote:
On 6/24/2010 7:16 PM, Igor Stasenko wrote:
One user could create a project, then others may create forks or subforks of his project(s)
How exactly is this a good thing? I don't want 200 forked Squeak VM versions; I want one canonical source that people can build from.
Forks can be really useful for people who have to maintain a set of patches that may not be accepted in the repository (applications requiring a specific VM configuration, servers, etc).
Do we have this problem? What patches do you or anyone else have that can or should not be integrated in the main source?
Cheers,
- Andreas
With the branching workflows in DVCS, you can still get updates from the main repository, develop new features in parallel, and maintain your patches without impacting the rest of the developers.
With SVN, if you don't have commit access, you only have two possibilities: store a lot of patches, and reapply them by hand at each update, or use a dirty trick like git-svn. I'm using git-svn right now: it is great to be able to commit locally, but it's a bit heavy to use.
On Fri, Jun 25, 2010 at 10:09 AM, Andreas Raab andreas.raab@gmx.de wrote:
On 6/25/2010 1:05 AM, Geoffroy Couprie wrote:
On Fri, Jun 25, 2010 at 9:53 AM, Andreas Raabandreas.raab@gmx.de wrote:
On 6/24/2010 7:16 PM, Igor Stasenko wrote:
One user could create a project, then others may create forks or subforks of his project(s)
How exactly is this a good thing? I don't want 200 forked Squeak VM versions; I want one canonical source that people can build from.
Forks can be really useful for people who have to maintain a set of patches that may not be accepted in the repository (applications requiring a specific VM configuration, servers, etc).
Do we have this problem? What patches do you or anyone else have that can or should not be integrated in the main source?
I have my CMake patches (to be able to build the Windows VM with CMake), and some patches to build the Windows VM with GCC. I sent the patches here 2 months ago (you never answered on that thread), and although people seemed interested by that code, it was never added in the repository. I had to store the CMake patches, and then the other Windows patches, and working on these different pieces of code without being able to commit was painful.
I also modify the VM for self education/fun purposes, and these modifications would never be accepted in the main tree (heavily breaking large parts of the memory allocations, weird plugins, etc).
On 6/25/2010 1:23 AM, Geoffroy Couprie wrote:
Do we have this problem? What patches do you or anyone else have that can or should not be integrated in the main source?
I have my CMake patches (to be able to build the Windows VM with CMake), and some patches to build the Windows VM with GCC. I sent the patches here 2 months ago (you never answered on that thread), and although people seemed interested by that code, it was never added in the repository. I had to store the CMake patches, and then the other Windows patches, and working on these different pieces of code without being able to commit was painful.
Sorry about this, I've been quite busy with other things (such as the Cog release). The patches itself sound quite reasonable to me and probably should be integrated, no?
BTW, I don't think you've ever asked for commit rights. Regarding cmake, I have no problems giving you access so that you can keep the cmake stuff current.
I also modify the VM for self education/fun purposes, and these modifications would never be accepted in the main tree (heavily breaking large parts of the memory allocations, weird plugins, etc).
But those patches then are just as unlikely to apply to other large changes in the main VM sources. That's a bit my point here. We've basically got two options:
1) Everyone forks in their own little worlds, creating chaos. We've had that in the past, it did not work AT ALL.
2) We try to be reasonable and integrate things back into the main sources. Give people who do active development commit rights for the relevant portions. Stay reasoable all along.
I'm *strongly* in favor of the latter.
Cheers, - Andreas
On 25.06.2010, at 10:39, Andreas Raab wrote:
On 6/25/2010 1:23 AM, Geoffroy Couprie wrote:
Do we have this problem? What patches do you or anyone else have that can or should not be integrated in the main source?
I have my CMake patches (to be able to build the Windows VM with CMake), and some patches to build the Windows VM with GCC. I sent the patches here 2 months ago (you never answered on that thread), and although people seemed interested by that code, it was never added in the repository. I had to store the CMake patches, and then the other Windows patches, and working on these different pieces of code without being able to commit was painful.
Sorry about this, I've been quite busy with other things (such as the Cog release). The patches itself sound quite reasonable to me and probably should be integrated, no?
BTW, I don't think you've ever asked for commit rights. Regarding cmake, I have no problems giving you access so that you can keep the cmake stuff current.
I also modify the VM for self education/fun purposes, and these modifications would never be accepted in the main tree (heavily breaking large parts of the memory allocations, weird plugins, etc).
But those patches then are just as unlikely to apply to other large changes in the main VM sources. That's a bit my point here. We've basically got two options:
Everyone forks in their own little worlds, creating chaos. We've had that in the past, it did not work AT ALL.
We try to be reasonable and integrate things back into the main sources. Give people who do active development commit rights for the relevant portions. Stay reasoable all along.
I'm *strongly* in favor of the latter.
Cheers,
- Andreas
Maybe you have not developed using a distributed versioning system yet? A DCVS would be for the VM what the trunk process is for the Squeak image. There still would be a "mainline" which is the official source tree. But people could work independently on their changes, and it's really simple to fold changes back, much simpler than in svn.
The reason 1) above did not work is because there was no way to track the changes and fold them back. Maybe read "the forking non-problem" here: http://hgbook.red-bean.com/read/how-did-we-get-here.html
A DCVS allows precisely that tracking and fold-back. You could develop in private, but in practice having a shared repository for all private trees works well. E.g., look at the Sugar repository:
http://git.sugarlabs.org/projects/sugar
There is a "mainline" which several people have commit access to, constituting the official sources. But there are also any number of clones for people's experiments. It's really simple to switch your working copy to one of these personal trees, to test something, and switch back.
The thing is that there is zero barrier to entry - anyone can clone the official tree and start hacking. It's like the inbox.
So I'm strongly in favor of switching to a DCVS. I personally only ever used git, but since hg supposedly has better x-platform support that would be fine too (the Windows devs should speak up). Wouldn't be opposed to bzr either.
- Bert -
On 2010/06/25 11:18, Bert Freudenberg wrote:
On 25.06.2010, at 10:39, Andreas Raab wrote:
On 6/25/2010 1:23 AM, Geoffroy Couprie wrote:
Do we have this problem? What patches do you or anyone else have that can or should not be integrated in the main source?
I have my CMake patches (to be able to build the Windows VM with CMake), and some patches to build the Windows VM with GCC. I sent the patches here 2 months ago (you never answered on that thread), and although people seemed interested by that code, it was never added in the repository. I had to store the CMake patches, and then the other Windows patches, and working on these different pieces of code without being able to commit was painful.
Sorry about this, I've been quite busy with other things (such as the Cog release). The patches itself sound quite reasonable to me and probably should be integrated, no?
BTW, I don't think you've ever asked for commit rights. Regarding cmake, I have no problems giving you access so that you can keep the cmake stuff current.
I also modify the VM for self education/fun purposes, and these modifications would never be accepted in the main tree (heavily breaking large parts of the memory allocations, weird plugins, etc).
But those patches then are just as unlikely to apply to other large changes in the main VM sources. That's a bit my point here. We've basically got two options:
Everyone forks in their own little worlds, creating chaos. We've had that in the past, it did not work AT ALL.
We try to be reasonable and integrate things back into the main sources. Give people who do active development commit rights for the relevant portions. Stay reasoable all along.
I'm *strongly* in favor of the latter.
Cheers,
- Andreas
Maybe you have not developed using a distributed versioning system yet? A DCVS would be for the VM what the trunk process is for the Squeak image. There still would be a "mainline" which is the official source tree. But people could work independently on their changes, and it's really simple to fold changes back, much simpler than in svn.
The reason 1) above did not work is because there was no way to track the changes and fold them back. Maybe read "the forking non-problem" here: http://hgbook.red-bean.com/read/how-did-we-get-here.html
A DCVS allows precisely that tracking and fold-back. You could develop in private, but in practice having a shared repository for all private trees works well. E.g., look at the Sugar repository:
http://git.sugarlabs.org/projects/sugar
There is a "mainline" which several people have commit access to, constituting the official sources. But there are also any number of clones for people's experiments. It's really simple to switch your working copy to one of these personal trees, to test something, and switch back.
The thing is that there is zero barrier to entry - anyone can clone the official tree and start hacking. It's like the inbox.
So I'm strongly in favor of switching to a DCVS. I personally only ever used git, but since hg supposedly has better x-platform support that would be fine too (the Windows devs should speak up). Wouldn't be opposed to bzr either.
I use both hg and git, in the guise of TortoiseHg and TortoiseGit. Both please me.
I'm mildly more in favour of git. (1) TortoiseHg's UI doesn't look much like a native Windows app and fails to give you feedback that it's actually done something. (2) It's nice and easy to set up a shared account for serving up multiple repositories on your own machine for git - you just need SSH. With hg you have to install a web server and play around with hgwebdir.cgi. (In my probably limited experience: feel free to correct me!)
My main issue with both git and hg is a non-issue here: it's annoying to _share_ repositories on a Windows machine (but hg does have a built-in web server for ad-hoc sharing of single repositories).
I tried bzr (TortoiseBzr) year before last, or maybe early last year. Hopefully it has vastly improved in stability - loads of functionality was either stubbed out in the UI, or blew up.
frank
On Fri, Jun 25, 2010 at 11:18:19AM +0200, Bert Freudenberg wrote:
So I'm strongly in favor of switching to a DCVS. I personally only ever used git, but since hg supposedly has better x-platform support that would be fine too (the Windows devs should speak up). Wouldn't be opposed to bzr either.
I don't know if this is a good idea or not, but I have to say that right now would be a poor time to consider major changes to the infrastructure unless there is a *truly* compelling reason to do so. The reason is managing change overall - the Cog development represents a huge opportunity, but it also implies a lot of new things to understand and integrate, and new work to be done by folks who will need to understand the changes. Performing a simultanious migration to new version control and build processes would likely lead to delays and disruption in the more important objective of making progress on the VM.
I suggest that we focus on successful integration of Cog this year, and consider moving to some new version control infrastructure at a time when we are sailing on calmer waters.
Dave
I don't know, what else arguments could convince people to switch to DCVS. Multiple people presented their concerns here. And in summary, i want to emphasize this:
- i made the patch - i want make it available and easy to find and merge by others - i don't have to worry that it will rot on my hard disk
So, Andreas, it is not about explosion of forks, it is about making our life easier and progressing faster.
And for Cog , i think , this is the _right time_ to do it now. Because currently it doesn't have a public repository, so why not?
Right now, a situation is unpleasant. Any patch, no matter how userful it is is doomed to be rot and forgotten, if its not included into 'official' repository. It is also complicating a workflow for those, who want to try it out and give feedback. The patch author have to find the way how to deliver his patches to public. This is showstopper.
On Jun 25, 2010, at 3:05 36PM, Igor Stasenko wrote:
I don't know, what else arguments could convince people to switch to DCVS. Multiple people presented their concerns here. And in summary, i want to emphasize this:
- i made the patch
- i want make it available and easy to find and merge by others
- i don't have to worry that it will rot on my hard disk
So, Andreas, it is not about explosion of forks, it is about making our life easier and progressing faster.
And for Cog , i think , this is the _right time_ to do it now. Because currently it doesn't have a public repository, so why not?
Right now, a situation is unpleasant. Any patch, no matter how userful it is is doomed to be rot and forgotten, if its not included into 'official' repository. It is also complicating a workflow for those, who want to try it out and give feedback. The patch author have to find the way how to deliver his patches to public. This is showstopper.
-- Best regards, Igor Stasenko AKA sig.
+1
When merging is easy, forks become your friend. (A fork in GIT or Mercurial is very different from what Andreas seems to put into the concept) Both for seeing what is being done elsewhere, and for combatting bitrot for useful pieces of code that are for some reason ignored.
Cheers, Henry
On Fri, Jun 25, 2010 at 2:14 PM, David T. Lewis lewis@mail.msen.com wrote:
On Fri, Jun 25, 2010 at 11:18:19AM +0200, Bert Freudenberg wrote:
So I'm strongly in favor of switching to a DCVS. I personally only ever used git, but since hg supposedly has better x-platform support that would be fine too (the Windows devs should speak up). Wouldn't be opposed to bzr either.
I don't know if this is a good idea or not, but I have to say that right now would be a poor time to consider major changes to the infrastructure unless there is a *truly* compelling reason to do so.
I think the opposite :) It's a wonderful opportunity to learn. When I started working on the Linux kernel, I've learned a lot because all patches go through the Linux Kernel Mailing List (thanks to Git), discussed, reviewed, integrated in experimental branches and finally in official one.
A real force of Git infrastructure is to bring visibility. Cog is here, let's learn, play and contribute easily.
Cheers,
Laurent
The reason is managing change overall - the Cog development represents a huge opportunity, but it also implies a lot of new things to understand and integrate, and new work to be done by folks who will need to understand the changes. Performing a simultanious migration to new version control and build processes would likely lead to delays and disruption in the more important objective of making progress on the VM.
I suggest that we focus on successful integration of Cog this year, and consider moving to some new version control infrastructure at a time when we are sailing on calmer waters.
Dave
I think there's a misconception here. The fact that DVCS makes you easy to branch doesn't mean that there will be a lot of disconnected incompatible forks thrown out there.
Branches in DVCS are not the same as branches in SVN, they are not used the same way. i.e. in GIT, you create a branch each time you start working in a new feature, no matter if it is big or small. That helps you to keep your changes isolated from the mainline. Then, you commit your changes into your branch. After some commits, when the code is ready, you merge them to the mainline again.
The are many things that are really really really nice thing about DVCS. One of them is that it helps A LOT in merging the changes back. Besides, you can have your changes in a really tidy way, because you go on commiting all the time, even if your code is not ready to be merged to the mainline, you do it locally. When the code is ready, the DVCS will make it very easy to merge it back to the mainline and to do it without loosing the history of commits. At last, with infraestructure like github (or others) you can make your own branch public so that other people can collaborate with you, and the result is that your branches end up getting incorporated into the mainline quicker and are never lost.
Of course, I support the idea of DVCS, be it any of them (I think they are all compatible anyway, because they share their distributed nature).
Regards, Javier.
On Fri, Jun 25, 2010 at 10:26 AM, laurent laffont <laurent.laffont@gmail.com
wrote:
On Fri, Jun 25, 2010 at 2:14 PM, David T. Lewis lewis@mail.msen.comwrote:
On Fri, Jun 25, 2010 at 11:18:19AM +0200, Bert Freudenberg wrote:
So I'm strongly in favor of switching to a DCVS. I personally only ever used git, but since hg supposedly has better x-platform support that would be fine too (the Windows devs should speak up). Wouldn't be opposed to bzr either.
I don't know if this is a good idea or not, but I have to say that right now would be a poor time to consider major changes to the infrastructure unless there is a *truly* compelling reason to do so.
I think the opposite :) It's a wonderful opportunity to learn. When I started working on the Linux kernel, I've learned a lot because all patches go through the Linux Kernel Mailing List (thanks to Git), discussed, reviewed, integrated in experimental branches and finally in official one.
A real force of Git infrastructure is to bring visibility. Cog is here, let's learn, play and contribute easily.
Cheers,
Laurent
The reason is managing change overall - the Cog development represents a huge opportunity, but it also implies a lot of new things to understand and integrate, and new work to be done by folks who will need to understand the changes. Performing a simultanious migration to new version control and build processes would likely lead to delays and disruption in the more important objective of making progress on the VM.
I suggest that we focus on successful integration of Cog this year, and consider moving to some new version control infrastructure at a time when we are sailing on calmer waters.
Dave
On 6/25/2010 2:18 AM, Bert Freudenberg wrote:
Maybe you have not developed using a distributed versioning system yet? A DCVS would be for the VM what the trunk process is for the Squeak image.
But the trunk model is powerful because it is *centralized* and because it *avoids* forking. Don't confuse the technical ability to fork with *desirability*. What I hear people saying in this discussion is "oh, this will be so great, we can all just fork like crazy". It is the attitude about the desirability of forking that I object to.
It is *not* desirable to fork.
Cheers, - Andreas
On Fri, Jun 25, 2010 at 9:11 PM, Andreas Raab andreas.raab@gmx.de wrote:
On 6/25/2010 2:18 AM, Bert Freudenberg wrote:
Maybe you have not developed using a distributed versioning system yet? A DCVS would be for the VM what the trunk process is for the Squeak image.
But the trunk model is powerful because it is *centralized* and because it *avoids* forking. Don't confuse the technical ability to fork with *desirability*. What I hear people saying in this discussion is "oh, this will be so great, we can all just fork like crazy". It is the attitude about the desirability of forking that I object to.
It is *not* desirable to fork.
Why ?
Laurent
Cheers,
- Andreas
On 25 June 2010 22:11, Andreas Raab andreas.raab@gmx.de wrote:
On 6/25/2010 2:18 AM, Bert Freudenberg wrote:
Maybe you have not developed using a distributed versioning system yet? A DCVS would be for the VM what the trunk process is for the Squeak image.
But the trunk model is powerful because it is *centralized* and because it *avoids* forking. Don't confuse the technical ability to fork with *desirability*. What I hear people saying in this discussion is "oh, this will be so great, we can all just fork like crazy". It is the attitude about the desirability of forking that I object to.
I disagree. A trunk development model is decentralized! Think: Before that we got a release teams, which were much more centralized comparing to trunk. And release team was a major bottleneck and reason of dissatisfaction of many developers, who either leaved community (loss of man resources) or created own fork (split of man resources), such as Pharo.
In any case, let make one thing clear: keeping things under strict control, and having all levers under your fingertips doesn't gives any guarantees that there will be no more forks. It is pointless and delusional.
Once we removed this bottleneck and allowed a much wider range of developers to freely contribute to trunk, we got much faster development. And i feel that trunk model makes appearance of new forks much less probable than with release teams model. Correct me if i wrong.
So, what i actually proposing is to do the same with VM. Nothing else! Currently the VM development is centralized and in direct control of few people. And the fact is, that these people simply don't have time to overlook of all activity around VM (i could quote your own reply in this thread), and also when there are few people who deciding, what to include and what not, the risk of strategic mistake is very high.
I don't even want to mention that inability to deal with this bottleneck were the major reason why Pharo forked out from Squeak. Now, apply this situation to VM. Same case: in order to prevent a major forking, we should loose the control, and allow contribution in a masses. This is where github could play the same role as trunk does.
It is *not* desirable to fork.
Me too. And, obviously, if you don't wanna forks to pop up, then you should put VM on github :)
P.S. besides. Cog is a fork. So, how this complies with "It is *not* desirable to fork." ? ;)
Cheers, - Andreas
Few more words.
I wanna repeat this one more time: it is not technical issue. It is more political/organizational one.
Thunk having a single public repository, but it allows developers to easily contribute to it. In same way, i see a github as such meta-repository, which would allow developers to easily contribute to VM development.
While technically, and strictly speaking, each user will have own fork, but politically, it is not necessary so, and it is completely up to us to decide and organize a process. Github is just a tool, which provides a necessary infrastructure, in same way as MC does this for trunk.
On 25 June 2010 22:48, Igor Stasenko siguctua@gmail.com wrote:
On 25 June 2010 22:11, Andreas Raab andreas.raab@gmx.de wrote:
On 6/25/2010 2:18 AM, Bert Freudenberg wrote:
Maybe you have not developed using a distributed versioning system yet? A DCVS would be for the VM what the trunk process is for the Squeak image.
But the trunk model is powerful because it is *centralized* and because it *avoids* forking. Don't confuse the technical ability to fork with *desirability*. What I hear people saying in this discussion is "oh, this will be so great, we can all just fork like crazy". It is the attitude about the desirability of forking that I object to.
I disagree. A trunk development model is decentralized! Think: Before that we got a release teams, which were much more centralized comparing to trunk. And release team was a major bottleneck and reason of dissatisfaction of many developers, who either leaved community (loss of man resources) or created own fork (split of man resources), such as Pharo.
In any case, let make one thing clear: keeping things under strict control, and having all levers under your fingertips doesn't gives any guarantees that there will be no more forks. It is pointless and delusional.
Once we removed this bottleneck and allowed a much wider range of developers to freely contribute to trunk, we got much faster development. And i feel that trunk model makes appearance of new forks much less probable than with release teams model. Correct me if i wrong.
So, what i actually proposing is to do the same with VM. Nothing else! Currently the VM development is centralized and in direct control of few people. And the fact is, that these people simply don't have time to overlook of all activity around VM (i could quote your own reply in this thread), and also when there are few people who deciding, what to include and what not, the risk of strategic mistake is very high.
I don't even want to mention that inability to deal with this bottleneck were the major reason why Pharo forked out from Squeak. Now, apply this situation to VM. Same case: in order to prevent a major forking, we should loose the control, and allow contribution in a masses. This is where github could play the same role as trunk does.
It is *not* desirable to fork.
Me too. And, obviously, if you don't wanna forks to pop up, then you should put VM on github :)
P.S. besides. Cog is a fork. So, how this complies with "It is *not* desirable to fork." ? ;)
Cheers, - Andreas
-- Best regards, Igor Stasenko AKA sig.
On 25.06.2010, at 21:11, Andreas Raab wrote:
On 6/25/2010 2:18 AM, Bert Freudenberg wrote:
Maybe you have not developed using a distributed versioning system yet? A DCVS would be for the VM what the trunk process is for the Squeak image.
But the trunk model is powerful because it is *centralized* and because it *avoids* forking. Don't confuse the technical ability to fork with *desirability*. What I hear people saying in this discussion is "oh, this will be so great, we can all just fork like crazy". It is the attitude about the desirability of forking that I object to.
It is *not* desirable to fork.
Cheers,
- Andreas
But it is desirable to being able to develop without having to ask anyone's permission. And to make it dead easy for these changes to be folded into the official version, if the gatekeeper chose to. That's what we have the inbox for - everybody is encouraged to use the same tool as the core developers, because that makes it easy to merge those contributions. Trusted developers work directly on the trunk of course. And that's what using a DCVS would allow for the VM too. It would allow me to use the same tool in my own development as the VM maintainers.
I really cannot understand your objection. Using git/hg with a centralized repository seems to me to be the best equivalent of the Monticello trunk/inbox model. Of course people could fork the trunk packages, in their own repositories. Having those clones visible right next to the mainline version would actually be desirable, and that's what services like github or bitbucket provide.
- Bert -
On 6/25/2010 1:59 PM, Bert Freudenberg wrote:
I really cannot understand your objection.
Yes, I'm obviously doing a bad job formulating my concern :-)
The concern isn't about the utilization of a DVCS. The concern is about people saying "hurray, now we can finally fork". If we're in a situation that people feel that way, then we're doing something wrong and it has nothing to do with the use of a DVCS.
So everyone here explaining to me how great it is to fork is doing nothing but deepening my concern that we have a real problem and that the only outcome of a switch to a DVCS is that we'll end up in a multitude of incompatible forks. Which is what I'm trying to avoid.
Cheers, - Andreas
But andreas if people cannot easily post their contributions then they will leave, or they will fork anyway. This is really simple to clone a svn repository. We were planning to have a github dedicated to vm contributions so that people investing time to get a better make for windows for example can contribute and like that we have no stress that you get busy or not. The VM maintainer can decide if they want it or not. They can cherry pick the changes. But we can also access it and use it and contribute to it. This is like the immutability it even if it is not introduced then having an entry point to find the code is an advantage.
As igor said git is a tool and you can build a process around it.
Stef
On 6/25/2010 1:59 PM, Bert Freudenberg wrote:
I really cannot understand your objection.
Yes, I'm obviously doing a bad job formulating my concern :-)
The concern isn't about the utilization of a DVCS. The concern is about people saying "hurray, now we can finally fork". If we're in a situation that people feel that way, then we're doing something wrong and it has nothing to do with the use of a DVCS.
So everyone here explaining to me how great it is to fork is doing nothing but deepening my concern that we have a real problem and that the only outcome of a switch to a DVCS is that we'll end up in a multitude of incompatible forks. Which is what I'm trying to avoid.
Cheers,
- Andreas
On 26 June 2010 01:18, stephane ducasse stephane.ducasse@gmail.com wrote:
But andreas if people cannot easily post their contributions then they will leave, or they will fork anyway. This is really simple to clone a svn repository. We were planning to have a github dedicated to vm contributions so that people investing time to get a better make for windows for example can contribute and like that we have no stress that you get busy or not.
Oh you also planned to use it? Cool.
I used github for a single project, and frankly i can't say that i learnt to use it well. But from what i have seen, it really helps with organizing a workflow, where you have multiple contributors, each doing experiments in own direction, and then sync the results into a central repository.
It is very easy to track things and don't get lost in the information ocean. http://github.com/couchapp/couchapp/network
The VM maintainer can decide if they want it or not. They can cherry pick the changes. But we can also access it and use it and contribute to it. This is like the immutability it even if it is not introduced then having an entry point to find the code is an advantage.
As igor said git is a tool and you can build a process around it.
Stef
On 6/25/2010 1:59 PM, Bert Freudenberg wrote:
I really cannot understand your objection.
Yes, I'm obviously doing a bad job formulating my concern :-)
The concern isn't about the utilization of a DVCS. The concern is about people saying "hurray, now we can finally fork". If we're in a situation that people feel that way, then we're doing something wrong and it has nothing to do with the use of a DVCS.
So everyone here explaining to me how great it is to fork is doing nothing but deepening my concern that we have a real problem and that the only outcome of a switch to a DVCS is that we'll end up in a multitude of incompatible forks. Which is what I'm trying to avoid.
Cheers, - Andreas
On Jun 26, 2010, at 4:17 AM, Igor Stasenko wrote:
On 26 June 2010 01:18, stephane ducasse stephane.ducasse@gmail.com wrote:
But andreas if people cannot easily post their contributions then they will leave, or they will fork anyway. This is really simple to clone a svn repository. We were planning to have a github dedicated to vm contributions so that people investing time to get a better make for windows for example can contribute and like that we have no stress that you get busy or not.
Oh you also planned to use it? Cool.
yes we decided that at the sprint at brussels after talking with geoffroy.
I used github for a single project, and frankly i can't say that i learnt to use it well.
We have experts around so I have no stress for that.
But from what i have seen, it really helps with organizing a workflow, where you have multiple contributors, each doing experiments in own direction, and then sync the results into a central repository.
It is very easy to track things and don't get lost in the information ocean. http://github.com/couchapp/couchapp/network
The VM maintainer can decide if they want it or not. They can cherry pick the changes. But we can also access it and use it and contribute to it. This is like the immutability it even if it is not introduced then having an entry point to find the code is an advantage.
As igor said git is a tool and you can build a process around it.
Stef
On 6/25/2010 1:59 PM, Bert Freudenberg wrote:
I really cannot understand your objection.
Yes, I'm obviously doing a bad job formulating my concern :-)
The concern isn't about the utilization of a DVCS. The concern is about people saying "hurray, now we can finally fork". If we're in a situation that people feel that way, then we're doing something wrong and it has nothing to do with the use of a DVCS.
So everyone here explaining to me how great it is to fork is doing nothing but deepening my concern that we have a real problem and that the only outcome of a switch to a DVCS is that we'll end up in a multitude of incompatible forks. Which is what I'm trying to avoid.
Cheers,
- Andreas
-- Best regards, Igor Stasenko AKA sig.
On 25/06/2010 23:04, Andreas Raab wrote:
On 6/25/2010 1:59 PM, Bert Freudenberg wrote:
I really cannot understand your objection.
Yes, I'm obviously doing a bad job formulating my concern :-)
The concern isn't about the utilization of a DVCS. The concern is about people saying "hurray, now we can finally fork". If we're in a situation that people feel that way, then we're doing something wrong and it has nothing to do with the use of a DVCS.
To me, it sounds more like "hurray, now we can finally maintain our own private changes without jumping though a bunch of hoops" :)
So everyone here explaining to me how great it is to fork is doing nothing but deepening my concern that we have a real problem and that the only outcome of a switch to a DVCS is that we'll end up in a multitude of incompatible forks. Which is what I'm trying to avoid.
I think the problem is with the use of the word "fork". Isn't a private copy of a repo more akin to a branch?
On 6/25/2010 4:29 PM, Douglas Brebner wrote:
I think the problem is with the use of the word "fork". Isn't a private copy of a repo more akin to a branch?
Well, if that's the case, how about addressing it by using branches? Right here on squeakvm.org? Would this alleviate your perceived need to fork?
Cheers, - Andreas
On 26/06/2010 02:47, Andreas Raab wrote:
On 6/25/2010 4:29 PM, Douglas Brebner wrote:
I think the problem is with the use of the word "fork". Isn't a private copy of a repo more akin to a branch?
Well, if that's the case, how about addressing it by using branches? Right here on squeakvm.org? Would this alleviate your perceived need to fork?
You don't need squeakvm.org commit permissions to use a private clone repo..
My point though, is to think of it not as forking but as (very) private branches for code that, among other things, can be personal, highly experimental, legally problematical or just embarrassingly bad ;)
On 6/25/2010 4:29 PM, Douglas Brebner wrote:
I think the problem is with the use of the word "fork". Isn't a private copy of a repo more akin to a branch?
Well, if that's the case, how about addressing it by using branches? Right here on squeakvm.org? Would this alleviate your perceived need to fork?
Cheers,
- Andreas
This point may not be as relevant to the vm discussion as it might be, but I am not subscribed to the squeak-dev list.
When you decide that forks are not desirable, you force everyone else who doesn't happen to be tracking you on a daily basis, to fork by default. Git/bzr provides a default way of working where you pull working stuff from working forks aka branches. The result, forking works for you, not against you, because you have the tools and the process surrounding the tools which is not afraid of forking.
In git/bzr etc all forks are branches, with common tools for interop between the branches. In squeakland it is different, a fork is a hard- fork, because the tools (MC,sunit) are not common between forks.
Stephane created pharo, and in one day effectively made half of my code base into a fork of pharo, that was difficult to support, and had no way of contributing back into pharo, because pharo's code management tools, and testing tools were different to mine.
Andreas created "trunk", and in one day made the other half of my entire code base into a fork of Squeak, in exactly the same way.
The position of "not desiring forks" is basically unsupportable, because blatantly we have several official forks and hundreds of other images "left behind", with packages in squeaksource for every variant in between.
This is not as painful in other languages, because basically all they need in the way of common tools is a text editor.
In smalltalk, everything moves so fast, once you get to a situation where you are building your stuff on top of other people's stuff, and they are moving their projects forward, you need some coherent strategy to cope, or the whole thing collapses very quickly.
Neither Andreas, nor Stephane appear to be familiar with this problem, perhaps they never build anything on top of other peoples code that they are not in complete control of.
I have a solution for working across forks, my solution uses bzr/ launchpad for scm, and provides much simpler common tools for all forks, and potentially all smalltalks. (no MC in sight). Using my solution I can create and maintain a package in all forks simultaneously, because I have developed a tool set that is designed knowing that I do not have control over what anyone does or what facilities an image will have in it.
I am unsubscribing shortly
regards
Keith
On 26 June 2010 02:29, Douglas Brebner squeaklists@fang.demon.co.uk wrote:
On 25/06/2010 23:04, Andreas Raab wrote:
On 6/25/2010 1:59 PM, Bert Freudenberg wrote:
I really cannot understand your objection.
Yes, I'm obviously doing a bad job formulating my concern :-)
The concern isn't about the utilization of a DVCS. The concern is about people saying "hurray, now we can finally fork". If we're in a situation that people feel that way, then we're doing something wrong and it has nothing to do with the use of a DVCS.
To me, it sounds more like "hurray, now we can finally maintain our own private changes without jumping though a bunch of hoops" :)
I'd say "hurray, we can finally work".
So everyone here explaining to me how great it is to fork is doing nothing but deepening my concern that we have a real problem and that the only outcome of a switch to a DVCS is that we'll end up in a multitude of incompatible forks. Which is what I'm trying to avoid.
I think the problem is with the use of the word "fork". Isn't a private copy of a repo more akin to a branch?
+1 git is like MC. And this is a pity to see code of geoffroy rot or geoffroy leaving while we can learn from his VLC experience.
Stef
On 6/25/2010 1:23 AM, Geoffroy Couprie wrote:
Do we have this problem? What patches do you or anyone else have that can or should not be integrated in the main source?
I have my CMake patches (to be able to build the Windows VM with CMake), and some patches to build the Windows VM with GCC. I sent the patches here 2 months ago (you never answered on that thread), and although people seemed interested by that code, it was never added in the repository. I had to store the CMake patches, and then the other Windows patches, and working on these different pieces of code without being able to commit was painful.
Sorry about this, I've been quite busy with other things (such as the Cog release). The patches itself sound quite reasonable to me and probably should be integrated, no?
BTW, I don't think you've ever asked for commit rights. Regarding cmake, I have no problems giving you access so that you can keep the cmake stuff current.
I also modify the VM for self education/fun purposes, and these modifications would never be accepted in the main tree (heavily breaking large parts of the memory allocations, weird plugins, etc).
But those patches then are just as unlikely to apply to other large changes in the main VM sources. That's a bit my point here. We've basically got two options:
Everyone forks in their own little worlds, creating chaos. We've had that in the past, it did not work AT ALL.
We try to be reasonable and integrate things back into the main sources. Give people who do active development commit rights for the relevant portions. Stay reasoable all along.
I'm *strongly* in favor of the latter.
Cheers,
- Andreas
Maybe you have not developed using a distributed versioning system yet? A DCVS would be for the VM what the trunk process is for the Squeak image. There still would be a "mainline" which is the official source tree. But people could work independently on their changes, and it's really simple to fold changes back, much simpler than in svn.
The reason 1) above did not work is because there was no way to track the changes and fold them back. Maybe read "the forking non-problem" here: http://hgbook.red-bean.com/read/how-did-we-get-here.html
A DCVS allows precisely that tracking and fold-back. You could develop in private, but in practice having a shared repository for all private trees works well. E.g., look at the Sugar repository:
http://git.sugarlabs.org/projects/sugar
There is a "mainline" which several people have commit access to, constituting the official sources. But there are also any number of clones for people's experiments. It's really simple to switch your working copy to one of these personal trees, to test something, and switch back.
The thing is that there is zero barrier to entry - anyone can clone the official tree and start hacking. It's like the inbox.
So I'm strongly in favor of switching to a DCVS. I personally only ever used git, but since hg supposedly has better x-platform support that would be fine too (the Windows devs should speak up). Wouldn't be opposed to bzr either.
- Bert -
On Fri, Jun 25, 2010 at 10:09 AM, Andreas Raab andreas.raab@gmx.de wrote:
On 6/25/2010 1:05 AM, Geoffroy Couprie wrote:
On Fri, Jun 25, 2010 at 9:53 AM, Andreas Raabandreas.raab@gmx.de wrote:
On 6/24/2010 7:16 PM, Igor Stasenko wrote:
One user could create a project, then others may create forks or subforks of his project(s)
How exactly is this a good thing? I don't want 200 forked Squeak VM versions; I want one canonical source that people can build from.
Forks can be really useful for people who have to maintain a set of patches that may not be accepted in the repository (applications requiring a specific VM configuration, servers, etc).
Do we have this problem? What patches do you or anyone else have that can or should not be integrated in the main source?
I for one, really do have this problem. My list of patches now runs to 13 files, totalling 3871 lines.
Note: I'm not blaming the current maintainers; I think they're doing a great job.
It's just that some things never make it into the official tree. Sometimes the maintainers don't accept a patch. Sometimes my employer won't allow me to release a patch to the public. Sometimes I'm too embarrassed by my code to release it.
Whatever the reason, patches are a way of life. We need to find tools and systems to ensure that this life doesn't suck. My vote's for git, not because I particularly "like" it, but because my understanding's that it's the best tool available when it comes to merging and maintaning patches. I 'm told it makes merges and keeping patches up to date as the main trunk diverges, as easy as possible. If there's a better tool, I'm sure someone on the list will correct me!
- Andrew
PS: My experience has been that, when I do post a patch to the list, it's met with silence. I found the lack of feedback (even negative responses) disconcerting. So I no longer try terribly hard to get patches into the tree.
On Fri, Jun 25, 2010 at 10:09 AM, Andreas Raab andreas.raab@gmx.de wrote:
On 6/25/2010 1:05 AM, Geoffroy Couprie wrote:
On Fri, Jun 25, 2010 at 9:53 AM, Andreas Raabandreas.raab@gmx.de wrote:
On 6/24/2010 7:16 PM, Igor Stasenko wrote:
One user could create a project, then others may create forks or subforks of his project(s)
How exactly is this a good thing? I don't want 200 forked Squeak VM versions; I want one canonical source that people can build from.
Forks can be really useful for people who have to maintain a set of patches that may not be accepted in the repository (applications requiring a specific VM configuration, servers, etc).
Do we have this problem? What patches do you or anyone else have that can or should not be integrated in the main source?
While I was trying to build squeak vm for Pharo with FT2Plugin I had to maintain 3 patches long before they were integrated in squeak vm trunk.
With a DVCS it's easier to make collaborative experimentations, try new things, merge the good ones, see popular patches.
That doesn't mean there's no official branch anymore.
Cheers,
Laurent
Cheers,
- Andreas
With the
branching workflows in DVCS, you can still get updates from the main repository, develop new features in parallel, and maintain your patches without impacting the rest of the developers.
With SVN, if you don't have commit access, you only have two possibilities: store a lot of patches, and reapply them by hand at each update, or use a dirty trick like git-svn. I'm using git-svn right now: it is great to be able to commit locally, but it's a bit heavy to use.
This is something I've wanted to say about Squeak for a while now...
Every running image with changes in it is in effect a branch of Squeak. People seem to be asking for distributed SCM solutions (in which every working copy is in effect a branch) for the VM.
Squeak is a self sustaining system: I think one reason to have a self sustaining system is to be able to fork it on whimsy. This will be especially useful for students and folks with crazy ideas that might just work. I think it will also be quite useful for businesses, which is a big part of why I was so enthusiastic about closing the deal on the MIT license.
So I guess what I'm saying is that I think we shouldn't worry at all about forks, and that statement includes not worrying at all about being compatible with forks. If I wanted to fork Squeak (and I do from time to time,) quite frankly, I think it would be unreasonable to expect Squeak to be compatible with my fork; when you fork, you're on your own. Anyone who's ever maintained a fork of something knows this from personal experience.
Now back to SCM. There are some nice wins with Git over Subversion, mostly to do with fast merges and distributed development. In fact I'd like it if we learned some things from Git in our further development of Monticello.
But for the love of God, can we keep Cog in the same repository that we keep the rest of the Squeak VMs? Maybe we switch to Git or Mercurial for managing C sources eventually, but we should do it across the board. Squeak is (from the moment they decided to actually use the Blue Book sources as a starting point) a *reference implementation.* You really don't want more than one of those.
I'm going to pull a total Jack-move and call Godwin's Law on myself in a shameless attempt to kill this subject as quickly as possible: Hitler.
On Jun 25, 2010, at 12:53 AM, Andreas Raab andreas.raab@gmx.de wrote:
On 6/24/2010 7:16 PM, Igor Stasenko wrote:
One user could create a project, then others may create forks or subforks of his project(s)
How exactly is this a good thing? I don't want 200 forked Squeak VM versions; I want one canonical source that people can build from.
Cheers,
- Andreas
On 6/25/2010 1:41 AM, Casey Ransberger wrote:
So I guess what I'm saying is that I think we shouldn't worry at all about forks, and that statement includes not worrying at all about being compatible with forks. If I wanted to fork Squeak (and I do from time to time,) quite frankly, I think it would be unreasonable to expect Squeak to be compatible with my fork; when you fork, you're on your own. Anyone who's ever maintained a fork of something knows this from personal experience.
Now back to SCM. There are some nice wins with Git over Subversion, mostly to do with fast merges and distributed development. In fact I'd like it if we learned some things from Git in our further development of Monticello.
I agree with merging (the only argument that carries any weight here). I don't buy the forking argument. The number of people building VMs is *tiny* compared to general Squeak users. Having those fork instead of pool their resources is an absolutely deadly fallacy. As a consequence, I think that it's a Very Good Thing (tm) having to pay a price for forking. It should be easier to contribute back to main line sources than to fork.
But for the love of God, can we keep Cog in the same repository that we keep the rest of the Squeak VMs? Maybe we switch to Git or Mercurial for managing C sources eventually, but we should do it across the board. Squeak is (from the moment they decided to actually use the Blue Book sources as a starting point) a *reference implementation.* You really don't want more than one of those.
Absolutely. Eliot's initial point was exactly that, i.e., decouple the discussion about a change in SCM from having a Cog branch. I don't think anyone is arguing that point.
I'm going to pull a total Jack-move and call Godwin's Law on myself in a shameless attempt to kill this subject as quickly as possible: Hitler.
:-)
Cheers, - Andreas
On Fri, Jun 25, 2010 at 10:56 AM, Andreas Raab andreas.raab@gmx.de wrote:
On 6/25/2010 1:41 AM, Casey Ransberger wrote:
So I guess what I'm saying is that I think we shouldn't worry at all about forks, and that statement includes not worrying at all about being compatible with forks. If I wanted to fork Squeak (and I do from time to time,) quite frankly, I think it would be unreasonable to expect Squeak to be compatible with my fork; when you fork, you're on your own. Anyone who's ever maintained a fork of something knows this from personal experience.
Now back to SCM. There are some nice wins with Git over Subversion, mostly to do with fast merges and distributed development. In fact I'd like it if we learned some things from Git in our further development of Monticello.
I agree with merging (the only argument that carries any weight here). I don't buy the forking argument. The number of people building VMs is *tiny* compared to general Squeak users. Having those fork instead of pool their resources is an absolutely deadly fallacy. As a consequence, I think that it's a Very Good Thing (tm) having to pay a price for forking. It should be easier to contribute back to main line sources than to fork.
I try an argument.
Now vm-dev team uses SVN, and there's forks. But you don't know it. They may be wonderful patches, they're lost on people hard disks.
With a DVCS there will be forks too. But you know it, you can track it, others can try it and say "hey this is cool, it works, merge it please !".
IMHO it's really important that fork is easy. Look at the Linux kernel, it's wonderful.
Laurent
But for the love of God, can we keep Cog in the same repository that we
keep the rest of the Squeak VMs? Maybe we switch to Git or Mercurial for managing C sources eventually, but we should do it across the board. Squeak is (from the moment they decided to actually use the Blue Book sources as a starting point) a *reference implementation.* You really don't want more than one of those.
Absolutely. Eliot's initial point was exactly that, i.e., decouple the discussion about a change in SCM from having a Cog branch. I don't think anyone is arguing that point.
I'm going to pull a total Jack-move and call Godwin's Law on myself in a
shameless attempt to kill this subject as quickly as possible: Hitler.
:-)
Cheers,
- Andreas
On 25 June 2010 12:29, laurent laffont laurent.laffont@gmail.com wrote:
On Fri, Jun 25, 2010 at 10:56 AM, Andreas Raab andreas.raab@gmx.de wrote:
On 6/25/2010 1:41 AM, Casey Ransberger wrote:
So I guess what I'm saying is that I think we shouldn't worry at all about forks, and that statement includes not worrying at all about being compatible with forks. If I wanted to fork Squeak (and I do from time to time,) quite frankly, I think it would be unreasonable to expect Squeak to be compatible with my fork; when you fork, you're on your own. Anyone who's ever maintained a fork of something knows this from personal experience.
Now back to SCM. There are some nice wins with Git over Subversion, mostly to do with fast merges and distributed development. In fact I'd like it if we learned some things from Git in our further development of Monticello.
I agree with merging (the only argument that carries any weight here). I don't buy the forking argument. The number of people building VMs is *tiny* compared to general Squeak users. Having those fork instead of pool their resources is an absolutely deadly fallacy. As a consequence, I think that it's a Very Good Thing (tm) having to pay a price for forking. It should be easier to contribute back to main line sources than to fork.
I try an argument. Now vm-dev team uses SVN, and there's forks. But you don't know it. They may be wonderful patches, they're lost on people hard disks. With a DVCS there will be forks too. But you know it, you can track it, others can try it and say "hey this is cool, it works, merge it please !". IMHO it's really important that fork is easy. Look at the Linux kernel, it's wonderful.
This is exactly why i proposed to use github. Because with it, its very easy to merge the changes between forks. But what is most important - nothing is lost.
Laurent
But for the love of God, can we keep Cog in the same repository that we keep the rest of the Squeak VMs? Maybe we switch to Git or Mercurial for managing C sources eventually, but we should do it across the board. Squeak is (from the moment they decided to actually use the Blue Book sources as a starting point) a *reference implementation.* You really don't want more than one of those.
Absolutely. Eliot's initial point was exactly that, i.e., decouple the discussion about a change in SCM from having a Cog branch. I don't think anyone is arguing that point.
I'm going to pull a total Jack-move and call Godwin's Law on myself in a shameless attempt to kill this subject as quickly as possible: Hitler.
:-)
Cheers, - Andreas
On Jun 25, 2010, at 1:56 AM, Andreas Raab andreas.raab@gmx.de wrote:
But for the love of God, can we keep Cog in the same repository that we keep the rest of the Squeak VMs? Maybe we switch to Git or Mercurial for managing C sources eventually, but we should do it across the board. Squeak is (from the moment they decided to actually use the Blue Book sources as a starting point) a *reference implementation.* You really don't want more than one of those.
Absolutely. Eliot's initial point was exactly that, i.e., decouple the discussion about a change in SCM from having a Cog branch. I don't think anyone is arguing that point.
Oh! I must have missed that part. Oops, that's embarrassing. If we're actually talking about migrating the sources out of SVN, why then I think I'm ambivalent about the whole thing:) Git was fun to work with, but I'm not really sure switching is worth the effort. It winds up being kind of a pain in the ass to get all of the bits out of the one repository and into the other, so it will really be a watershed event if we decide to do it.
I seriously need to drop this topic though, as I've violated Godwin's Law just by sending this message, and I hear they'll judge you in the hall of Osiris if you pull crap like that on a regular basis!
On Fri, Jun 25, 2010 at 3:26 AM, Josh Gargus josh@schwa.ca wrote:
On Jun 24, 2010, at 5:17 PM, Igor Stasenko wrote:
Does Mercurial provides an infrastructure like github?
Google Code hosting supports Mercurial. I'm not sure specifically what infrastructure you're talking about; does Google Code meet your needs?
There's http://bitbucket.org/ for Mercurial.
The free account may not be enough, see http://bitbucket.org/plans
"Integration with Lighthouse, Twitter, FogBugz, Basecamp, CIA.vc and more is included with all plans."
Cheers,
Laurent Laffont
http://pharocasts.blogspot.com/ http://magaloma.blogspot.com/
I mean, if it doesn't , then it is nothing better than svn (the fact that i could have a full copy of repository locally doesn't much matters). I really don't care what version control system used as a backend, i care about infrastructure around it. On a github its ultimately easy to get started and make own fork(s) of existing projects,
Not sure how well Google Code meets that need. Anyone?
Cheers, Josh
and moreover, all such things are tracked, not just sources. So, users could see how much forks there, and could navigate through them etc etc. The fancy & clever diff/merge etc things is cool, but used seldom, because 99% of times you just doing edit/commit.
On 25 June 2010 02:46, Josh Gargus josh@schwa.ca wrote:
+1 Mercurial, -1 Git. Cheers, Josh
On Jun 24, 2010, at 3:43 PM, Eliot Miranda wrote:
On Thu, Jun 24, 2010 at 8:13 AM, Igor Stasenko siguctua@gmail.com
wrote:
Eliot, how about using github for it?
I think that's great for the whole Squeak VM not just Cog. I'm not
doing this now because I think Cog should live with the rest of the Squeak VM. Let's start a separate discussion on whether we should move http://squeakvm.org/svn/squeak to github, or at least to git with a home on machines we control..
It would be much convenient for use, since it supports branching and no need for someone to be added to 'official' list of contributors in order to push own patches. Anyone could make own fork at any time, and at any time, a core developer could backport the changes into official repository. I think github model is very good for community development. Then i, for instance, could push my own changes into my branch, and it will be easy to track, exchange and port the code between forks and official repository.
Agreed. Git and/or Mercurial is much better than svn. best Eliot
On 23 June 2010 21:48, Eliot Miranda eliot.miranda@gmail.com wrote:
Hi All, I need to be able to push fixes to Cog into general circulation
and for this I'd like to maintain a Cog branch in the Subversion tree. But how do I get permission and/or credentials? What's the process to add me to those allowed to write to the repository? Or is there simply a secret username and password that's told to a few? If the later can some kind soul let me have the password. I faithfully promise not to abuse the privilege.
best Eliot
-- Best regards, Igor Stasenko AKA sig.
-- Best regards, Igor Stasenko AKA sig.
vm-dev@lists.squeakfoundation.org
-
Andreas Raab -
Andrew Gaylard -
Bert Freudenberg -
Casey Ransberger -
David T. Lewis -
Douglas Brebner -
Eliot Miranda -
Frank Shearar -
Geoffroy Couprie -
Henrik Johansen -
Igor Stasenko -
Javier Pimás -
Josh Gargus -
Juan Vuletich -
keith -
laurent laffont -
stephane ducasse