Hi:

Without excluding nothing, I think that Minimal deserve a bit of attention. I saw it running latests version of Pier with no problems.

I'm thinking in use it to Pier customers, because in shared servers the sizes of image is very important.

Just my 0,02

Cheers. Germán.

2010/1/23 Edgar J. De Cleene edgardec2001@yahoo.com.ar:

On 1/23/10 11:58 AM, "keith" keith_hodges@yahoo.co.uk wrote:

So, welcome to the brave new world, built in Cuis.

Well, I do not should speak by Juan, but  you sure you don’t wish another mammal? Cuis  is small, beautiful, fast and a good Smalltalk. But maybe when you add some tool (Monticello is my first choice, several more for sure, like OBSystemBrowser, Shout, TTF fonts etc) ends in a big thing which Juan don’t want..

I have Minimal, as several times said here.

It’s only 7.3 mb and could load all 3.10 could load without any more as a enhanced CodeLoader. Maybe is not so nice and sure not so clean. But is powerful and deserve be polished. Only lacks Closures, and again I ask for any who like spend some time to teach me how get Closures into and I said have a killer. Because could follow Trunk as SqueakLight 3.11 or 3.11Unloaded could. Choose which packages should actualize and which not. Could look on external servers for any not in the image as Minimal and SqueakLightII do for a long time now. Again I said have several Minimal + Some working day by day here in SqueakRos at http://www.squeakros.be.tc/ If take long to respond is because I don’t could afford let the Macs run 7/24 and cable modem sucks.

But I have some plans... I hope in a month or two going to fiber 2Mb both ways, so could be usable out of Rosario.

Naming the beast is open to suggestion.

LaVizcacha , which is a mammal bigger and uglier as Cuis. ElZorro , a mammal who eat Cuises. ElPerro, a domestic mammal founded in houses and cities. ElGato,  another favourite pet who also could eat Cuises.

Edgar

On Sat, 23 Jan 2010, Mariano Martinez Peck wrote:

On Sat, Jan 23, 2010 at 4:38 PM, Germán Arduino garduino@gmail.com wrote:

...

Hi:

Without excluding nothing, I think that Minimal deserve a bit of attention. I saw it running latests version of Pier with no problems.

I'm thinking in use it to Pier customers, because in shared servers the sizes of image is very important.

The latest PharoCore 1.0 is also 7.8 MB after ScriptLoader new cleanUpForRelease, where Seaside and Pier can run perfectly also.

Seems to be 10.7 MB.

Levente

Will check, thanks Mariano!

2010/1/23 Mariano Martinez Peck marianopeck@gmail.com:

2010/1/23 Levente Uzonyi leves@elte.hu

...

On Sat, 23 Jan 2010, Mariano Martinez Peck wrote:

...

On Sat, Jan 23, 2010 at 4:38 PM, Germán Arduino garduino@gmail.com wrote:

...

Hi:

Without excluding nothing, I think that Minimal deserve a bit of attention. I saw it running latests version of Pier with no problems.

I'm thinking in use it to Pier customers, because in shared servers the sizes of image is very important.

The latest PharoCore 1.0 is also 7.8 MB after ScriptLoader new cleanUpForRelease, where Seaside and Pier can run perfectly also.

Seems to be 10.7 MB.

Ups...sorry I mean ScriptLoader new cleanUpForProduction.    not ScriptLoader new cleanUpForRelease.

...

Levente

...

2010/1/23 Mariano Martinez Peck marianopeck@gmail.com:

2010/1/23 Levente Uzonyi leves@elte.hu

...

On Sat, 23 Jan 2010, Mariano Martinez Peck wrote:

...

On Sat, Jan 23, 2010 at 4:38 PM, Germán Arduino garduino@gmail.com wrote:

...

Hi:

Without excluding nothing, I think that Minimal deserve a bit of attention. I saw it running latests version of Pier with no problems.

I'm thinking in use it to Pier customers, because in shared servers the sizes of image is very important.

The latest PharoCore 1.0 is also 7.8 MB after ScriptLoader new cleanUpForRelease, where Seaside and Pier can run perfectly also.

Seems to be 10.7 MB.

Ups...sorry I mean ScriptLoader new cleanUpForProduction.    not ScriptLoader new cleanUpForRelease.

I tried the ScripLoader new cleanUpForRelease on Pharo1.0-10508-rc2dev10.01.2 and don't think to work.

I'm missing something?

Cheers. Germán.

oppsss my fault, sorry, and thanks Levente.

11,3MB on rc2.

Cheers. Germàn.

