VM Automated builds update
Locked
12
12
Re: VM Automated builds update
 
|
On Wed, Mar 16, 2011 at 3:49 AM, David T. Lewis <[hidden email]> wrote: > > On Tue, Mar 15, 2011 at 09:22:27PM +0100, Igor Stasenko wrote: >> >> On 15 March 2011 17:35, Levente Uzonyi <[hidden email]> wrote: >> > >> > On Tue, 15 Mar 2011, Igor Stasenko wrote: >> > >> >> >> >>> >> >>> The main functional differences between SqueakVM and StackVM are: >> >>> - StackVM requires 6505 images (maybe 6504, i'm not sure) while SqueakVM >> >>> can >> >>> execute 6502, 6504 and 6505 images. >> >> >> >> not a big deal. I think everyone aware that Cog using newer image >> >> version(s). >> > >> > Not a big deal, for you. >> > >> > Someone just mentioned, that they're using 3.10-4 VM on Solaris, so they >> > don't use newer image versions. We also have some Squeak 3.9 images deployed >> > and we're not planning to upgrade them yet. The latest Etoys and Cobalt >> > releases use the old image format. >> > >> >> Well, if people decided to stick with old images, it is their choice. >> And once they decide to migrate, >> then there is a way to do that. I see nothing complicated there. >> >> Either you stay with old MS-DOS, and run your application using DosBox , or >> you run it on x64 compiled using modern compiler. The choice is always yours :) >> > > For whatever it may be worth, I intend to continue supporting the traditional > interpreter VM to the best of my ability for the forseeable future. I also > intend to help as best I can to support Cog and hopefully to help merge > code bases and reduce redundancy where possible. Finally, I think that the > work Igor is doing for automated builds is very valuable. > > Let's be glad for the progress that is being made with new VMs and new > build processes, but please do not assume that this progress comes at > the expense of all that has come before. It just ain't so. Igor, sorry if my question triggered a mini-flamefest. That wasn't my intention! I was just wondering what the "general direction" of VM development currently is. You answered it clearly. Since we have an automated process that builds images from scratch, and since we never store what we can generate (sound familiar! :), it's not a big deal for us to migrate to a new format. Also, I'm really grateful for the work you've done to make builds repeatable and automated. For years now, VM development has been plagued with "it works when *I* build it, so it must be fine"-type of issues. Your efforts will go a long way to industrialise the VM development and bug-fixing process. Many thanks, - Andrew |
|
|
On 16 March 2011 09:44, Andrew Gaylard <[hidden email]> wrote: > > On Wed, Mar 16, 2011 at 3:49 AM, David T. Lewis <[hidden email]> wrote: >> >> On Tue, Mar 15, 2011 at 09:22:27PM +0100, Igor Stasenko wrote: >>> >>> On 15 March 2011 17:35, Levente Uzonyi <[hidden email]> wrote: >>> > >>> > On Tue, 15 Mar 2011, Igor Stasenko wrote: >>> > >>> >> >>> >>> >>> >>> The main functional differences between SqueakVM and StackVM are: >>> >>> - StackVM requires 6505 images (maybe 6504, i'm not sure) while SqueakVM >>> >>> can >>> >>> execute 6502, 6504 and 6505 images. >>> >> >>> >> not a big deal. I think everyone aware that Cog using newer image >>> >> version(s). >>> > >>> > Not a big deal, for you. >>> > >>> > Someone just mentioned, that they're using 3.10-4 VM on Solaris, so they >>> > don't use newer image versions. We also have some Squeak 3.9 images deployed >>> > and we're not planning to upgrade them yet. The latest Etoys and Cobalt >>> > releases use the old image format. >>> > >>> >>> Well, if people decided to stick with old images, it is their choice. >>> And once they decide to migrate, >>> then there is a way to do that. I see nothing complicated there. >>> >>> Either you stay with old MS-DOS, and run your application using DosBox , or >>> you run it on x64 compiled using modern compiler. The choice is always yours :) >>> >> >> For whatever it may be worth, I intend to continue supporting the traditional >> interpreter VM to the best of my ability for the forseeable future. I also >> intend to help as best I can to support Cog and hopefully to help merge >> code bases and reduce redundancy where possible. Finally, I think that the >> work Igor is doing for automated builds is very valuable. >> >> Let's be glad for the progress that is being made with new VMs and new >> build processes, but please do not assume that this progress comes at >> the expense of all that has come before. It just ain't so. > > Igor, sorry if my question triggered a mini-flamefest. That wasn't my > intention! I was just wondering what the "general direction" of VM > development currently is. You answered it clearly. Since we have an > automated process that builds images from scratch, and since we > never store what we can generate (sound familiar! :), it's not a big > deal for us to migrate to a new format. > Right , that the idea. Different groups of people developing different things: - VM - kernel image - 3rd party packages - end-user applications and in order to meet them all, all players in field should be mobile, and all pieces of puzzle should be replaceable at any moment. Then you can move forward and exploit the new features done by another party. > Also, I'm really grateful for the work you've done to make builds > repeatable and automated. For years now, VM development has > been plagued with "it works when *I* build it, so it must be fine"-type > of issues. Your efforts will go a long way to industrialise the VM > development and bug-fixing process. > > Many thanks, > - Andrew > -- Best regards, Igor Stasenko AKA sig. |
|
|
In reply to this post by David T. Lewis
On 16 March 2011 02:49, David T. Lewis <[hidden email]> wrote: > > On Tue, Mar 15, 2011 at 09:22:27PM +0100, Igor Stasenko wrote: >> >> On 15 March 2011 17:35, Levente Uzonyi <[hidden email]> wrote: >> > >> > On Tue, 15 Mar 2011, Igor Stasenko wrote: >> > >> >> >> >>> >> >>> The main functional differences between SqueakVM and StackVM are: >> >>> - StackVM requires 6505 images (maybe 6504, i'm not sure) while SqueakVM >> >>> can >> >>> execute 6502, 6504 and 6505 images. >> >> >> >> not a big deal. I think everyone aware that Cog using newer image >> >> version(s). >> > >> > Not a big deal, for you. >> > >> > Someone just mentioned, that they're using 3.10-4 VM on Solaris, so they >> > don't use newer image versions. We also have some Squeak 3.9 images deployed >> > and we're not planning to upgrade them yet. The latest Etoys and Cobalt >> > releases use the old image format. >> > >> >> Well, if people decided to stick with old images, it is their choice. >> And once they decide to migrate, >> then there is a way to do that. I see nothing complicated there. >> >> Either you stay with old MS-DOS, and run your application using DosBox , or >> you run it on x64 compiled using modern compiler. The choice is always yours :) >> > > For whatever it may be worth, I intend to continue supporting the traditional > interpreter VM to the best of my ability for the forseeable future. I also > intend to help as best I can to support Cog and hopefully to help merge > code bases and reduce redundancy where possible. Finally, I think that the > work Igor is doing for automated builds is very valuable. > > Let's be glad for the progress that is being made with new VMs and new > build processes, but please do not assume that this progress comes at > the expense of all that has come before. It just ain't so. > Dave, i didn't meant that it should be dropped immediately. If we want to migrate to Cog, someone has to make sure that things which worked in old VM, working in Cog as well. And apparently Eliot can't do it alone. And in terms of building infrastructure for VMs, it will make the whole process more controllable and predictable. And again, if any of you want to add the cmake configs into CMakeVMMaker which can be used to build traditional VMs, feel free to do that. Because i don't have a time to do that, it doesn't means that i am against it. > $0.02, > > Dave > > -- Best regards, Igor Stasenko AKA sig. |
Re: VM Automated builds update
|
|
In reply to this post by Igor Stasenko
On Wed, Mar 16, 2011 at 8:14 AM, Igor Stasenko <[hidden email]> wrote:
Sorry, I don't agree ;). It's not easy to replace people, and I don't like that idea, hehe. I can't find an Igor Stasenko everyday everywhere! Cheers, Guille Then you can move forward and exploit the new features done by another party. |
Re: VM Automated builds update
|
|
In reply to this post by Igor Stasenko
On Wed, Mar 16, 2011 at 12:54:51PM +0100, Igor Stasenko wrote: > > On 16 March 2011 02:49, David T. Lewis <[hidden email]> wrote: > > > > On Tue, Mar 15, 2011 at 09:22:27PM +0100, Igor Stasenko wrote: > >> > >> On 15 March 2011 17:35, Levente Uzonyi <[hidden email]> wrote: > >> > > >> > On Tue, 15 Mar 2011, Igor Stasenko wrote: > >> > > >> >> > >> >>> > >> >>> The main functional differences between SqueakVM and StackVM are: > >> >>> - StackVM requires 6505 images (maybe 6504, i'm not sure) while SqueakVM > >> >>> can > >> >>> execute 6502, 6504 and 6505 images. > >> >> > >> >> not a big deal. I think everyone aware that Cog using newer image > >> >> version(s). > >> > > >> > Not a big deal, for you. > >> > > >> > Someone just mentioned, that they're using 3.10-4 VM on Solaris, so they > >> > don't use newer image versions. We also have some Squeak 3.9 images deployed > >> > and we're not planning to upgrade them yet. The latest Etoys and Cobalt > >> > releases use the old image format. > >> > > >> > >> Well, if people decided to stick with old images, it is their choice. > >> And once they decide to migrate, > >> then there is a way to do that. I see nothing complicated there. > >> > >> Either you stay with old MS-DOS, and run your application using DosBox , or > >> you run it on x64 compiled using modern compiler. The choice is always yours :) > >> > > > > For whatever it may be worth, I intend to continue supporting the traditional > > interpreter VM to the best of my ability for the forseeable future. I also > > intend to help as best I can to support Cog and hopefully to help merge > > code bases and reduce redundancy where possible. Finally, I think that the > > work Igor is doing for automated builds is very valuable. > > > > Let's be glad for the progress that is being made with new VMs and new > > build processes, but please do not assume that this progress comes at > > the expense of all that has come before. It just ain't so. > > > > Dave, i didn't meant that it should be dropped immediately. > If we want to migrate to Cog, someone has to make sure that things > which worked in old VM, > working in Cog as well. And apparently Eliot can't do it alone. > And in terms of building infrastructure for VMs, it will make the > whole process more controllable and > predictable. Agreed :) I just wanted to reassure folks who might have been concerned that the standard VM would be neglected. That will not happen. > And again, if any of you want to add the cmake configs into > CMakeVMMaker which can be used to build > traditional VMs, feel free to do that. Because i don't have a time to > do that, it doesn't means that i am against it. I also have limited time of course, and that does not mean I am against progress ;) Dave |
Re: VM Automated builds update
|
|
>> Dave, i didn't meant that it should be dropped immediately. >> If we want to migrate to Cog, someone has to make sure that things >> which worked in old VM, >> working in Cog as well. And apparently Eliot can't do it alone. >> And in terms of building infrastructure for VMs, it will make the >> whole process more controllable and >> predictable. + 1 > Agreed :) I just wanted to reassure folks who might have been concerned > that the standard VM would be neglected. That will not happen. > >> And again, if any of you want to add the cmake configs into >> CMakeVMMaker which can be used to build >> traditional VMs, feel free to do that. Because i don't have a time to >> do that, it doesn't means that i am against it. > > I also have limited time of course, and that does not mean I am > against progress ;) Excellent. We are for positive energy and making sure people can invent their own future. One of the key question/challenge I have for myself simple: what should we do so that the next avi briant will pick Smalltalk and not X/Z/K to build the future? Stef |
Re: VM Automated builds update
|
|
In reply to this post by stephane ducasse-2
Hi Stef, On Tue, 15 Mar 2011, stephane ducasse wrote: > > Hi Levente > > Well we could have build an infrastructure only for pharo and do not share it but this is not the case. > You can freely use the three months of effort of igor (payed for pharo indeed) to build an automatic build server. > All the vms produced on the build server are also freely accessible. So people wanting CogVM can just use them. > > Noticed also that the infrastructure will make > - building VMs after every single commit (no need to wait several months for one new vms) so high availability of recent vms > - helping vm developers to improve the reproduction of bugs and regression > - engaging the community to really invest in the vms and contribute. > > Notice also that what igor is doing is open, everybody can clone and contribute. That's all nice and great as long as it serves everyone's needs. Levente > > Stef |
|
|
Levente, On 16/03/2011 20:45, Levente Uzonyi wrote: > > Hi Stef, > > On Tue, 15 Mar 2011, stephane ducasse wrote: > >> Notice also that what igor is doing is open, everybody can clone and >> contribute. > > That's all nice and great as long as it serves everyone's needs. > doesn't meet your needs, you've got everything you need (except possibly the skills - not a dig, I don't know) to clone and extend it so that it does, and then contribute back your extensions. Regards, Steve -- You can follow me on twitter at http://twitter.com/smalltalkhacker |
Re: VM Automated builds update
|
|
Quoting Steve Rees <[hidden email]>: > > Levente, > > On 16/03/2011 20:45, Levente Uzonyi wrote: >> >> Hi Stef, >> >> On Tue, 15 Mar 2011, stephane ducasse wrote: >> >>> Notice also that what igor is doing is open, everybody can clone >>> and contribute. >> >> That's all nice and great as long as it serves everyone's needs. >> > Actually, the fact that it is open and cloneable, means that if it > doesn't meet your needs, you've got everything you need (except > possibly the skills - not a dig, I don't know) to clone and extend > it so that it does, and then contribute back your extensions. You only quoted the last sentence of Stephane's mail, read the rest of it to get my point. Also take into account that there's an existing infrastructure used by VM developers and the announcement of the new infrastructure didn't get a warm welcome from them. Levente > > Regards, Steve > > -- > You can follow me on twitter at http://twitter.com/smalltalkhacker > > |
|
|
On 17 March 2011 03:24, Levente Uzonyi <[hidden email]> wrote: > > > Quoting Steve Rees <[hidden email]>: > >> >> Levente, >> >> On 16/03/2011 20:45, Levente Uzonyi wrote: >>> >>> Hi Stef, >>> >>> On Tue, 15 Mar 2011, stephane ducasse wrote: >>> >>>> Notice also that what igor is doing is open, everybody can clone and >>>> contribute. >>> >>> That's all nice and great as long as it serves everyone's needs. >>> >> Actually, the fact that it is open and cloneable, means that if it doesn't >> meet your needs, you've got everything you need (except possibly the skills >> - not a dig, I don't know) to clone and extend it so that it does, and then >> contribute back your extensions. > > You only quoted the last sentence of Stephane's mail, read the rest of it to > get my point. > Also take into account that there's an existing infrastructure used by VM > developers and > the announcement of the new infrastructure didn't get a warm welcome from > them. > Levente, take a look at http://gitorious.org/cogvm there is already 21 personal clone of it.. so, 21 clone is not warm enough for you, heh? Okay.. lets wait for 50 then.. > > Levente > -- Best regards, Igor Stasenko AKA sig. |
Re: VM Automated builds update
|
|
Quoting Igor Stasenko <[hidden email]>: > > On 17 March 2011 03:24, Levente Uzonyi <[hidden email]> wrote: >> >> >> Quoting Steve Rees <[hidden email]>: >> >>> >>> Levente, >>> >>> On 16/03/2011 20:45, Levente Uzonyi wrote: >>>> >>>> Hi Stef, >>>> >>>> On Tue, 15 Mar 2011, stephane ducasse wrote: >>>> >>>>> Notice also that what igor is doing is open, everybody can clone and >>>>> contribute. >>>> >>>> That's all nice and great as long as it serves everyone's needs. >>>> >>> Actually, the fact that it is open and cloneable, means that if it doesn't >>> meet your needs, you've got everything you need (except possibly the skills >>> - not a dig, I don't know) to clone and extend it so that it does, and then >>> contribute back your extensions. >> >> You only quoted the last sentence of Stephane's mail, read the rest of it to >> get my point. >> Also take into account that there's an existing infrastructure used by VM >> developers and >> the announcement of the new infrastructure didn't get a warm welcome from >> them. >> > > Levente, take a look at > http://gitorious.org/cogvm > there is already > 21 personal clone of it.. > > so, 21 clone is not warm enough for you, heh? > Okay.. lets wait for 50 then.. Okay, let's make it clear: I was talking about those people who were developing the VM for years. Also "playing" with the numbers is a bad idea. Most clones were done during the Deep into Smalltalk school by the students. Levente > > >> >> Levente >> > > -- > Best regards, > Igor Stasenko AKA sig. > |
Re: VM Automated builds update
|
|
In reply to this post by Levente Uzonyi-2
Dear levente >>>> >> Actually, the fact that it is open and cloneable, means that if it doesn't meet your needs, you've got everything you need (except possibly the skills - not a dig, I don't know) to clone and extend it so that it does, and then contribute back your extensions. > > You only quoted the last sentence of Stephane's mail, read the rest of it to get my point. > Also take into account that there's an existing infrastructure used by VM developers and > the announcement of the new infrastructure didn't get a warm welcome from them. You can continue to bash us saying that we are nasty newbies. Right now we are building an **open** and welcoming architecture to sustain real open development VMs. This is ok that you do not like it, this is ok too that you bash us. If this helps you feel better I cannot do much about it. We want VMs to be maintained not just a small (tiny, microscopic) club of people that may be distracted/not willing to communicate/not have the time to build a vms. We want to make sure that if a guy has time to improve a vm he will not get frustrated because of millions of stupid details: this is what is called software engineering (vs. handcraft). Having a solid automated process is the key to progress in constraints resources. We want to minimize risk for business. Also we want to send a clear message to smart C, assembler people that lurk at our technology: they are welcome to participate and help because the architecture is open. They do not have to ask for a blessing (knights period is over). They can clone, hack and push/share changes and people can cherry pick the changes without having to have the permissions to publish. For example, igor sent a fix for the Windows vm for the semaphore input more than a year ago and it was never integrated. I'm happy that igor decided to stay in our community. Now we can ask ourselves (lot of people don't and after complain that smalltalk is a dead language) how many people came and left. Sharing is key. Now we will have a Windows VM built everyday (this is a fresh news ;) and more than 8 years I'm dreaming about that. And all the community will be able to use it, if they want. Nobody forces you to use our infrastructure but there will be a lot of advantages. It is free and maintained. We want to make sure that if people with ideas get in contact with our technology, their venture capitalists do not ask simple and naive questions such as - do you have a process - how do you control your quality - what happens if the Unix/windows guys breaks his legs or fly to mars and come to the conclusion that the risk is too high and ask to develop everything in Java. We are thinking and working hard to build a company around moose http://www.moosetechnology.org/ and we do not want to be forced to rewrite everything in Java as this happens a lot around us. May be you do not know everything at this level.... Stef |
|
|
In reply to this post by stephane ducasse-2
On Tue, Mar 15, 2011 at 07:38:29PM +0100, stephane ducasse wrote: > Noticed also that the infrastructure will make > - building VMs after every single commit (no need to wait several months for one new vms) so high availability of recent vms > - helping vm developers to improve the reproduction of bugs and regression > - engaging the community to really invest in the vms and contribute. I already love Hudson. I'm no VM dev and have no interest in becoming one unless all the existing ones go away. I tried a Hudson build against cobalt, found a bug, reported it, and igor fixed it, and hudson built it. Total turnaround time from bug report to working VM: 1.5 hours 1.5 hours is way better than 1 week to a year to see if a bug is fixed in the VM fixed, and have to keep using the ancient cobalt 3.8 VM in the interim In my humble opinion, 1.5 hours is much less than one year -- Matthew Fulmer (a.k.a. Tapple) |
|
|
In reply to this post by Levente Uzonyi-2
On 3/16/2011 19:48, Levente Uzonyi wrote: > Okay, let's make it clear: I was talking about those people who were > developing > the VM for years. Don't worry about it. Igor is a good steward and fortunate enough that he can work on this stuff full time. My own priorities have significantly changed and I am simply not spending much time on Squeak anymore. Also, this development was inevitable in the long term - any person or group who has done significant Squeak development has always had their own VM build setup, so none of this should come as a surprise. Cheers, - Andreas > > Also "playing" with the numbers is a bad idea. Most clones were done > during the > Deep into Smalltalk school by the students. > > > Levente > >> >> >>> >>> Levente >>> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> > > > > > |
Re: VM Automated builds update
|
|
In reply to this post by stephane ducasse-2
On Thu, 17 Mar 2011, stephane ducasse wrote: > > Dear levente > >>>>> >>> Actually, the fact that it is open and cloneable, means that if it doesn't meet your needs, you've got everything you need (except possibly the skills - not a dig, I don't know) to clone and extend it so that it does, and then contribute back your extensions. >> >> You only quoted the last sentence of Stephane's mail, read the rest of it to get my point. >> Also take into account that there's an existing infrastructure used by VM developers and >> the announcement of the new infrastructure didn't get a warm welcome from them. > > You can continue to bash us saying that we are nasty newbies. Right now we are building an **open** and welcoming architecture > to sustain real open development VMs. This is ok that you do not like it, this is ok too that you bash us. If this helps you feel better > I cannot do much about it. Did I bash you? No, I said it's "nice and great". > > We want VMs to be maintained not just a small (tiny, microscopic) club of people that may be > distracted/not willing to communicate/not have the time to build a vms. We want to make sure that if a guy has time to improve a vm he will not get frustrated because of millions of stupid details: this is what is called software engineering (vs. handcraft). Having a solid automated process is the key to progress in constraints resources. We want to minimize risk for business. Great. > > Also we want to send a clear message to smart C, assembler people that lurk at our technology: they are welcome to participate and help > because the architecture is open. They do not have to ask for a blessing (knights period is over). They can clone, hack and push/share changes and people can cherry pick the changes without having to have the permissions to publish. That sounds good, but it may not be true. Do you mean that there won't be official VM releases anymore? Or if there will be, then who will decide which changes/features will be included in those? > > For example, igor sent a fix for the Windows vm for the semaphore input more than a year ago and it was never integrated. Yeah, that's annoying, I had the same experience earlier. > I'm happy that igor decided to stay in our community. Now we can ask ourselves (lot of people don't and after complain that smalltalk is a dead language) how many people came and left. Sharing is key. > > Now we will have a Windows VM built everyday (this is a fresh news ;) and more than 8 years I'm dreaming about that. > And all the community will be able to use it, if they want. Nobody forces you to use our infrastructure but there will be a lot of advantages. It is free and maintained. Great. > > We want to make sure that if people with ideas get in contact with our technology, their venture capitalists do not ask simple and naive questions such as > - do you have a process > - how do you control your quality > - what happens if the Unix/windows guys breaks his legs or fly to mars > and come to the conclusion that the risk is too high and ask to develop everything in Java. > > We are thinking and working hard to build a company around moose http://www.moosetechnology.org/ and we do not want to be forced to rewrite everything in Java as this happens a lot around us. May be you do not know everything at this level.... Which level? Levente > > Stef |
Re: VM Automated builds update
|
|
>>>>>> >> You can continue to bash us saying that we are nasty newbies. Right now we are building an **open** and welcoming architecture >> to sustain real open development VMs. This is ok that you do not like it, this is ok too that you bash us. If this helps you feel better >> I cannot do much about it. > > Did I bash you? No, I said it's "nice and great". Excellent then :) > >> >> We want VMs to be maintained not just a small (tiny, microscopic) club of people that may be >> distracted/not willing to communicate/not have the time to build a vms. We want to make sure that if a guy has time to improve a vm he will not get frustrated because of millions of stupid details: this is what is called software engineering (vs. handcraft). Having a solid automated process is the key to progress in constraints resources. We want to minimize risk for business. > > Great. > >> >> Also we want to send a clear message to smart C, assembler people that lurk at our technology: they are welcome to participate and help >> because the architecture is open. They do not have to ask for a blessing (knights period is over). They can clone, hack and push/share changes and people can cherry pick the changes without having to have the permissions to publish. > > That sounds good, but it may not be true. > Do you mean that there won't be official VM releases anymore? > Or if there will be, then who will decide which changes/features will be included in those? apparently you do not really understand what is a distributed source management system. this is not because people can clone code and publish their own fixes that there is not somebody in charge of taking decision to integrate a fix or not. Now with git or system like that people can publish integrated code and VM maintainers can cherry pick the changes. In addition, imagine the near future where we will have automatic regression tests about all the produced VMs. then suddenly we will know the impact of a change. Now since we do not have any regression tests it is more difficult to control quality. Finally of course this may create a bit of noise but the most important aspect is that if somebody was in capability of helping but did not because of time constraints or other, the current set up can help this person to join effort. >> For example, igor sent a fix for the Windows vm for the semaphore input more than a year ago and it was never integrated. > > Yeah, that's annoying, I had the same experience earlier. > >> I'm happy that igor decided to stay in our community. Now we can ask ourselves (lot of people don't and after complain that smalltalk is a dead language) how many people came and left. Sharing is key. >> >> Now we will have a Windows VM built everyday (this is a fresh news ;) and more than 8 years I'm dreaming about that. >> And all the community will be able to use it, if they want. Nobody forces you to use our infrastructure but there will be a lot of advantages. It is free and maintained. > > Great. |
Fractal Development (was Re: [Vm-dev] VM Automated builds update)
|
|
I think I just have to crash this thread; renaming to be polite about it. Distributed SCM, thrown around a lot on the list. Continuous integration is a pretty obvious win I think (if you can convince me that it isn't I'll buy you a whole case of beer.) So I'll just look at source control. It works for the Linux kernel. In particular, it makes it possible for a *single individual* to handle integration for the whole kernel, by farming out the detail work to "trusted lieutenants," who in turn do the same for still others. Code starts flowing all over the place, and if it's useful it usually makes it's way back up the tree. Does the "single individual" part scream Smalltalk at anyone else, or is it just me? Think of it as a fractal development model wherein you have much testing and vetting at many levels before e.g. Torvalds ever sees it your commit. Some folks seem worried that a decentralized SCM will encourage more forks. I would maintain that forking is a social behavior, and it's unrelated to SCM. I think we will always have a core of people who "own" pieces of Squeak as a consequence of some combination of meritorious conduct, passion for the technology, etc. There's no need to ditch official releases to accommodate a distributed SCM. Frankly MC is already a hair closer to Git than it is to CVS in some respects, and all the damned thing really needs to get all this goodness rolling (on a technical level anyway) is branching functionality. Branch+Merge != Fork FWIW, the point is making branching and *especially* merging easier. When merging is easy, you have a force that acts *against* divergent enterprises. How many forks are there of Squeak? Okay, now how many forks are there of the Linux kernel? Is the orthogonality obvious yet? On Mar 17, 2011, at 2:02 PM, stephane ducasse <[hidden email]> wrote: > >>>>>>> >>> You can continue to bash us saying that we are nasty newbies. Right now we are building an **open** and welcoming architecture >>> to sustain real open development VMs. This is ok that you do not like it, this is ok too that you bash us. If this helps you feel better >>> I cannot do much about it. >> >> Did I bash you? No, I said it's "nice and great". > > Excellent then :) >> >>> >>> We want VMs to be maintained not just a small (tiny, microscopic) club of people that may be >>> distracted/not willing to communicate/not have the time to build a vms. We want to make sure that if a guy has time to improve a vm he will not get frustrated because of millions of stupid details: this is what is called software engineering (vs. handcraft). Having a solid automated process is the key to progress in constraints resources. We want to minimize risk for business. >> >> Great. >> >>> >>> Also we want to send a clear message to smart C, assembler people that lurk at our technology: they are welcome to participate and help >>> because the architecture is open. They do not have to ask for a blessing (knights period is over). They can clone, hack and push/share changes and people can cherry pick the changes without having to have the permissions to publish. >> >> That sounds good, but it may not be true. >> Do you mean that there won't be official VM releases anymore? >> Or if there will be, then who will decide which changes/features will be included in those? > > apparently you do not really understand what is a distributed source management system. > this is not because people can clone code and publish their own fixes that there is not somebody in charge of taking decision to integrate a fix or not. Now with git or system like that people can publish integrated code and VM maintainers can cherry pick the changes. In addition, imagine the near future where we will have automatic regression tests about all the produced VMs. then > suddenly we will know the impact of a change. Now since we do not have any regression tests it is more difficult to control quality. > Finally of course this may create a bit of noise but the most important aspect is that if somebody was in capability of helping but > did not because of time constraints or other, the current set up can help this person to join effort. > >>> For example, igor sent a fix for the Windows vm for the semaphore input more than a year ago and it was never integrated. >> >> Yeah, that's annoying, I had the same experience earlier. >> >>> I'm happy that igor decided to stay in our community. Now we can ask ourselves (lot of people don't and after complain that smalltalk is a dead language) how many people came and left. Sharing is key. >>> >>> Now we will have a Windows VM built everyday (this is a fresh news ;) and more than 8 years I'm dreaming about that. >>> And all the community will be able to use it, if they want. Nobody forces you to use our infrastructure but there will be a lot of advantages. It is free and maintained. >> >> Great. > |
Re: Fractal Development (was Re: [Vm-dev] VM Automated builds update)
|
|
On 17 March 2011 23:46, Casey Ransberger <[hidden email]> wrote: > > I think I just have to crash this thread; renaming to be polite about it. > > Distributed SCM, thrown around a lot on the list. Continuous integration is a pretty obvious win I think (if you can convince me that it isn't I'll buy you a whole case of beer.) So I'll just look at source control. > > It works for the Linux kernel. In particular, it makes it possible for a *single individual* to handle integration for the whole kernel, by farming out the detail work to "trusted lieutenants," who in turn do the same for still others. Code starts flowing all over the place, and if it's useful it usually makes it's way back up the tree. > > Does the "single individual" part scream Smalltalk at anyone else, or is it just me? > > Think of it as a fractal development model wherein you have much testing and vetting at many levels before e.g. Torvalds ever sees it your commit. > > Some folks seem worried that a decentralized SCM will encourage more forks. I would maintain that forking is a social behavior, and it's unrelated to SCM. > Indeed. I am personally against forking. Splitting precious human resources , wasting energy on holy wars.. It is much better to work together. > I think we will always have a core of people who "own" pieces of Squeak as a consequence of some combination of meritorious conduct, passion for the technology, etc. There's no need to ditch official releases to accommodate a distributed SCM. Frankly MC is already a hair closer to Git than it is to CVS in some respects, and all the damned thing really needs to get all this goodness rolling (on a technical level anyway) is branching functionality. > > Branch+Merge != Fork > > FWIW, the point is making branching and *especially* merging easier. When merging is easy, you have a force that acts *against* divergent enterprises. > > How many forks are there of Squeak? Okay, now how many forks are there of the Linux kernel? > > Is the orthogonality obvious yet? > It was obvious. From very starting. I stress again, that things which i doing is not fork. It is my contribution (on behalf of Pharo team) to VM development. The maximum divergence which i can expect to be needed by Pharo is building/packaging VM with Pharo icon. :) In future i can go deeper (if time allow) and change/fix some stuff. But it can be folded back to mainline at any moment (of course if it prove to be useful). It is clear , that none of Pharoers want to privatise VM or someone's work. Our vision is simple: spread the knowledge, get a critical mass, make VM development open and contribution easy and without extra administration cost. In is in same spirit as Squeak trunk does: anyone can push the changes to inbox without asking, and core devs can push directly to trunk. So if you look at gitorious it reflects the same process model, just using git as a tool for that. -- Best regards, Igor Stasenko AKA sig. |
Re: Fractal Development (was Re: [Vm-dev] VM Automated builds update)
|
|
In reply to this post by Casey Ransberger-2
> Distributed SCM, thrown around a lot on the list. Continuous integration is a pretty obvious win I think (if you can convince me that it isn't I'll buy you a whole case of beer.) So I'll just look at source control. > > It works for the Linux kernel. In particular, it makes it possible for a *single individual* to handle integration for the whole kernel, by farming out the detail work to "trusted lieutenants," who in turn do the same for still others. Code starts flowing all over the place, and if it's useful it usually makes it's way back up the tree. > > Does the "single individual" part scream Smalltalk at anyone else, or is it just me? > > Think of it as a fractal development model wherein you have much testing and vetting at many levels before e.g. Torvalds ever sees it your commit. > > Some folks seem worried that a decentralized SCM will encourage more forks. I would maintain that forking is a social behavior, and it's unrelated to SCM. yes because nothing prevents you do have your own local copy containing your fixes and not sharing them > > I think we will always have a core of people who "own" pieces of Squeak as a consequence of some combination of meritorious conduct, passion for the technology, etc. There's no need to ditch official releases to accommodate a distributed SCM. Frankly MC is already a hair closer to Git than it is to CVS in some respects, and all the damned thing really needs to get all this goodness rolling (on a technical level anyway) is branching functionality. > > Branch+Merge != Fork > > FWIW, the point is making branching and *especially* merging easier. When merging is easy, you have a force that acts *against* divergent enterprises. yes > > How many forks are there of Squeak? Okay, now how many forks are there of the Linux kernel? > > Is the orthogonality obvious yet? sorry probably my english but I do not get what you want to say. Now I agree with the answer of igor. |
«
Return to Squeak VM
|
1 view|%1 views
| Free forum by Nabble | Edit this page |