a Cog branch
Locked
123
123
 
|
+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: >> >> 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 > > 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 - > |
|
|
In reply to this post by Andreas.Raab
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 |
|
|
In reply to this post by Andreas.Raab
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 ;) |
|
|
In reply to this post by stephane ducasse-2
On 26 June 2010 01:18, stephane ducasse <[hidden email]> 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 > > -- Best regards, Igor Stasenko AKA sig. |
|
|
In reply to this post by Douglas Brebner
On 26 June 2010 02:29, Douglas Brebner <[hidden email]> 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" :) > "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? > -- Best regards, Igor Stasenko AKA sig. |
|
|
In reply to this post by Andreas.Raab
> 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 |
|
|
In reply to this post by Igor Stasenko
On Jun 26, 2010, at 4:17 AM, Igor Stasenko wrote: > > On 26 June 2010 01:18, stephane ducasse <[hidden email]> 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. |
«
Return to Squeak VM
|
1 view|%1 views
| Free forum by Nabble | Edit this page |