2010/1/26 Levente Uzonyi leves@elte.hu:

On Tue, 26 Jan 2010, Germán Arduino wrote:

...

2010/1/23 Mariano Martinez Peck marianopeck@gmail.com:

...

2010/1/23 Levente Uzonyi leves@elte.hu

...

On Sat, 23 Jan 2010, Mariano Martinez Peck wrote:

...

On Sat, Jan 23, 2010 at 4:38 PM, Germán Arduino garduino@gmail.com wrote:

...

Hi:

Without excluding nothing, I think that Minimal deserve a bit of attention. I saw it running latests version of Pier with no problems.

I'm thinking in use it to Pier customers, because in shared servers the sizes of image is very important.

The latest PharoCore 1.0 is also 7.8 MB after ScriptLoader new cleanUpForRelease, where Seaside and Pier can run perfectly also.

Seems to be 10.7 MB.

Ups...sorry I mean ScriptLoader new cleanUpForProduction.    not ScriptLoader new cleanUpForRelease.

I tried the ScripLoader new cleanUpForRelease on Pharo1.0-10508-rc2dev10.01.2 and don't think to work.

I'm missing something?

Yes, try cleanUpForProduction.

Levente

...

Cheers. Germán.

Wow, you're really not willing to concede a single point, ever, are you?

I'll respond to your specific points below. However, look at what you've done below... you nitpick specific points while trimming out the part of my text that makes my main point: that Monticello is very much like other distributed SCMs, and that nobody else uses any distributed SCM in the way that you propose with Sake/Packages. In particular, the Linux kernel source tree is not built automatically by a script that draws patches from a variety of repositories; I'm not aware of any other source tree that is, either.

This very typical of the way that you argue. I'm not sure if you have self-concsciousness of it. My hope is that you don't, and that there's a chance that I can help you gain it. If you're doing it intentionally, then please let me know, and I'll stop wasting my time.

On Jan 23, 2010, at 12:36 PM, keith wrote:

...

No, we already have a distributed SCM. It's called Monticello, and it works EXACTLY like git, mercurial, and bazaar. You are proposing something else.

CVS is a distributed SCM, when you check in you have to be online to do it.

(in the following, I'll use Version Control System, or VCS as a synonym for SCM... most people use this term now because they're used to store more than source code)

I have never, ever seen CVS described as a distributed VCS before. In any introduction to the benefits of distributed VCSes compared to centralized ones, CVS and Subversion are typically used as the canonical examples of centralized VCSes. If we're going to have a discussion, it will be helpful if we agree on the meanings of the words that we use. Maybe this will help:

http://www.infoq.com/articles/dvcs-guide

With Monticello, when you check in you have to be online to do it. Monticello does not work like mercurial or bzr, unless you set up a local repository.

There is a local repository by default... all versions that I download are automatically put into a local "package-cache" repository. Furthermore, it is trivially easy to set up a separate local repository. I just set one up right now... it literally took 25 seconds.

Or apparently Gofer allows you to move resources locally if you want to. MC1.5 has a copy all function as well.

Mercurial, and Bzr, dont use centralized servers, so when you check out you get the entire tree and history, for yourself, so you can work on the train.

