[Cuis] Cuis
Locked
123456789
123456789
 
|
> What I really would like is to hear about REAL compatibility problem
> and not supposed compatibility problems. The real compatibility problem is this. I am working in a 3.10 based image NOW. I wont have the opportunity to move my code base and find out what the compatibility problems are until 3.11 is released in 6 months time. In that 6 months I will have generated a considerable amount of code, that may be incompatible with 3.11 but I wont have known it. I will also have been saving my packages to squeaksource, but I will not know that these packages are not useful to 3.11 users. All the 3.11 users will load my packages and will either complain or write my code off as "it never works", and I will never find out. So, when I finally move my working image to 3.11, all my deployed production images are still in 3.10. So now I have to maintain 2 code bases of my packages. However if I could load a couple of patches into 3.10 that make them API equivalent, I wouldnt have to. Ok to do this I have to manually reverse-engineer the whole of the 3.11 effort. In short it is too difficult to contemplate, because non of the 3.11 effort was done with the expectation that it would need to be re- engineered. This is what happened in the case of ifNotNil: ifNotNilDo: merger. So, here we have an opportunity, Josh, could make his futures work, loadable into 3.10. Then I can start using this new wizzy api now in my existing code base, and I wont have to wait a year to be able to give him feedback. If Elliot or Andreas or someone, could make closures loadable into 3.10 as a separate entity, then that would be of GREAT benefit to me and to Edgar apparently. I would also like the long changes file fixes (but someone told me they are available on mantis) So in summary, I will not be ready to tell you what the compatibility problems are until about 3 months after the release of 3.11 is finished. At which point the only person who can fix them, will be me, for myself only. Keith |
|
|
In reply to this post by Randal L. Schwartz
> Josh> that it is a technical shortcoming of Sake/Packages, I just
> think that > Josh> any attempt to have universal cross-fork compatibility is > fundamentally > Josh> doomed to either: > > Josh> 1) fail, or > > Josh> 2) "succeed", but at the cost of preventing fundamental > improvements to > Josh> the programming model Let's try an example. We have three forks... Edgars-Minimal , Keith's Beach, and Pharo's. If I develop a package, Rio, that loads into a Pharo release, in order to load Rio into Beach, I have two choices. 1. Make the Rio code base more general, use the lowest common denominator (i.e go backwards) 2. Make Beach more like Pharo with a patch or two. (The forks are converging with the patch) I prefer the 2nd option. Now if I patch Keith's-Beach, my patch is only useful to me. However if I patch 3.10 on which Keith's Beach is built then I am capturing useful knowledge, for all users of 3.10, including Edgar. So along comes Edgar, he finds Rio doesn't load, however there is a patch which clearly explains the issue. He doesnt need to understand Beach, because the patch is against 3.10 which he already understands. Since he is the developer of Minimal based on 3.10 he can see how to adapt the patch for Minimal So, now we have several benefits. 1. Rio loading in three base images, and 2. the api of the three forks are converging. So what does this mean in practice. If you develop your next base image (aka 3.11) in smaller steps, patches against 3.10, then other forks can gain api compatability with 3.11, by choosing to become more like 3.10 (a task which is possible), rather than choosing to become more like 3.11 a task which is impossible because 3.11 isn't finished yet. regards Keith |
|
|
In reply to this post by keith1y
From my point of view, every feature of 3.11 that you publish which is directly loadable into 3.10, I will accept as progress, because I can use it now. Otherwise, I will have to wait over a year to port my code base and find out. Presently it seems to me that every feature of 3.11, is a potential compatibility problem, making the port more difficult and the probability of the port happening more unlikely. I get paid for delivering an application that works. The porting process, when it eventually happens will end up as a month or so of unpaid work, since the client doesn't care about the details. What I don't get is how come Randal, who is an application developer himself, doesn't see this. Do you have some other solution? Ahhh I get it. Randal is building his stuff on other peoples packages like seaside, so you get to leave the hassle of fork incompatibilities to them, its "someone else's problem". Cool solution. So... the seaside crew announce that they are going to solve this problem by only developing for Pharo, and the Magma guy announces that he is going to solve this problem by only developing for Squeak. Pity the poor soul who wants to use Seaside with Magma that would be me Keith p.s. before someone who is incapable of abstract thought pipes up and says "but seaside runs on squeak as well", and "magma runs on pharo as well" The Magma-Seaside case is "only an example" demonstrating the principle of the problem. p.p.s now with the current state of play, I simply despair, since squeak ceases to be a viable platform to actually work in, because everyone is insisting on developing to moving targets, and I mean everyone! All you have to do to change this is conceptually develop patches only relative to specific non moving releases. Then all of the forks will naturally converge their API's, and you wont leave people behind. |
|
|
In reply to this post by keith1y
2010/1/24 keith <[hidden email]>:
> > On 24 Jan 2010, at 06:44, Friedrich Dominicus wrote: > >> Josh Gargus <[hidden email]> writes: >> >>> >>> >>> The "community" doesn't want only one thing, and different people in it >>> want >>> different things to different degrees. I don't dispute that what you >>> have >>> described above is desirable, in principle, to the vast majority of >>> community >>> members. However, it is fundamentally at odds with other goals that >>> various >>> community members hold dear. A balance must be struck. >> >> You are right, but let's as it that way: >> - how many of you do activly work in the "Kernel!" >> - how many of you do use it for application development >> >> I would be suprised to see a ratio much higher than 1:10 000 or even >> 1: 100 000 (kernel dev/application dev). >> >> As I understand Keiths posting he's mainly an application developer and >> so it's clear that he does not like to re-write his code over and over >> again (for whatever good/bad technical reason). > > It's worse than that. > > When there are too many packages all a moving target, being written on too > many differing kernels, also moving targets. At some point the task of > building an application and maintaining it becomes virtually impossible. > > Suddenly there comes a point where the only choice you have is to fork > everything! > > This is a very hard choice to make if you are not good enough, or you don't > have the time to maintain everything. > > Of course the gurus Lukas', Andreas and Stefane don't have this problem, so > they apparently don't see a need. > >> There's IMHO no better way to drive away people but to break their code >> over and over again... > > Amen, Amen and Amen. > >>> >>> Here's a very specific example. I would like to see more integrated >>> support >>> for concurrent programming in the Squeak kernel. Toward that end, >>> I've added a >>> trivial implementation of "promises" to the trunk (hopefully, I'll take >>> it >>> further relatively soon... one of the things I've done in the interim was >>> to >>> re-read Mark Miller's dissertation). >> >> Well so you are interested in another thing. Well so you probably do not >> see the points of Keiths mails. >> >> >> Regards >> Friedrich > > Josh, > > So, your implementation of futures, that sounds useful. My images are all > based upon 3.10, so would you be so kind as to package up your > implementation in a form that I can actually use in my images. A change set > that is load able into 3.10 would be good enough, if you did this then Edgar > would use it too I am sure. You see, then I can use your API with my current > code base. When the time comes to move my code base to 3.11, the transition > will be a smooth one. > > thanks in advance > > Keith > Keith, you know very well your main options: 1) you take a trunk/pharo/cuis image then reload all your stuff (LPF/Installer/Sake/Package SHOULD be helpful). You may report compatibility problems in relevant list. 2) you start with an unmaintained image from the past, transform MC diffs into change sets and you cherry pick, but you're on your own. I know very well your problems. I played option 2) during seveal years when releasing a commercial product in VW. I know very well the costs, and I know you are in trouble with this path. Not that many experienced people are still supporting option 2). Juan still use it because he wants a very fine grain control. The fact that Cuis is minimal may help but he knows how much time it costs. Sorry, but I doubt you'll attract many people on that path. Would I develop an app today, no doubt it would be with option 1. Installer/Sake could be used as well for option 1, couldn't it ? You have to think about this option too. That's how I see things with option 1: - you select an image when you think added value is worth the effort (like faster file I/O) - you load and run specific Kernel tests expressing the essential expectations of your application here, you can have a go/no go decision. It can also be a maybe: you send requests to developpers or propose your own changes in trunk. - you play your scripts to load your application - you run your application tests and ask for support on regressions and uncompatibilities. More over, with bob you could automate the tests and automatically know if trunk updates are breaking things or not. So the question of an officially "released" image is less relevant. If you really want this process, adopt Pharo, they are close to 1.0 (without faster streams and other improvments of course...). Cheers. Nicolas |
Re: Revived from the dead [Re: [squeak-dev] [Cuis] Cuis]
|
|
In reply to this post by keith1y
2010/1/24 keith <[hidden email]>:
>> Josh> that it is a technical shortcoming of Sake/Packages, I just think >> that >> Josh> any attempt to have universal cross-fork compatibility is >> fundamentally >> Josh> doomed to either: >> >> Josh> 1) fail, or >> >> Josh> 2) "succeed", but at the cost of preventing fundamental improvements >> to >> Josh> the programming model > > > Let's try an example. We have three forks... > > Edgars-Minimal , Keith's Beach, and Pharo's. > > If I develop a package, Rio, that loads into a Pharo release, > > in order to load Rio into Beach, I have two choices. > > 1. Make the Rio code base more general, use the lowest common denominator > (i.e go backwards) > 2. Make Beach more like Pharo with a patch or two. (The forks are converging > with the patch) > > I prefer the 2nd option. Now if I patch Keith's-Beach, my patch is only > useful to me. > However if I patch 3.10 on which Keith's Beach is built then I am capturing > useful knowledge, for all users of 3.10, including Edgar. > > So along comes Edgar, he finds Rio doesn't load, however there is a patch > which clearly explains the issue. He doesnt need to understand Beach, > because the patch is against 3.10 which he already understands. Since he is > the developer of Minimal based on 3.10 he can see how to adapt the patch for > Minimal > > So, now we have several benefits. > > 1. Rio loading in three base images, and > 2. the api of the three forks are converging. > > So what does this mean in practice. If you develop your next base image (aka > 3.11) in smaller steps, patches against 3.10, then other forks can gain api > compatability with 3.11, by choosing to become more like 3.10 (a task which > is possible), rather than choosing to become more like 3.11 a task which is > impossible because 3.11 isn't finished yet. > > regards > > Keith > > What's your goal ? Develop an application ? Develop a cross-fork module/package/library ? If the later (RIO), then use what every other cross-fork do, compatibility layers (Grease...). Otherwise, concentrate on the fork you have chosen and let people port if they are interested. If you catch a huge market like Seaside, you'll eventually be in a position to influence fork directions. Otherwise, you can also make things move by technical argumentation. If your pressure is only political, beat it, you're not in a position to win. Nicolas > > |
|
|
In reply to this post by Edgar J. De Cleene
Exactly what I said, you have a NEED for "Minimal" to not be made obsolete, so you have a NEED to repeat the work of the guru's or solicit their help. Wouldn't it be nice if they anticipated your NEED, since it was their need once, and it is also my NEED. To anticipate your need, all they need to do is publish the work relative to a fixed point that is known, rather than integrating it as they go along in to a moving target. The fundamental problem is not the progress it is the moving target.
Here we have the same problem in the backwards direction. You had a go at unloading etoys, but managed an imperfect job. Well done for having the guts to try it. So if you were to publish your imperfect effort as a delta against a known fixed point 3.10 release. Then the gurus, knowing you had a need, could contribute to your effort, and publish it as a final delta against the 3.10 release. However what happens is, the gurus are off working relative to their moving target, we will call it "trunk" for the sake of argument, so they don't see your hard work as relevant to them, after all they are a guru so they know better. They easily redo your work in a day, that took you weeks, but then they publish it to their moving target. The net result, your hard work is ignored, and you are left scavenging through their repository in the hope you can learn what you did wrong, and apply it to your moving target.
Actually Edgar, I think you may have been ahead of your time on this one. Given that Cuis doesn't have Monticello I have been having similar ideas myself.
Sure... the problem being that those who develop applications like me have their time and limited talent tied up in hefty loaded images, with the client screaming to just make the damn thing work. Those who are sprinting ahead with the time and the talent to make a better kernel, are simply not in the same world. LevelPlayingField (and 3.10-build) was invented as a place to put patches that could smooth out the difference, between what the kernel developers give us, and what we application developers actually need.
I have always strongly objected to this repeated accusation. I have continuously been interested in having your input, but you would never give it, you absolutely refused. You just said "he uses scripts in a website" that dont have a password (when I don't) and turned your back on the idea of joining in. Secondly I was continuously interested in contributing to 3.10, I wrote TestReporter a non GUI test runner for SUnit , as a contribution to 3.10. Ralph ignored my contribution and wrote his own 3 months later. Which one is the team player? I wrote Installer as a contribution to 3.10, which you included, but you included an old version... again I write stuff to be included, I get it included, but someone decides not to make sure that the best version is published in the final release. Again who is the team player here, and who is not? I provided a framework within which you could publish the script for building FunSqueak. I asked you to put funsqueak into Sake/Packages so we could see what it contained and build and test 3.11 against FunSqueak. Damien did it for the "developer" image, and he isnt even a regular squeak user.
Until I manage to load closures into my working image, all the time and energy I put into it, has been wasted. Or until I can load my working image into 3.11 (which I have to wait a long while for), my effort is wasted. It appears to be that a lot of effort gets wasted around here.
It was mantis yesterday. Only Mantis is more useful for me NOW.
You don't need to run for the board. Campaign instead for the board not to favour certain "egos" and to have a civilised protocol where discussion and collaboration is actually possible.
"trunk" is a pre-concept we are stuck with now, it was created without listening or understanding that we had already decided that this very way of working was what had caused previous problems in the past. 1. Long release turnarounds, because trying to do too much at once. 2. No small scale branching, thus provoking full scale forking. 3. Repeatedly large chunks of the community get left behind (etoys 3.8, Sophie 3.8, cobalt 3.8) Gjallar is the only large project that I know of which hasn't been left behind, and the solution for that was Installer and LPF. regards Keith |
Re: Revived from the dead [Re: [squeak-dev] [Cuis] Cuis]
|
|
In reply to this post by keith1y
2010/1/24 keith <[hidden email]>:
> Progress which cant be used is not actually progress. > > From my point of view, every feature of 3.11 that you publish which is > directly loadable into 3.10, I will accept as progress, because I can use it > now. > Otherwise, I will have to wait over a year to port my code base and find > out. > Presently it seems to me that every feature of 3.11, is a potential > compatibility problem, making the port more difficult and the probability of > the port happening more unlikely. > I get paid for delivering an application that works. The porting process, > when it eventually happens will end up as a month or so of unpaid work, > since the client doesn't care about the details. > What I don't get is how come Randal, who is an application developer > himself, doesn't see this. > Do you have some other solution? Ahhh I get it. Randal is building his stuff > on other peoples packages like seaside, so you get to leave the hassle of > fork incompatibilities to them, its "someone else's problem". Cool solution. > So... the seaside crew announce that they are going to solve this problem by > only developing for Pharo, and the Magma guy announces that he is going to > solve this problem by only developing for Squeak. Pity the poor soul who > wants to use Seaside with Magma > that would be me > Keith > p.s. before someone who is incapable of abstract thought pipes up and says > "but seaside runs on squeak as well", and "magma runs on pharo as well" The > Magma-Seaside case is "only an example" demonstrating the principle of the > problem. There is at least one abstraction you've become a master of: circles ;). > p.p.s now with the current state of play, I simply despair, since squeak > ceases to be a viable platform to actually work in, because everyone is > insisting on developing to moving targets, and I mean everyone! All you have > to do to change this is conceptually develop patches only relative to > specific non moving releases. Then all of the forks will naturally converge > their API's, and you wont leave people behind. > Oh well, this applies to my 2cents bug patches (even these happen to be different in 3.10, trunk and Pharo) Bye bye closure, COG, etc... A 5x speed up certainly is a moving target I will learn to love. > > |
Squeak core dev is now like every other open source project! (was Re: [squeak-dev] [Cuis] Cuis)
|
|
In reply to this post by Nicolas Cellier
>>>>> "Nicolas" == Nicolas Cellier <[hidden email]> writes:
Nicolas> Since I don't see much requests in this list, shall I conclude that Nicolas> either Squeak-trunk is not used for application dev. or that there is Nicolas> no major compatibility problem ? Why is this viewed so much different from every other open source project? Do you keep installing the daily release of the Linux Kernel on your server machines? No! You wait for a major release of Fedora, or Debian, or Ubuntu, which happens every six months or year. You port your code to the new release, with hopefully only a few problems. You then deploy *that* release with your code. Squeak is following a similar model... if you have production code, keep using 3.9 or 3.10 or 3.10.2 until the next *Squeak* release, which will be 4.0 within a few weeks (same as 3.10.2 precisely) and then 4.1 shortly after (which will be a frozen and vetted version of trunk), and then 4.2 maybe a year later. If you are a *developer* of Squeak itself, follow trunk, propose changes to Inbox, and perhaps become a committer to trunk yourself after enough good patches. THIS IS THE SAME MODEL AS EVERY OTHER SUCCESSFUL OPEN SOURCE PROJECT. Keith continues to make it into something it isn't. We're doing *what works*. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 <[hidden email]> <URL:http://www.stonehenge.com/merlyn/> Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc. See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion |
|
|
In reply to this post by Nicolas Cellier
> Keith, you know very well your main options:
> 1) you take a trunk/pharo/cuis image then reload all your stuff > (LPF/Installer/Sake/Package SHOULD be helpful). You may report > compatibility problems in relevant list. yep, correct. > 2) you start with an unmaintained image from the past, transform MC > diffs into change sets and you cherry pick, but you're on your own. yep correct again. So points to conclude from this. a. Everyone is on their own. b. You can't really start doing either, until the 3.11 is released. (So a bi-monthly release cycle would be a better thing than a bi- annual one, I am still waiting for the process that is going to get us a bi-monthly release, tested and documented) c. If you do start doing it now, you have to continuously track trunk. If you use packages form pharo, you probably have to continually track pharo as well! d. The packages that you publish which have existing users, you either have to maintain a dual codebase for, one for the old and one for the new base images, or you have to restrict yourself to the lowest common denominator. (if you are forced to do this all the time, then there is no point in moving to a better api) > I know very well your problems. > I played option 2) during seveal years when releasing a commercial > product in VW. > I know very well the costs, and I know you are in trouble with this > path. You are making the mistake that option 1 and 2 are mutually exclusive, they are not. You only have to back port essential API changes, (like for example, if Pharo publish Author as a loadable package that would load into Squeak, then a load of compatibility problems will be sorted) Once you have back ported the API, you can move your own code base forward, and continue to support other users still stuck in the past, by offering them the backport patch. > Not that many experienced people are still supporting option 2). > Juan still use it because he wants a very fine grain control. The fact > that Cuis is minimal may help but he knows how much time it costs. > Sorry, but I doubt you'll attract many people on that path. And the evidence we have is that purely relying on option 1, leaves a trail of forks behind it, (etoys, sophie cobalt, and now soon to be an orphan "beach") for which the cost of porting up to the front is 3 months of unproductive work. Secondly there are now two fronts to port up to, so which do you choose? All that is needed is to facilitate a migration path, from 3.x to 3.x +1. Note I didn't say you need to provide that migration path, just facilitate it. You facilitate it by packaging separate innovations separately upfront. (like we did on mantis, but on a less granular scale). This is the basis of the packaging model, just applied to features of the kernel. Then you build your releases by integrating innovations on a regular basis. Then the knowledge you need to backport an innovation is there if you need it. No cherry picking is needed. Secondly you are not on your own, because if you extend the innovation to provide a backport to say, 3.10. Edgar can come along and contribute his knowledge (by conceptually subclassing your work) and extend it to work for "Minimal" too. So the model proposed is: you innovate in the latest release, in your context, but you don't publish your innovation in such a way as to restrict its use to only your context. (that would normally be called a changeset (cs), or a deltastreams-delta (ds) You allow others to retarget your innovation to their context, and you provide a place where all users of that innovation pool their knowledge as to how to apply your innovation to all the different contexts. This is what Sake/ Tasks is for, you provide your innovation as one Task, with dependencies and pre-requisites, and others can subclass that Task to tweak it for application to other contexts, which have other dependencies and pre-requisites. Sake/Packages does this for packages. It collects the data as to what is needed to load a package into Squeak, Pharo, and any other contexts you care to add. However it does this, not just for the current releases, but also past unmaintained releases. The squeaksource.com/ Packages repository becomes a shared resource defining exactly what loads where. If for example I want to load a package into a released version of Minimal, then I can add the fix to the the dependencies in the Minimal packages definitions. At a later date I hope I can persuade Edgar to incorporate the patch in Minimal, but if there are any users of the old Minimal release then they will still need the patch. > Would I develop an app today, no doubt it would be with option 1. > Installer/Sake could be used as well for option 1, couldn't it ? You Yes this is what I use, and have used since 2006. 1. However pier keeps data in image, so the move is not routine. 2. Trunk is still moving, and is alpha so it will not be ready for at least 6 months and i wont have the time for perhaps a year to do it (so trunk remains irrelevant to me for all practical purposes until about a year or more hence) 3. I am not just porting an application to latest, I am supporting packages that have users in many images. So while I may port my stuff to latest, I still have to support my users in 3.x-1. So I end up having to follow option 2 anyway, even to achieve option 1. The bob process would only integrate release quality finished innovations into the final-release. Conceptually there would never be an alpha release, there is always a stable release X, and the previous stable release X-1, and the 100 or so deltas that move X-1 to X. > have to think about this option too. > That's how I see things with option 1: > - you select an image when you think added value is worth the effort > (like faster file I/O) > - you load and run specific Kernel tests expressing the essential > expectations of your application > here, you can have a go/no go decision. > It can also be a maybe: you send requests to developpers or propose > your own changes in trunk. Its a bit late, since I wont be starting this until 6 months after trunk is released. > - you play your scripts to load your application > - you run your application tests and ask for support on regressions > and uncompatibilities. But meanwhile I still have to support and maintain the X-1 release. So I still have to back port patches to X-1. We have a mechanism for patching the current release (its called the release team), but we don't have a mechanism for patching the X-1 release for my existing package users. (that is what LPF was invented for, but if no one uses LPF....) > More over, with bob you could automate the tests and automatically > know if trunk updates are breaking things or not. yep you could. > So the question of an officially "released" image is less relevant. > If you really want this process, adopt Pharo, they are close to 1.0 Thats what I was actually thinking of doing, until I actually tried pharo, and discovered they had removed the PackagePaneBrowser. I find OB unusable. > (without faster streams and other improvments of course...). > > Cheers. > > Nicolas Keith |
|
|
In reply to this post by Nicolas Cellier
Both: Develop an application using cross-fork packages. However the way things are going, its all I can manage to do the application, keeping all the balls in the air is a problem.
Is grease a package? why didn't whoever developed Grease, add to LPF which is already doing this? Or perhaps we just need to add Grease to LPF.
I haven't chosen a fork, I was going to use pharo, but found it somewhat reliant on OB which I dont get along with. So discovering that I didnt actually have a fork that I found interesting I cam back here to see if cuis would do the trick. this looks like it might be too much work. So I will probably just stay where I am, earn some money and employ someone else to port things later on (you never know). In the meantime the community looses the maintainence of any of the cross-fork packages I already provide. Keith |
|
|
In reply to this post by Randal L. Schwartz
Do you recall that in the last 10 years there was discovered such a thing as Extreme Programming. This is a different model to what you are using.
May I point out again that it doesn't work for me. My patches to trunk would be fixes for Monticello. These fixes would break trunk, therefore it doesn't work as you suppose. Keith |
Re: Revived from the dead [Re: [squeak-dev] [Cuis] Cuis]
|
|
In reply to this post by keith1y
2010/1/24 keith <[hidden email]>:
> > What's your goal ? > Develop an application ? > Develop a cross-fork module/package/library ? > > Both: Develop an application using cross-fork packages. > However the way things are going, its all I can manage to do the > application, keeping all the balls in the air is a problem. > > If the later (RIO), then use what every other cross-fork do, > compatibility layers (Grease...). > > Never heard of it, I have been out of the loop for a while. > Is grease a package? why didn't whoever developed Grease, add to LPF which > is already doing this? Or perhaps we just need to add Grease to LPF. > AFAIK, Grease is not universal. It is for seaside cross-dialect compatibility. Not sure it works for you, maybe... but the idea should work. > Otherwise, concentrate on the fork you have chosen and let people port > if they are interested. > > I haven't chosen a fork, I was going to use pharo, but found it somewhat > reliant on OB which I dont get along with. > So discovering that I didnt actually have a fork that I found interesting I > cam back here to see if cuis would do the trick. > this looks like it might be too much work. > So I will probably just stay where I am, earn some money and employ someone > else to port things later on (you never know). > In the meantime the community looses the maintainence of any of the > cross-fork packages I already provide. > Keith > |
|
|
In reply to this post by keith1y
On 24 Jan 2010, at 15:28, keith wrote:
Also squeak and linux are different, one is source based the other isn't. Squeak has a long history, and the problem is not, and never has been, bunging out another release, Edgar managed it all on his lonesome! The new problem on the block is reducing the propensity, the need, and the drive, for forking within the community. how exactly does trunk solve that. If you can answer that convincingly I will then be convinced that trunk is part of the solution and not part of the problem. regards Keith |
|
|
Randal wrote:
I suggest you read the documentation for Bazaar and Mercurial. Each new feature or fix is developed in its own branch. These branches are referred to as feature branches or task branches - the terms are used interchangeably. To create a task branch, use the branch command against your mirror branch. For example: bzr branch trunk fix-123
cd fix-123
(hack, hack, hack)
There are numerous advantages to this approach:
In particular, some changes take longer to cook than others so you can ask for reviews, apply feedback, ask for another review, etc. By completing work to sufficient quality in separate branches before merging into a central branch, the quality and stability of the central branch are maintained at higher level than they otherwise would be. regards Keith |
Re: Revived from the dead [Re: [squeak-dev] [Cuis] Cuis]
|
|
In reply to this post by keith1y
2010/1/24 keith <[hidden email]>:
> > What's your goal ? > Develop an application ? > Develop a cross-fork module/package/library ? > > Both: Develop an application using cross-fork packages. > However the way things are going, its all I can manage to do the > application, keeping all the balls in the air is a problem. > Developing an application means freezing a set of dependencies. If you're not freezing them, then you not developing an application, you just toying. Because, you'll never know that might be broken, when you update dependencies to the latest, so you are always doing it at own risk (and don't blame the devs about breaking things - its absurd), because despite what package maintainer says, there are always a chance that with even little and minimal update, your application could stop working normally. This is what we calling 'moving target'. Sure thing, if package maintainer tries to preserve compatibility, then in 99% cases everything ok, but if he not - then its up to you to manually update the application to conform with newer version of package. And always will. The only class of updates, which can be acceptable in such ecosystem is bug fixes. But if you need to move forward, like introduce new & better stuff, or remove obsolete cruft, you inevitably will meet compatibility problems. Honestly, what kind of automation you can invent here to migrate your application from using package version A, to package version B , which potentially, can be completely rewritten from scratch? You doomed to either stay with version A, or do a lot of manual work migrating to version B and no magic tool will help you with that. About cross-fork package development. Each package having an environment-agnostic behavior , and environment dependent. The goal of developer is to identify these parts and connect them nicely. But this is gone too far. It is now about defining and enforcing a good practices in package development to avoid cross-dialect pitfalls. How many packages we has built with cross-compatibility in mind? How many packages having all globals declared in a single place, not scattered among code? And what automated tools can solve the problems, when your package code using 'SmalltalkImage current' instead of 'Smalltalk'? > If the later (RIO), then use what every other cross-fork do, > compatibility layers (Grease...). > > Never heard of it, I have been out of the loop for a while. > Is grease a package? why didn't whoever developed Grease, add to LPF which > is already doing this? Or perhaps we just need to add Grease to LPF. > > Otherwise, concentrate on the fork you have chosen and let people port > if they are interested. > > I haven't chosen a fork, I was going to use pharo, but found it somewhat > reliant on OB which I dont get along with. > So discovering that I didnt actually have a fork that I found interesting I > cam back here to see if cuis would do the trick. > this looks like it might be too much work. > So I will probably just stay where I am, earn some money and employ someone > else to port things later on (you never know). > In the meantime the community looses the maintainence of any of the > cross-fork packages I already provide. > Keith > > > -- Best regards, Igor Stasenko AKA sig. |
Re: Squeak core dev is now like every other open source project! (was Re: [squeak-dev] [Cuis] Cuis)
|
|
In reply to this post by keith1y
2010/1/24 keith <[hidden email]>:
> > If you are a *developer* of Squeak itself, follow trunk, propose > changes to Inbox, and perhaps become a committer to trunk yourself > after enough good patches. > > THIS IS THE SAME MODEL AS EVERY OTHER SUCCESSFUL OPEN SOURCE PROJECT. > > Do you recall that in the last 10 years there was discovered such a thing as > Extreme Programming. This is a different model to what you are using. > > Keith continues to make it into something it isn't. We're doing > *what works*. > > May I point out again that it doesn't work for me. My patches to trunk would > be fixes for Monticello. These fixes would break trunk, therefore it doesn't > work as you suppose. Strange, then , why calling it fix - fixes usually not breaking existing stuff. Call it replacement or rewrite, or upgrade, but not 'fix'. > Keith > > > -- Best regards, Igor Stasenko AKA sig. |
Re: Squeak core dev is now like every other open source project! (was Re: [squeak-dev] [Cuis] Cuis)
|
|
In reply to this post by keith1y
On Sun, 24 Jan 2010, keith wrote:
>> >> If you are a *developer* of Squeak itself, follow trunk, propose >> changes to Inbox, and perhaps become a committer to trunk yourself >> after enough good patches. >> >> THIS IS THE SAME MODEL AS EVERY OTHER SUCCESSFUL OPEN SOURCE PROJECT. > > > Do you recall that in the last 10 years there was discovered such a thing as > Extreme Programming. This is a different model to what you are using. > >> Keith continues to make it into something it isn't. We're doing >> *what works*. > > > May I point out again that it doesn't work for me. My patches to trunk would > be fixes for Monticello. These fixes would break trunk, therefore it doesn't > work as you suppose. So these are not patches to trunk. Levente > > Keith |
Re: Squeak core dev is now like every other open source project! (was Re: [squeak-dev] [Cuis] Cuis)
|
|
2010/1/24 Levente Uzonyi <[hidden email]>:
> On Sun, 24 Jan 2010, keith wrote: > >>> >>> If you are a *developer* of Squeak itself, follow trunk, propose >>> changes to Inbox, and perhaps become a committer to trunk yourself >>> after enough good patches. >>> >>> THIS IS THE SAME MODEL AS EVERY OTHER SUCCESSFUL OPEN SOURCE PROJECT. >> >> >> Do you recall that in the last 10 years there was discovered such a thing >> as Extreme Programming. This is a different model to what you are using. >> >>> Keith continues to make it into something it isn't. We're doing >>> *what works*. >> >> >> May I point out again that it doesn't work for me. My patches to trunk >> would be fixes for Monticello. These fixes would break trunk, therefore it >> doesn't work as you suppose. > > So these are not patches to trunk. > And besides, MC CAN be updated using MC. We already having a lot of entry points for these: - use SomeClass>>initialize - use image startup/shutdown phases - use package script Keith, you can look how we managed to replace compiled methods trailer handling without need of using .cs, but just loading a set of MC packages. > > Levente > >> >> Keith -- Best regards, Igor Stasenko AKA sig. |
|
|
In reply to this post by Igor Stasenko
>> May I point out again that it doesn't work for me. My patches to >> trunk would >> be fixes for Monticello. These fixes would break trunk, therefore >> it doesn't >> work as you suppose. > > Strange, then , why calling it fix - fixes usually not breaking > existing stuff. > Call it replacement or rewrite, or upgrade, but not 'fix'. I think AGAIN you are missing the point completely Monticello cant load itself for anything other than the most minor of changes. Keith |
|
|
In reply to this post by Levente Uzonyi-2
I have done my damnedest to get people to manage packages like Monticello and SUnit externally, but it doesnt work. Monticello is as far as I know is maintained in trunk. (it shouldnt be), it should be integrated in from elsewhere. Non of my changes are developed in the kernel. Everything I do is a loadable optional thing. Keith |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |