a Cog branch
Locked
123
123
 
|
On Fri, Jun 25, 2010 at 10:09 AM, Andreas Raab <[hidden email]> wrote:
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
|
|
|
In reply to this post by Geoffroy Couprie
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 |
Forks (Re: [Vm-dev] a Cog branch)
|
|
In reply to this post by Andreas.Raab
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 <[hidden email]> 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 |
Re: Forks (Re: [Vm-dev] a Cog branch)
|
|
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 |
|
|
In reply to this post by Andreas.Raab
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: > > 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 - |
Re: Forks (Re: [Vm-dev] a Cog branch)
|
|
In reply to this post by Andreas.Raab
On Fri, Jun 25, 2010 at 10:56 AM, Andreas Raab <[hidden email]> wrote:
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
|
Re: Forks (Re: [Vm-dev] a Cog branch)
|
|
In reply to this post by Andreas.Raab
On Jun 25, 2010, at 1:56 AM, Andreas Raab <[hidden email]> 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! |
|
|
In reply to this post by Bert Freudenberg
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: >> >> 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. 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 |
|
|
In reply to this post by Bert Freudenberg
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 |
Re: Forks (Re: [Vm-dev] a Cog branch)
|
|
In reply to this post by laurent laffont
On 25 June 2010 12:29, laurent laffont <[hidden email]> wrote: > > > On Fri, Jun 25, 2010 at 10:56 AM, Andreas Raab <[hidden email]> 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 > > > -- Best regards, Igor Stasenko AKA sig. |
|
|
In reply to this post by David T. Lewis
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. |
|
|
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 |
|
|
In reply to this post by David T. Lewis
On Fri, Jun 25, 2010 at 2:14 PM, David T. Lewis <[hidden email]> wrote:
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 |
|
|
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 <[hidden email]> wrote:
-- Javier Pimás Ciudad de Buenos Aires |
|
|
In reply to this post by Bert Freudenberg
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 <[hidden email]> wrote:
Why ? Laurent
|
|
|
In reply to this post by Andreas.Raab
On 25 June 2010 22:11, Andreas Raab <[hidden email]> 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. > 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. |
|
|
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 <[hidden email]> wrote: > On 25 June 2010 22:11, Andreas Raab <[hidden email]> 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. > -- Best regards, Igor Stasenko AKA sig. |
|
|
In reply to this post by Andreas.Raab
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 |
«
Return to Squeak VM
|
1 view|%1 views
| Free forum by Nabble | Edit this page |