I do the same with Monticello (with the inconsequential difference that I don't have the whole history... this is very seldom a problem in practice).

When you have finished your work on the train you can push back to the centralised repository if you want to.

Yes, this is exactly what I do on the train with Monticello. It's simple to commit to a local repository, and then copy the packages to the server when I get to the office.

Cheers, Josh

Keith

On Jan 23, 2010, at 5:43 PM, keith wrote:

...

Wow, you're really not willing to concede a single point, ever, are you?

Hi Josh,

You are really not understanding my point. So I didn't concede your point, because your point seemed to me to be being scored against the wrong target.

That's completely counter-productive. If you think that my point is off-target, just tell me.

You appear to be attempting to point score on the relative technical merits and possible uses of individual scm tools. Whereas I was attempting some abstract thinking about the process here, and the actual tools are not that relevant.

OK, I believe you. But it seemed like you were focusing on the tools. I understood that you were saying that Monticello wasn't the right tool because it didn't support working in a distributed mode. You apparently confirmed that when, in response to me arguing that Monticello *is* substantially like git/mercurial/bazaar, you didn't say that I was missing the point. Instead, you elaborated (incorrectly) about how Monticello doesn't support this mode of working, and prompted me to argue in more detail that "yes, I can and do commit to a local repository on the train, and then copy the results to a different repository once I'm connected to the network".

BTW, now that we've agreed that it doesn't matter, do you concede the point that Monticello is substantially like git/mercurial/bazaar from a technical perspective, even if we're not using it in the way that the Mercurial folks advocate? ;-)

You appear to repeat the same mistake when you have a go at "bob", bob is only a hacked together second attempt at a concrete tool for attempting to implement an abstract idea, a new way of working and thinking about the problem, in other words a different paradigm. You attack the tool and its implementer, on its lack of technical merits, and my inadequate capabilities, without understanding the value of the abstract thinking behind it. The deliverable of bob, is the demonstration and framework that allows you to think using the new paradigm, not fundamentally the tool itself. You say to me, ah ha, Lukas has developed a new CI tool, which is better than yours, so its ok we can ignore you, throwing bob away is justified. But, Lukas is using his new tool simply as a way of automating the old paradigm. Conceptually, you load an image from scratch, load some packages and test them, this is how Lukas is using his tool. You can do this manually, there is no new paradigm demonstrated here.

I think that the above is more like an amalgam of various things that people have said to you, not things that I myself have written (I've never heard of the CI tool that Lukas created, and don't have any opinion on it vs Bob). But fair enough.

The only part I would take issue with is that I'm only criticizing the implementation, not the idea. I think that many of my posts indicate that I'm trying to grapple with the idea.

Lets try again once more.

BTW, in advance of my comments and questions below, let me thank you for making the effort to lay everything out at once. It doesn't clear up all of my questions and concerns, but it offers a real chance that we can stop going in circles.

Also, I'm making a deliberate effort not to say anything controversial in this post. The goal is to establish a fixed point for subsequent conversation, so that we can stop going in circles.

Conceptually, there is one Seaside3 repository held centrally, and one team developing it, and there is one Seaside3 Head, for the entire world. This is the essence of the centralised approach. (Of course, anyone can do what they want locally) Linux may use distributed tools, but conceptually it is being controlled by one individual Linus, so it is also fundamentally a centralised model of thinking, no matter what the tools are able to achieve in practice.

Your point that Monticello can work in a distributed fashion is fine, of course it can, but in practice, it isn't used that way. There is only one head for Seaside3, and there is only one head for Linux, since effectively the Linux kernel is only one product with one gate keeper, and there is only one head for "trunk" too.

Fundamentally 3 years ago a small group of us recognised that innovating new features on just "one head" was a thing of the past for squeak, we already have 8 or more maintained forks of varying descriptions. That's what the pharo guys were doing too just innovating for themselves, and with every commit pharo was making it harder to maintain packages in common with squeak. The pharo team's response to this dilemma was to say "we dont care", the squeak team and the boards response to this dilemma 3 years ago was to say "we do care". We will write tools that fundamentally expect to fix, innovate and test against multiple forks. We can let pharo be the hare, but we can win in the long haul as the tortoise, because our innovations will be more carefully implemented and tested, and will be more useful to more people with existing code bases to support.

So as I was saying, it is an abstract point, that conceptually the way we think when we do development, is basically to swarm around a centralised resource, be it a repository, an image or a person. When we do this, we are signing up to depend on that resource for the longer term.

OK, I'm with you so far.

Along comes Mercurial, a new kid on the block with a new fundamental concept.

They put forward a different abstract idea fundamentally. When you use mercurial, every checkout/branch is a head, and is equal at every level and is indistinguishable from the original (In fact unlike, git and bzr, mercurial, only really supports any notion of centralised repositories, and a lightweight checkout because some users demanded it for pragmatic reasons)

With mercurial when you branch, you get everything. Your "head" is equal to and as good as anyone elses, and you could take your work to the moon, and forget the rest of the world exists, forever.

The equivalent in the squeak world is that when I branch to develop something on top of seaside3, I get the whole of the seaside repository to take with me, and I get my own seaside3 head. I can now make innovations to seaside locally, and I can provide a new seaside head to the world if I want to.

Now that is a silly idea isnt it, I hear you think, what would the world want with, and what is the use of, 15 different heads to a product that is obviously being developed by one team.

However, if you read the documentation, the Mercurial guys then recommend an entirely new approach to working. What you do, is you make a separate branch relative to a fixed point (A), (a release for example) for each new feature or bug fix, (B, C and D), (or developer working on a feature) in your product. This ensures that each feature may be tested and developed by itself, relative to a known starting point, the branch ancestor.

The result being that you locally get all the little deltas of each little change (B.1->B.2->B.3) you make when developing that feature, but when you come to publish, you also have one big delta (B.3 - A) for the whole feature. That big delta for that feature is not contaminated with the work on other features.

So, when the time comes to make a release you make a new fresh branch (A.2) from the old fixed point (A), you pull from each of the innovations in turn and merge them in (A.2 = A + (B3.-A)+(C.3-A)+(D3-A)), (this is the opposite of the above 1, in which the innovators all effectively push to a central repo. or gatekeeper). In addition, you don't then automatically require the developer of that new feature to continue his work from your new head (AA). He can continue to produce B.4 B.5 and B.6, so that when you merge in his work again. You merge (A3= A.2 + B.6-B.3).

Are you getting the point that the mercurial approach is a different paradigm, it is fundamentally distributed. (even though technically you can use it in a centralised manner)

So... I was suggesting that with Cuis, we could switch from a mindset that thinks centrally, to a mindset that thinks distributed.

At present there is conceptually one head for the world for everything, i.e. Squeak3.10 + 700 packages in squeak map.

My thought was that when you download a distribution built on cuis, you conceptually get all 700 packages, and all their history. When you work you adapt everything you need to work for cuis, and you ignore the rest of world. You could in fact over a very long weekend delete FileDirectory and port every single package to something better.

Then when you publish your result, it becomes a brand new distribution "Sooty", equal in status to the first, each of the packages you load is fully manageable in the context that it is being used. Others interested in your innovations can study them in context, and pull them as they desire.

I see what you're saying.

I started to write responses to a couple of other posts, but I realize that there are still things that I don't understand about your proposal. Please continue to help me understand.

Let's imagine that 3.10.2 just came out, and that we have your process in place. I'm assuming that we can equate 3.10.2 to A. The important part that I'm missing is that I don't know the time interval between A and A.2. Is it on the order of a week or two, or 6 months? Once I know the answer, I'll have more to say.

Also, you often refer to the codebase that you're developing against A that you will eventually want to move forward to whatever the latest is (maybe A.2, or maybe A.10). How often do you envision porting your packages forward to the latest? Every week or two? Every 6 months? Does it depend on the specific developer/codebase?

(BTW, I'm curious, can you cite an example of a successful project that uses this approach? If you can't, that doesn't automatically disqualify your idea (someone has to be first), but I'm still curious. Please, just a short yes or no, with no loss-of-face or giving-up-ground implied in a negative answer).

When you tell me that my bob process relying on Mantis is no good, as many have attempted to do. This criticism is based upon point scoring because they dont think that technically these tools would do it as well as they would like. Basically saying imho "mantis is crap so anything that uses mantis will also be crap", by definition.

What you fail to understand is that my bob process is not built on mantis, it is built on the abstract principle, that you start with a known fixed point and develop each innovation as a separate delta.

Then you can apply those deltas individually to several forks. If for some reason a delta doesn't work in a fork, then the fork can be fixed to address the problem. Fixing the fork actually results in all the forks converging to be closer to the original fixed point, and some essential commonality is preserved. Every innovation that you make for just your own image, that you do not make available for other forks to try, is potentially destroying commonality. Every innovation and patch that you make available for other forks to try is potentially improving commonality.

Mantis just happens to be the place where the fixes are at the moment. Several developers all innovate relative to that known fixed point. Bug fixers develop bug fixes relative to that known fixed point, and then the next release can be produced by cherry picking innovations that are actually complete, and bug fixes that are complete and tested.

So here is where "bob" could conceptually comes in...

With bob you can load your version of package A (e.g. Rio), as you maintain it in your local distribution, in your fork, and automatically test it. You make your "rio testing bob" open, so that anyone can add their distribution to the list. Bob downloads their image from their ftp site when it changes, and adds it to the test schedule. So, you can develop package A, seeing the impact you are making on every derived distribution in bobs list. When you see that package A's new feature is going to work for everyone, you can announce that feature and those who are interested can pull it over. At the same time, each user of package A, is also running the tests, so they get to see if they accidentally undermine package A, breaking by doing something silly.

You should cut people some slack, because you have been anything but consistent on this point over the past months. You're focusing on the abstract principles now, but at other times you've said that Bob/Mantis is good to go, and that we should start using it immediately.

Having said that, I'm comfortable with agreeing that criticisms of Mantis/Bob (i.e. the current concrete implementation) are out-of-bounds while we consider the abstract principles involved (of course, if we get to the point where you convince the community that you're correct in principle, then criticizing Mantis/Bob is back on the table as we decide *how* to implement your ideas).

Currently, in its technically limited way, using Bob, and Sake/Tasks, you can write a script made of a series of tasks that you think would pull 200 fixes and update to the latest packages to make 3.10 into 3.11.

Then you can run that script against 3.9, and low and behold, 95% of that script will execute. Any parts that need a tweak, can be tweeked by subclassing or overriding the task that failed. In this manner some fixes can be omitted, or extra ones loaded if needed.

Then you can run that same script against your production image based upon 3.9, and it might well pass too. If it does, and you fix your production image to work, then this means, that all the code in your production image, can migrate to 3.11 seamlessly.

The net result will be, that there will be a new monticello, squeakmap, sunit, in squeak 3.11, but also, there will potentially be a 3.9.2 with that same new monticello, squeakmap and sunit, and also a 3.8.4 with that same monticello, squeakmap and sunit. All generated and tested simultaneously.

If the pharo guys want to pull your 3.10-3.11 innovations, they simply add a subclass for pharo, let bob build Pharo1.0+(3.10 to 3.11 delta script) and see what works and what doesn't. Or they can see exactly what steps you went through to make 3.11, and they can cherry pick the ones they like. If the pharo guys made Pharo 1, from squeak 3.9 in the same manner then you could pull their innovations too. (this is the principle that the mercurial guys are aiming to support)

The more different forks, that load common fixes, (and I know not everything will work) the more compatability we will have, even though the kernels of the forks may be different.

Before you tell me that this wouldn't work, may I point out that LPF already did this for 8(?) different squeak forks, you can download 3.7-lpf, 3.8-lpf, cobalt-lpf etc etc.

In addition, Sake/Packages knows the package dependencies for all the packages that are loadable in 3.10, and 3.9, so bob can produce. 3.7-lpf + sake/packages = 3.7-build, 3.8-build, 3.9-build, cobalt2.0-build etc.

So, we can update and maintain 8 different forks to have the same scm tools, the same package management tools, and the same testing tools.

So... if we can achieve this by pushing out fixes and packages to different forks, then applying the same principles, of publishing the list of changes we make to move from, 3.10 to 3.11, as code. Other forks based on 3.10 can pull what they want of the changes, but they are not forced to accept everything we do. For example, I want a fork of 3.10 which uses Rio, so I wouldn't pull any of the fixes to FileDirectory.

The current situation is that "trunk" is the only head, and all contributors are working on it, because they are following their esteemed leader. The chances of removing FileDirectory from trunk is 0, because of the legacy, it will never happen.

However if I choose to fork 3.10 and make an image which doesn't have FileDirectory, (YAY!), then I am on my own, because "trunk" is no use to me. However if "trunk" innovations were of use to me, then I wouldn't be on my own.

3.11 with FileDirectory can be tracked to produce a parallel 3.11 with Rio full integrated and FileDirectory removed.. Seaside with FileDirectory can be tracked to produce a parallel Seaside with Rio.

eventually FileDirectory can die a graceful death.

its just an idea

OK, gotcha. Are we ready to proceed? (did I manage to avoid saying anything that you violently disagree with?)

Cheers, Josh

Keith

On Jan 24, 2010, at 12:00 PM, keith wrote:

...

BTW, now that we've agreed that it doesn't matter, do you concede the point that Monticello is substantially like git/mercurial/bazaar from a technical perspective, even if we're not using it in the way that the Mercurial folks advocate? ;-)

No because if it were true, firstly Gofer would never have been developed.

(looking up Gofer, which I was unfamiliar with... OK, got it)

We are not talking about the ability to work locally if you want to. We are talking about having all of the history of (in my case) some 60+ packages from different sources, locally, and providing a non-manual resync back to base when you get back on line again.

OK, I'm completely lost. What the hell are we talking about here?

I thought that we are talking about how Bob/Sake/Packages are a first attempt at a tool chain that can support the "Mercurial" approach to distributed development. Furthermore, we agreed that these tools aren't perfect, and that we would therefore make an effort to evaluate the ideas that the tools are an expression of.

Right?

Since we just established this one email exchange ago, and since I'm sure that you're good enough to extend to Monticello the same exemption from purely technical nitpicking, then I must conclude that the cited differences between Monticello and Mercurial are relevant with respect to the topic as I just framed it above.

Right?

So please explain to me...

Why is having the entire history of packages available locally *fundamentally* necessary for the development process that you're describing (as opposed to for your convenience while developing on the train)?

Why is providing a non-manual resync back to base *fundamentally* necessary for the development process that you're describing (as opposed to your convenience while developing on the train)?

I submit that the online/offline distinction is a diversion. It is orthogonal to the core question, and furthermore Monticello could be easily extended to add this functionality if required. If this is not true, please explain why, because I do not understand.

Leaving aside the online/offline distinction (unless you can explain why we shouldn't), I ask again: do you concede the point that Monticello is substantially like git/mercurial/bazaar from a technical perspective, even if we're not using it in the way that the Mercurial folks advocate?

Cheers, Josh

You can use "MC1.5's copy all (forked)", to grab the whole history of a package and keep it locally. if you want to, but that isnt really how the tool is designed to be used.

Keith

I see what you're saying.

I started to write responses to a couple of other posts, but I realize that there are still things that I don't understand about your proposal. Please continue to help me understand.

Let's imagine that 3.10.2 just came out, and that we have your process in place. I'm assuming that we can equate 3.10.2 to A. The important part that I'm missing is that I don't know the time interval between A and A.2. Is it on the order of a week or two, or 6 months? Once I know the answer, I'll have more to say.

Given that once A is out (a fixed point), work begins on migrating innovations in progress, to load into A, and fixes not yet integrated, to test them against A.

The automated script generating and testing "Ax-stable-alpha-test" image candidates, runs every (?) time a bug fix status is changed from "testing" to "passed" in mantis. So as soon as A is released, this script is switched to start loading and testing fixes against it.

Practically speaking, allowing for a 2 week break after the release to let the dust settle, a serious go at producing the next release candidate A.2-stable-beta should be made within a month and leaving a couple of weeks to finalise things. You are looking at a new fully tested release A2-stable (fixed point) every 4-6 weeks.

Also, you often refer to the codebase that you're developing against A that you will eventually want to move forward to whatever the latest is (maybe A.2, or maybe A.10). How often do you envision porting your packages forward to the latest? Every week or two? Every 6 months? Does it depend on the specific developer/codebase?

There are two builds happening simultaneously, A+1-unstable, (unstable builds on an image loading mantis fixes status "testing") and A+1- stable (builds on fixes status "passed"), and you can add your own, like A+1-stable+withnamespaces, A+1-unstable+closures etc.

So package developers can see what is coming, by checking the results of the "developer" image, or the "web" image that is built upon A+1- unstable.

The new A2.3.4 etc, are automatically used as a basis for building all derived images, such as the developer image, the web image, fun, and my own working image build etc. So it is quickly obvious when a package is failing to keep up, or a kernel patch is breaking things for everyone.

Given that the packages are at A.x-1, when you release A.x, for the tests to pass, you just need a version of the package that is compatible with two releases, the newest and the previous one to ensure a continuous migration path for everyone.

(BTW, I'm curious, can you cite an example of a successful project that uses this approach? If you can't, that doesn't automatically disqualify your idea (someone has to be first), but I'm still curious. Please, just a short yes or no, with no loss-of-face or giving-up-ground implied in a negative answer).

It's what I do every time I build an image to use, I have been using this process for several years, because squeak releases are few and far between.

Task 1. download the old release (A.0) Task 2. load the tested stable kernel fixes that I know I need. (Either from mantis, by number, or from a MC package that I use to maintain them, "Kernel-Extensions") Task 3. upgrade all the externally managed packages that the release has out of date versions of. Task 4. load all the packages that provide my basic tools Task 5. unload a few things. Task 6. reorganise stuff to make things a bit tidier. Task 7. (optionally) Save everything to monticello.

This was automated, and I save my actual working base image (A.1) that then build my product on, starting with the developer tools (optional), seaside, pier, rio, beach and magma.

Given that this process, is how I move an ageing release to be an image that is good enough to actually start working with. And I do this every month or two, and for every new client. I figured that the same process would be able to provide the monthly iterations, such that A.1 actually gets saved as 3.11.

You should cut people some slack,

Sorry but I was on my holiday when this all kicked off. Where was the slack for me?

This discussion all happened 3 years ago amongst members of the release team, and in the preparation of the proposal with the board. For 3.10 Everyone that was interested in the release was on the release-team list. Very few discussions were held on squeak-dev.

because you have been anything but consistent on this point over the past months. You're focusing on the abstract principles now, but at other times you've said that Bob/Mantis is good to go, and that we should start using it immediately.

Mantis, has been used for collating fixes for years. It is good to go. Automated loading of mantis fixes is provided by InstallerMantis. You can do it yourself using code along the lines of (I dont have an image open)

(Installer mantis allBugs select: [ :ea | ea status = "Testing" ]) do: #ensureFix.

We already had more fixes marked for integration than I could handle, in a single iteration. Effort would be better served packaging other innovations ready to be cleanly loadable into 3.10, such as closures.

I thought the board understood the abstract principles, since we discussed them in person with some people, and we had to write a proposal etc.

Having said that, I'm comfortable with agreeing that criticisms of Mantis/Bob (i.e. the current concrete implementation)

are out-of-bounds while we consider the abstract principles involved (of course, if we get to the point where you convince the community that you're correct in principle, then criticizing Mantis/Bob is back on the table as we decide *how* to implement your ideas).

OK, gotcha. Are we ready to proceed? (did I manage to avoid saying anything that you violently disagree with?)

you did ok.... would you like to run for the Board?

Keith

... and thanks again.

One thing that strikes me about this is that it is agnostic about how the fixed-point images are built.

The fixed point images need to be built, by a process which applies to the previous fixed point.

So that a fork which was made from the previous fixed point, can cherry pick from, and apply that process too.

The more that separate forks pick ideas from other forks, the more they have in common.

Basically to use the knowledge that is in trunk, you will have to analyse it and sort it into separate useful innovations and ideas, and publish them as separate changesets.

Ironically, most of those innovations could have started of as separate changesets in the first place. Am I making sense?

Keith

I contend that for the latter, it does not matter how the fixed- point image was created, just that you continuously build and test your application against frequent releases, and work with the community to quickly fix any compatibility issues that arise. Isn't this true?

Thanks, Josh

It would be lovely, but it just doesn't happen. Ask etoys, cobalt, sophie, gjallar. They all started large projects and did not find the time or the effort to track subsequent squeak releases. One problem is that individual releases were too revolutionary for many, trying to to do much in one go, this can be helped by release early and often. More than that the release teams didn't take any responsibility for the migration path. (e.g. Smalltalk -> SmalltalkImage)

This same problem occurs at a package level too. I am stuck about 150 (or more now) revisions behind in Pier, because my modifications to pier (which I do keep in a separate package), are effectively (but accidentally) a fork. In trying to solve the problem, the more I see the tools, i.e. Monticello as part of the problem. However at present the solution alludes me.

K.

Eliot wrote:

...

I suggest you do need to see http://www.ted.com/talks/lang/eng/clay_shirky_on_institutions_versus_collabo... and think about its implications.

and it seems to me you've only seen the surface. Of course we're moving from institutional to collaborative modes of interaction. This community already has. The underlying implications that you've missed are (for me, there are probably others)

The implication you have missed is that we discussed this 3 years ago, that we wanted the NON INSTITUTIONAL APPROACH. That is what the bob process was developed for.

Andreas then used the institution to IMPOSE his will, and instituted trunk, so we have regressed back to the institution dictating how development is done.

Keith

No. Trunk is an enabler, not an institution.

Trunk is a fork. It is one product serving one agenda.

We had already moved beyond this in detailed discussions with the board, recognising that squeak is no longer one product, we wanted a process that supports multiple products, and multiple forks, because that is the reality we are in, and so we specified the components to develop and the approach that would be required as a basis to enable this to happen.

Cross fertilisation cannot happen effectively if everyone is working to a moving target all of the time, and fixed points only occur once every 1-2 years.

What is needed conceptually is the following, fixed points every 2 months at the minimum, and each innovation packaged for that fixed point, or provided as a delta, relative to those fixed points. The number of big compatibility breaking innovations published per fixed point should be limited to 1 or two per month, in order not to overwhelm people with too much.

Then if you are a non-mainsteam fork (like cobalt) you can look at the innovation and work out how to port it to your local fork, because you can see the stable state of the other dependencies in the fixed point.

Please think about this. Then you will understand why trunk is a bad thing, it is the antithesis of what we actually decided we needed.

The squeak board doesn't count as much of an institution because it lacks funds. Trunk excludes no one, everyone has read rights.

The board is an institution if it acts like one. It is a dictatorship if it acts like one.

Trunk excludes me, I have made this clear several times.

Trunk only has one head, so it excludes anyone who wants to go in a different direction, or those who are already supporting images that are not trunk compatible, like me.

t is clearly not an obstacle to progress;

Trunk is an obstacle to progress, because I cant make my contributions to it.

Trunk is an obstacle to progress because we have to wait a year for a release, again!

Trunk is an obstacle to cross fertilisation of patches or innovations because it is a moving target.

Once we have smaller kernels

Trunk is not a fast route to smaller kernels, since no actual thought was put in to how you would get from A to B. Getting from A-B and back again if you want to, requires thought and tools to do so. This is why we developed the tools first, rather than throw a new image at the community with no tools.

we will be able to evolve the underlying execution machinery more easily and implement different object representations and more efficient garbage collectors, but the broader community won't be inconvenienced because their packages will still load. Assuredly however old images will be left behind, and the best way of bringing old code forward will be to publish it as a package and load it into a new image.

The best way of bringing old code forward, is to back-port the new api into the old image, so that you only need to maintain one codebase for both. When all of your packages are individually working in both the old image and the new, then you can migrate to the new image, and there is never a point at which anything stopped working.

For example, the change which merged ifNotNil: and ifNotNilDo: [:n | ]

If you do it your way, and have to port 60 packages, even ones you don't own, then you end up with months of what is effectively downtime, or months where you have to maintain two codebases.

What we really need as an essential starting point is actually the kernel image that we have talked about for so long. So thank you Juan Vuletich, thank you for your kernel image, I am sure it will go far.

And who is making the fastest progress towards that goal right now? You or Andreas and Juan?

Looks like it is Juan.

Are you helping them or hindering them?

Why cant it be, are they helping me or hindering me? Andreas is the new kid on the block when it comes to working towards a smaller image and multiple forks. I have been working on it for 3 years, tools first.

The board should not play favourites. I put 4 years of effort into squeak too you know. However I had to write a proposal, and get it voted upon. Andreas didn't because he used his position on the board to impose his non-plan. We already had a shared repository, it was called somewhat logically squeaksource.com/311

Andreas started by going backwards, he started with not understanding (which he later admitted), then not-communicating, he started by using squeak-dev when I specifically asked him not to. He started by instituting a process I could not contribute to, and he started by not building upon anything that we had worked on already.

This is just as rude as the pharo guys starting on 3.9 and insulting Edgar's long-suffering efforts.

We're free to make that choice. But even better were free to not make a false or forced choice. In the package world there is no insurmountable separation between Cuis and Trunk or Pharo or Etoys.

Yes there is if the packages are all being developed relative to a moving target.

Your rose-tinted view is to be expected as a low level guy. Those who simply write packages on top of their one chosen image, dont really get effected by this very much. This is why the pharo guys who are academics producing a package for the purpose of writing a paper or two dint understand this either and those who write all their code themselves dont understand what I am going on about.

However if you are building large systems which integrate on top of packages on top of packages, and between packages, then the number of moving targets ups the variables considerably, and at some point progress becomes impossible. Think fragile base class problem x 100.

Code is moving in packages between all of them (and in changesets when it can't be accomplished easily with packages). Open your eyes and ears man, and stop shouting at deaf ears.

Yep shouting at deaf ears is about right, you aint listening, and you aint understanding.

P.S. In offence of Godwin's law I can't help but see the metaphor between Keith's model of continuous integration of everything into everything else and of Clay Shirkey's institutions vs communities and of Stalinism and the fall of Communism. There are great virtues in socialism (change sets) but when institutionalised (bob) it becomes monstrous (inefficiency of maintaining pointless backwards compatibility). ;) ;) ;)

You got this a bit wrong, again you lot didnt bother understanding before pronouncing. Bob is the non-institutional tool, because it is a standalone service, that can get an image from anywhere, perform a task on that image and test it, without requiring the image to have any dependencies.

Trunk, requires you to have an image with a specific version of Monticello, and PackageInfo, MonticelloConfigurations, HTTPSocket, HTTPClient, Network, Compession etc etc etc.

My reference to facism, is primarily based upon the boards lack of willingness to define a constitution or boundaries for itself. This approach has been seen before. Secondly it appears that many members of the community here present do not have the moral fibre to see that if someone is mistreated, actual steps need to be taken to make sure it doesnt happen again. It is not ok. You are 51 years old, you have kids, you know this really.

cheers

Keith

2010/1/24 David T. Lewis lewis@mail.msen.com:

On Sat, Jan 23, 2010 at 09:48:33PM +0000, keith wrote:

...

My reference to facism, is primarily based upon the boards lack of willingness to define a constitution or boundaries for itself.

Folks,

Someone else has already pointed out that this language is offensive, and I was about to post a request that keith be removed from this list to stop the continuing slander and abusive personal attacks.

But then I remembered somebody mentioning Godwin's law, so I looked it up on Wikipedia, and I about fell out of my chair laughing.

But actually it is serious. It's not a joke when someone is attacking you or bullying you personally, no matter who you are. So let me be the first to say it - if the abusive behavior and language continues, I want to request that keith be removed from the squeak-dev list.

Meanwhile, let's all stop feeding the troll.

Yeah. God always wins, once you declare your opponent heretic. So many people killed in the name of God, and still keeping get killed.

Dave