Hello Squeakers!
First I would like to say... phew. :) We know you guys are waiting to see what the heck we are going to do and I am sorry for this report to be a day late or so. But when you read it I hope you will forgive us.
We know that the only thing worth anything is results - in every aspect of the word. So please keep your expectations at a reasonable level - we have had about 3 days now, mostly packed with communication - and while I do think we have quite a nice report here, 3 days aren't much at all. But we felt the pressure hard to get something OUT.
The last few days have been hectic to say the least - but despite our bumpy start - it feels things are now moving along nicely. Ok, enough chit chat.
Clarification -------------- I did post it separately, but here it is again.
By this leadership group being *temporary* in the announcement we *meant* it.
So hear us - 2006-02-15 at the LATEST, we will step down. We don't have the energy to go any longer than a year. Period. So if SqF hasn't delivered by then, we will either have to improvise and get a new group formed or we are all left hanging.
The more likely period for us is probably in around 6 months.
A Course Correction ----------------------- We want to make sure that we are seen as a legitimate leadership group by as many as possible in this community and Doug came up with a good idea to help doing that - by asking for the acknowledgement from the currently forming SqF... which is still forming, but we think it can be done. We will simply throw ourselves "at their feet". :) And we all like that idea.
Who and what is SqF? Since SqF hasn't yet made any real public postings and hasn't yet formed its own structure (but we think more will come very soon about that) we are taking the liberty of at least giving you an idea.
SqF (or what is called SqF formation) is currently a non-public mailinglist with 29 people. That list has a good cross section of people which includes all of the people in previous groups in charge of Squeak, the Guides, Squeak Central and several others. Of course, the list isn't by any means an elected representation of the community or anything like that, but it is the best we have at the moment.
Roughly this will be done by us presenting our group and as much as we can about how and what we want to do. This is all what we have said previously and are saying with this report, nothing else. The proposal will also include a veto mechanism in which SqF will be able to veto any action on our part, as a safety mechanism - details are sketchy.
Now, this can't be done until SqF gets a few mechanisms in place, like for example how to perform a vote :), but we are trusting in SqF to do so ASAP.
We hope this will clear up any misunderstandings about our intentions, and of course that it will turn out all for the best. It is *also* putting some pressure on SqF to actually get cracking. And if we fail to get the support from that group of people - then this initiative ends Right There. There is of course no point in even trying to lead the community in that case.
We are not stopping to wait for this support though - since as we have explained - we have no idea when that will be clear. Hopefully as soon as possible.
Organisation boring stuff ------------------------------ We have created a Swiki for our notes, todolists, simple rules on how we work together etc. We just now made it public readonly so that you all can see at all times what we are doing, but my advice is to read this report in full before going there:
http://anakin.bluefish.se/castaways
It will be moved to a more proper place on the new server when we have that geared up. And of course we have the alias to reach us all:
mysterious-island@discuss.squeakfoundation.org
Now, our group has gone through some changes. Unfortunately it seems the Mysterious Island book is haunting us a bit. In the book one person fell off the balloon (!) just before landing on the island, not sure what became of him actually. So unfortunately the same happened (not literally though) in reality so Michael Rueger will not be able to work with us in this group.
Michael is though still active in bringing the 3.8 release to a close, more on that below.
So we are now four and we will not try to replace Michael. We need to get cranking instead and there is no real point in extending the group because we are focusing on extensively using a team/task driven approach.
We also want to make clear that there is no internal hierarchy or anything like that in our group - the reason I am doing most of the talking is... well it beats me, it just turned out like that. :) So informally I might have ended up being a secretary/spokesperson, but that is ALL there is to it.
I personally do not like that I have ended up so overexposed, especially since several people have expressed serious doubts about my interpersonal skills, but I trust you to believe us when we say that there is no hierarchy at all.
Tasks and Teams ------------------- We are using a simple approach here. A task can be much anything. Each task has a team with a leader. On the castaway swiki there is a simple table that keeps track of the running tasks, who is the leader and also who of us (Doug, me, Marcus or Cees) is responsible on our side to track it. We don't keep track of who are the team members - that is just all up to the team leader.
The swiki has the current list of running tasks, but don't go there and spoil this report - read below instead. :)
Special Advisor ----------------- One REALLY good thing is that Dan Ingalls has offered to help us in the role of a "special advisor". Now, what is that? Who cares, it's Dan!! ;)
Well, but seriously Dan wants to give us his input on any and all issues so he is a full member but without the responsibilites. Which he likes fine. :) This means he also gets all our email and has write access to the Swiki etc. But he chooses himself how much he wants to do.
We are of course delighted to have Dan with us, especially since he is also joining in some of the tasks!
Contact persons ------------------ In order to get a better coordinated community "as a whole" we have also approached all the related "satellite projects" around Squeak and asked if they want to appoint a "contact person" that we can use to communicate with that project.
The current list of contacted such projects or communities are:
-Squeakland -SmallLand -Croquet, Andreas Raab confirmed -Tweak, Andreas Raab confirmed -Seaside, Avi Bryant confirmed -Tk4 -The Berne Guys, Stephane Ducasse confirmed -Japanese Squeak community, Yoshiki Oshima confirmed -Georgia Tech
The idea is that we are then able to send out questions and info and request potential feedback before going forward with certain plans that may affect the projects. The projects also get a channel for grabbing our attention if needed. We will start by sending out a general inquiry to get a feel of what the projects want in a longer perspective.
We will of course have this list published later with names of the contact persons we get. And if you know more such "satellite Squeak communities" that we have missed - please let us know.
Burning issues ----------------- We started trying to make an inventory of "burning issues" in the community. The current content of the list is known to most, but we need this list to get our bearings and to make priorities.
The list is available on the Swiki:
http://anakin.bluefish.se/castaways/2 ...and if you want to help us add more to that list - remember, this is an inventory - nothing more. Also, Ned has written quite a bit on these issues here:
http://bike-nomad.com/squeak/community2.html
I (Göran) am still distilling the above document to find bullets for the list. So again, here is a great place to help us out, because right now things are hectic and we surely are missing stuff. Just email.
Some of the issues there we are trying to deal with, but we will not remove any issue until it is solved, old and totally obsolete. Consider that list as our "collective pains". :)
Services --------- As many know we have a new community server called "box1". It can be reached at box1.squeakfoundation.org, but has no webface at this time. But lots of stuff are being consolidated to that server. Some quick facts:
- The machine is a virtual server running Debian with lots of bandwidth and disk. RAM is slightly more cramped, but no problem yet, and we can always just ask for more. - The machine is paid for using a PayPal account Cees set up a while back ready to take donations. And quite some money has arrived so the immediate need is definitely taken care of. - We are several people with root access that cooperatively maintain it. - SqueakMap, BFAV, a Subversion mirror and all new created lists are running there. - There is a file area which Bruce O'Neel has full control over (a Task btw): http://box1.squeakfoundation.org/files - There is a nightly backup running to a server at Bluefish, but we gladly add another one somewhere. - Rsync is on the box so that anyone can easily set up a mirror of the file area. - We have mirrored over the current www.squeak.org and we have Dan ready to repoint it to the new server any day now.
... and probably quite a few more things is there that I am forgetting now.
There is also an ongoing Task to create a new nice website and it will be hosted there of course. Stephane leads that task and Bruce is working on the design and a bunch of other people are also involved. The new site will be wiki-editable with a team to do the editing. But Stephane can tell you more on that. I can only tell you that the sneak peak I have seen looks SLICK AS HELL. :)
Release of 3.8 ---------------- We have talked to Michael Rueger about the 3.8 release and it is almost ready. There are only a very few items on the todo list left. Michael Rueger and Bert Freudenberg together with us 4 will try to wrap it up. I don't think we need more manpower to do that, but if so we will find it, and if you want to help - we aren't *stopping* you. :)
We have agreed together with Michael to set the release date to 1st of march.
Up, Up and Beyond ---------------------- Hehe, that heading puts on some pressure, now doesn't it? :)
So what about 3.9 and after that?
This is not a full description of everything that we think we should do - we have "only" picked two specific tasks that we are sure we want to push really hard and like us all to rally around.
Also, don't take anything here as written in stone, it is of course all up to the community to work together in all this. We just hope it sounds good and that you will join us. :)
Note that this section does NOT deal with a lot of the things already proposed for 3.9 - "Stefs roadmap". We just haven't had time to go through that yet nor foster a good discussion around it in the community - that is on our immediate todo list though and a thread will be started right after this report has been posted. Then we discuss it all together and we get those things nailed down.
Now, given all that... (deep breath) this is what we want to do.
ToolBuilder! ------------- As many have seen the recent discussions on Tweak, Morphic etc spurred Andreas to write a little abstract UI framework that gives just the functionality that most of our tools need. Then it maps to the different backends (Morphic, Tweak, MVC etc). Andreas being who he is :) quickly worked something up and people started to join the fray. This little project has a good momentum and we want to push this even harder.
Andreas started this great initiative, and we want very much for this layer to become an official package in Basic as of 3.9. This also means we want a dedicated maintainer with at least one co-maintainer of it and a team/task for making this happen.
So the question is who wants to be team leader on this? Andreas? Avi? Anyone else?
As for us - we intend to put our own efforts into this - Cees is already involved, I will start with porting SqueakMap Package Loader over to it and I think/hope Marcus will do SUnit.
This project has a list of its own that you can join at:
ui-subscribe@discuss.squeakfoundation.org
Now, we believe this package will be *emintently* important given the second thing below...
MinimalMorphic! ------------------- This part is a bolder move. We are starting a task with Cees de Groot as team leader called MinimalMorphic.
The task will run *in parallell* with the ongoing regular work on 3.9 and track 3.9 as the base. The job is to create an automated procedure that brings/shrinks the 3.9 image down to a lean and clean tools-only Morphic image. Or possibly also down to MVC, but that is up to the team.
The side product of this work is meant to be a loadable RestOfMorphic package and an eToys package. Or at least a RestOfMorphic package including eToys, that is also up for the team to find out.
This is a hard job and involves cleaning up Morphic to its original simplicity and tweaking the tools to only use that part of Morphic. Dan Ingalls wants to be a part of this work (yes!) and Juan Vuletich has already announced his interest/intentions in working on this, which is just great. And there have been quite a number of people discussing these aspects recently. Cees will contact people and get the team together and anyone interested to help should of course talk to Cees.
This procedure will not actually be applied to the 3.9 update stream, so 3.9 will be a "traditional fat" release, and exactly what 3.9 entails is that other "Stef roadmap"-thread we will start ASAP. But when 3.9 is released the MinimalMorphic procedure will be appliable to it and available on SM, which is a nice thing.
The first thing for the 4.0 release is to actually apply the MinimalMorphic procedure in the update stream. Bam! 4.0 will start its life as a lean and mean Morphic machine. :) We of course then also let 4.0 get a shrunk V4.sources and an almost empty .changes file.
Now, the ToolBuilder is a very important part of this dance - it defines the needs of the tools and will make it easier to see exactly what this small Morphic needs to deliver. So as we said before, it should enter 3.9 Basic as soon as we can make it. And since 3.9 is the last release with MegaMorphic intact as it looks today it will give the tool maintainers time to move over to ToolBuilder so that the tools will work in the new lean world of 4.0.
There are of course lots of open questions and details to all of this but this is it - this is what we want to focus hard on. Of course it doesn't preclude other ongoing things, like getting the PackageInfo bit working and getting started on TFNR (assigning maintainers to parts of the image, without actually ripping them out) - I and Doug are still very much going to focus on that during the 3.9 period.
Finally we would like to thank Avi for making us look in this direction and Dan for pushing us even further than we first dared, as Dan so well put it himself - "it's ballsy". :) But with Dan on board and the current energy level in the community (Can you feel it?) we think we can all pull this off.
Final word ------------ We are aware that there are some members of this community that don't trust us, at least not yet. We are also aware of a large number of people that have expressed their support in full, and a lot of it in private.
So the only question worth asking now is... are you prepared to give us the benefit of the doubt and work with us? We are NOTHING without you.
While we both are trying to get teams cracking on concrete things, we also will continute to look at the burning issues list and try to improve our processes. But we gotta have something to do next week too. :) :)
We are now moving over from the planning/communication phase to the "doing it" phase. We hope you join us in all the work ahead. Let the fun begin. :)
regards, Doug, Göran, Cees (Marcus, see below)
PS. Marcus is part ill, part overwhelmed by other things at this point. He is in catch-up mode and hasn't had time to fully catch up yet.
goran.krampe@bluefish.se wrote:
Now, our group has gone through some changes. Unfortunately it seems the Mysterious Island book is haunting us a bit. In the book one person fell off the balloon (!) just before landing on the island, not sure what became of him actually. So unfortunately the same happened (not literally though) in reality so Michael Rueger will not be able to work with us in this group.
Hi Göran,
Very interesting and presented with a nice wording ;-) It even puts another aura of mystery around all this, not only that 29 people are working in parallel with other teams, all of them in stealth mode of course, but Michael fell off the balloon!
The more often I read this, the more I see the humorous side of your coup. So here is my first question, which if I understood you correctly, you are glad to answer:
What happened?
Regards, Martin
On 18/02/05 13:20, "goran.krampe@bluefish.se" goran.krampe@bluefish.se wrote:
MinimalMorphic!
This part is a bolder move. We are starting a task with Cees de Groot as team leader called MinimalMorphic.
The task will run *in parallell* with the ongoing regular work on 3.9 and track 3.9 as the base. The job is to create an automated procedure that brings/shrinks the 3.9 image down to a lean and clean tools-only Morphic image. Or possibly also down to MVC, but that is up to the team.
The side product of this work is meant to be a loadable RestOfMorphic package and an eToys package. Or at least a RestOfMorphic package including eToys, that is also up for the team to find out.
This is a hard job and involves cleaning up Morphic to its original simplicity and tweaking the tools to only use that part of Morphic. Dan Ingalls wants to be a part of this work (yes!) and Juan Vuletich has already announced his interest/intentions in working on this, which is just great. And there have been quite a number of people discussing these aspects recently. Cees will contact people and get the team together and anyone interested to help should of course talk to Cees.
This procedure will not actually be applied to the 3.9 update stream, so 3.9 will be a "traditional fat" release, and exactly what 3.9 entails is that other "Stef roadmap"-thread we will start ASAP. But when 3.9 is released the MinimalMorphic procedure will be appliable to it and available on SM, which is a nice thing.
The first thing for the 4.0 release is to actually apply the MinimalMorphic procedure in the update stream. Bam! 4.0 will start its life as a lean and mean Morphic machine. :) We of course then also let 4.0 get a shrunk V4.sources and an almost empty .changes file.
I wish help here , if someone as always could find a way to break things is useful :-).
I could test on Mac 9, 10 and Windows.
And tell how is the world viewed "Desde el Sur".
Edgar
On Fri, 18 Feb 2005 17:20:08 +0100, goran.krampe@bluefish.se goran.krampe@bluefish.se wrote:
This part is a bolder move. We are starting a task with Cees de Groot as team leader called MinimalMorphic.
The side product of this work is meant to be a loadable RestOfMorphic package and an eToys package. Or at least a RestOfMorphic package including eToys, that is also up for the team to find out.
Finally we would like to thank Avi for making us look in this direction and Dan for pushing us even further than we first dared, as Dan so well put it himself - "it's ballsy". :)
Since you bring me up, just a small note: as I made clear in my original suggestion, I think it's crucially important that the RestOfMorphic package be ackowledged as a main focus (I'd say, *the* main focus) of this effort. Calling it a "side product" gives me pause. If we're trying not to fragment the community, then the silent majority of Squeak users who rely on eToys can't feel left behind. There's been a lot of good and necessary work already on simply stripping down a Morphic image, but the much harder and equally necessary part, which will require a lot of leadership, coordination,and elbow grease, is getting the RestOfMorphic together to file back in.
I'm pretty sure that the castaways already know this, but I think it's an important thing to make clear and keep clear as the work proceeds.
Avi
Avi Bryant wrote:
Since you bring me up, just a small note: as I made clear in my original suggestion, I think it's crucially important that the RestOfMorphic package be ackowledged as a main focus (I'd say, *the* main focus) of this effort. Calling it a "side product" gives me pause. If we're trying not to fragment the community, then the silent majority of Squeak users who rely on eToys can't feel left behind. There's been a lot of good and necessary work already on simply stripping down a Morphic image, but the much harder and equally necessary part, which will require a lot of leadership, coordination,and elbow grease, is getting the RestOfMorphic together to file back in.
Hopefully, nobody wants to see eToys or any other project left behind. But perhaps these worries are just a tempest in a teapot. Let's presume, for a moment, that some feckless renegades come out with a very powerful and modular image that that happens to change the internals of what they call "Morphic" beyond all recognition, and this group has the temerity to pronounce to the community that they have just released Squeak 4.0. Just who the heck are these guys? Soon after, another group comes along with a package for this interloper "Squeak" that has some amazing new multimedia abilities. What suckers -- don't they know that "Squeak 4.0" isn't really Squeak? The eToys crowd looks on in horror. But wait...they notice that the new package is, well, a package. It's got a clean API, it's loadable and removable. Can't the eToys guys just file it into their image? Please don't take this as glib. But it begs the question, what *exactly* does it mean to leave eToys behind? As long as Plugins for Squeak 4.0 work more or less like the plugins for 3.X, and as long as the Collections-* and Kernel-* and etc classes look about the same, chances are they will benefit along with everyone else from new and exciting packages. When we ask "Don't leave eToys behind?", do we mean that the eToys project shouldn't have to work too hard to benefit from advances in Squeak, like anyone else, or that all the work should be done for them by all groups with any interest in Squeak?
On Sat, 19 Feb 2005 16:20:24 -0500, Steven Swerling sswerling@yahoo.com wrote:
When we ask "Don't leave eToys behind?", do we mean that the eToys project shouldn't have to work too hard to benefit from advances in Squeak, like anyone else, or that all the work should be done for them by all groups with any interest in Squeak?
What Avi wanted to say I think, and what I second, is that this 4.0 project will have *two* major things:
- a minimal Morphic in the image; - a RestOfMorphic+Etoys loadable package (or packages if a further split-up is warranted).
So everything that gets 'thrown away' from MinimalMorphic will be immediately added to RestOfMorphic, so that at release time, we will be able to build and distribute the Full image lots of people so love (I love it for showing off Squeak's capabilities, for example ;-))
I'm just back from a Scouting weekend, so I'm dirty and smelly -> a shower is first on the to-do list after catching up with mail, but if anyone wants to jump in on this project, please make it known. If people have ideas on how to go about coordinating this refactoring effort, I'd be glad to hear your ideas. Note that the whole stripping/refactoring project will assume that ToolBuilder is around, so it might be an idea to take a peek at it - the list's archive is accessible on http://discuss.squeakfoundation.org/cgi-bin/ezmlm-cgi?4:iis:3:200502#b (we still need to get our head around ezmlm web archiving, most notably what the correct 'entrypoint url' should be - if anyone can help there, please shout).
Hi!
Steven Swerling sswerling@yahoo.com wrote: [SNIP]
When we ask "Don't leave eToys behind?", do we mean that the eToys project shouldn't have to work too hard to benefit from advances in Squeak, like anyone else, or that all the work should be done for them by all groups with any interest in Squeak?
Hehe, indeed. Now, we should of course take great care in making sure RestOfMorphic is installable and all that. And we can even make an effort finding maintainers for it and helping them get started etc.
But in the end I agree with you, the rest of us (not eToys users or developers) can't maintain it in the long run or be expected to either.
regards, Göran
The general release plan sounds great: clean up 3.8/3.9, then for 4.0 focus on partitioning. (please. PLEASE. stop speaking in codewords like "TFNR". It causes people who might want to help, to click "delete" because they don't even know what the message is about.)
However, two important items were left off the list:
1. Work out a way to release a set of packages this time, and not just an image. If this is nothing else than a zip file with a bunch of packages in a subdirectory, that would be fine. We really need this to give people a stable basis for working in Squeak -- especially as more and more stuff ends up in packages.
2. Get a bug tracker going so that we can see what specific packages have open release-critical bugs in them. Otherwise, the work in #1 is much less useful, because we have no way to tell how stable different packages are.
Additionally, the UI abstraction task is fine but seems relatively unimportant compared to these other items. How muh code, really, is going to find it useful to target 5 different UI's? Some, to be sure... but the above two items are easy and important. Without them, dividing the image into packages can actually *hurt* people who want to use Squeak (instead of developing it further).
For motivation, just picture someone who wants to develop software in Squeak, but not take part in developing Squeak itself. They decide they want to try Monticello... boom. Why boom, when it's available on SqueakMap? Because they are using a 3.5 image, because 3.6 and 3.7 broke their networking code, and because 3.8 and 3.9 seem too unstable, and because people keep posting new packages to 3.5 without thoroughly testing them. It should be normal that people can actually use stable releases to develop in, but doing so is a hassle if both (a) everything is in packages and (b) there are no stable releases of packages.
Lex
Hi Lex!
"Lex Spoon" lex@cc.gatech.edu wrote:
The general release plan sounds great: clean up 3.8/3.9, then for 4.0 focus on partitioning.
Mmmm, that is not exactly what the report says though. :)
We wrote that the partitioning work (staking out the image using PI (or similar) and assigning parts to maintainers) should start ASAP in the 3.9 cycle, not in 4.0. This is one of the bits that the Packages Team will do IMHO. That Team isn't formally formed yet because the Team leader question is still open - but I did create the mailinglist yesterday:
packages-subscribe@discuss.squeakfoundation.org
But the Morphic split will not happen until 4.0, that is true.
(please. PLEASE. stop speaking in codewords like "TFNR". It causes people who might want to help, to click "delete" because they don't even know what the message is about.)
Sure, I can stop using that acronym, no worries. I just thought most of us do know what it is.
However, two important items were left off the list:
- Work out a way to release a set of packages this time, and not just
an image. If this is nothing else than a zip file with a bunch of packages in a subdirectory, that would be fine. We really need this to give people a stable basis for working in Squeak -- especially as more and more stuff ends up in packages.
Sounds reasonable. I assume you and I (and the rest) will discuss it further on the Packages Team.
- Get a bug tracker going so that we can see what specific packages
have open release-critical bugs in them. Otherwise, the work in #1 is much less useful, because we have no way to tell how stable different packages are.
For the "official packages" and for the staked out partitions of the image I simply think we should use Mantis just like we already do. We already use it for the image and for some packages.
But the specifics for 3.9 in this regard is for the Janitors Team formed by Ken Causey.
Additionally, the UI abstraction task is fine but seems relatively unimportant compared to these other items. How muh code, really, is going to find it useful to target 5 different UI's? Some, to be sure... but the above two items are easy and important. Without them, dividing the image into packages can actually *hurt* people who want to use Squeak (instead of developing it further).
Just a note - the partitioning effort is not primarily focused on actually turning those parts into packages (that are external to the image). This I think you are aware of.
And getting ToolBuilder into 3.9 is an important piece of the puzzle for 4.0 - as I think the report explained. It will not be primarily important for 3.9 itself.
For motivation, just picture someone who wants to develop software in Squeak, but not take part in developing Squeak itself. They decide they want to try Monticello... boom. Why boom, when it's available on SqueakMap? Because they are using a 3.5 image, because 3.6 and 3.7 broke their networking code, and because 3.8 and 3.9 seem too unstable, and because people keep posting new packages to 3.5 without thoroughly testing them. It should be normal that people can actually use stable releases to develop in, but doing so is a hassle if both (a) everything is in packages and (b) there are no stable releases of packages.
This we all agree on I think.
Lex
regards, Göran
goran.krampe@bluefish.se wrote:
- Get a bug tracker going so that we can see what specific packages
have open release-critical bugs in them. Otherwise, the work in #1 is much less useful, because we have no way to tell how stable different packages are.
For the "official packages" and for the staked out partitions of the image I simply think we should use Mantis just like we already do. We already use it for the image and for some packages.
Yes, but what about for other packages? Mantis is not effective for them, because it does not target bugs at individual packages. It has some notion of "projects", which might be usable, but not until something is done to make the list have an option for every package.
Without a decent bug tracker, we can't do a great job of releasing stable sets of packages.
-Lex
On Wed, 2 Mar 2005 21:46:41 -0400, Lex Spoon lex@cc.gatech.edu wrote:
Yes, but what about for other packages? Mantis is not effective for them, because it does not target bugs at individual packages. It has some notion of "projects", which might be usable, but not until something is done to make the list have an option for every package.
The simplest thing that could possibly work is to have an email address with every package. People can send bug reports to the email address; individual package maintainers can choose how to deal with them: the email address can point to Mantis, a Request Tracker installation, a Source Forge account, or a homebrew Squeak app.
I hardly think we want to build another SourceForge for Squeak, and even if we want to we should make it so that participating is optional.
On Thu, 24 Feb 2005 20:49:23 -0400, Lex Spoon lex@cc.gatech.edu wrote:
Additionally, the UI abstraction task is fine but seems relatively unimportant compared to these other items. How muh code, really, is going to find it useful to target 5 different UI's?
Ehh... mostly all of the development tools? Plus it's the basis for defining the targets of the morphic untanglement thing, which will likely cut and and partition some major chunks of the image.
Cees de Groot cg@cdegroot.com wrote:
On Thu, 24 Feb 2005 20:49:23 -0400, Lex Spoon lex@cc.gatech.edu wrote:
Additionally, the UI abstraction task is fine but seems relatively unimportant compared to these other items. How muh code, really, is going to find it useful to target 5 different UI's?
Ehh... mostly all of the development tools?
As you know, those already work in all the UI's. Thus a UI abstraction does not help them; it only pretties them up. Pretty code is nice but should not be on the top of this priority list.
Plus it's the basis for defining the targets of the morphic untanglement thing, which will likely cut and and partition some major chunks of the image.
That's a better reason, but it doesn't seem like a very high priority. It's clearly a lower priority than setting up infrastructure to support the partitioning. Chopping Squeak into even tinier bits, is not useful if we end up keeping all the bits in the monolithic image because no one bothered to put together the proper infrastructure.
This is a cool project. I am just saying that there are higher priorities for the Squeak community at large.
-Lex
On Wed, 2 Mar 2005 21:40:36 -0400, Lex Spoon lex@cc.gatech.edu wrote:
As you know, those already work in all the UI's.
Hmm... Last time I looked, they didn't all work in wxSqueak. And lots of them don't work in Seaside. And I know of a couple that don't work in MVC.
That's a better reason, but it doesn't seem like a very high priority. It's clearly a lower priority than setting up infrastructure to support the partitioning.
Well, clearly in your eyes. It's a sort of catch-22, as long as the image is not partitionable, there's no need to install partitioning support, and vice versa. So we need to tackle this issue from two sides, and this is one of the project that has started chopping away from the other side.
On Thursday 03 March 2005 11:18 pm, Cees de Groot wrote:
As you know, those already work in all the UI's.
Hmm... Last time I looked, they didn't all work in wxSqueak. And lots of them don't work in Seaside. And I know of a couple that don't work in MVC.
Like, for instance, the Refactoring Browser.
Really, it's a bit of a pain right now to use both Morphic and MVC, and it's made worse by the fact that there are now widgets and menus that one can make on Morphic but not on MVC.
Ned Konz ned@squeakland.org wrote:
Really, it's a bit of a pain right now to use both Morphic and MVC, and it's made worse by the fact that there are now widgets and menus that one can make on Morphic but not on MVC.
I'd say the best answer would be to get morphic to a state where it actually works well enough / fast enough to allow dumping MVC. Probably only be a few person-decades of work.
tim -- Tim Rowledge, tim@sumeru.stanford.edu, http://sumeru.stanford.edu/tim Strange OpCodes: JTC: Jump To Conclusions
Tim Rowledge wrote:
Ned Konz ned@squeakland.org wrote:
Really, it's a bit of a pain right now to use both Morphic and MVC, and it's made worse by the fact that there are now widgets and menus that one can make on Morphic but not on MVC.
I'd say the best answer would be to get morphic to a state where it actually works well enough / fast enough to allow dumping MVC. Probably only be a few person-decades of work.
Maybe Tweak will get there first?
Jimmie
Jimmie Houchin jhouchin@cableone.net wrote:
Maybe Tweak will get there first?
I guess we'll see.
tim -- Tim Rowledge, tim@sumeru.stanford.edu, http://sumeru.stanford.edu/tim Useful random insult:- Lightbulb over his head is burned out.
Le 2005/02/19, Avi Bryant avi.bryant@gmail.com écrivait :
as I made clear in my original suggestion, I think it's crucially important that the RestOfMorphic package be ackowledged as a main focus (I'd say, *the* main focus) of this effort.
I totally agree with Avi on that. I read all the stuff around the new leadership and the Report 1 from Göran and I agree with the plan...and the people who forms the new leadership... The point brought by Avi is the only one left which seems a really important one.
Raymond
Hi guys!
Raymond Asselin raymondasselin@sympatico.ca wrote:
Le 2005/02/19, Avi Bryant avi.bryant@gmail.com écrivait :
as I made clear in my original suggestion, I think it's crucially important that the RestOfMorphic package be ackowledged as a main focus (I'd say, *the* main focus) of this effort.
I totally agree with Avi on that. I read all the stuff around the new leadership and the Report 1 from Göran and I agree with the plan...and the people who forms the new leadership... The point brought by Avi is the only one left which seems a really important one.
Yes, I agree with you guys on this. My wording was slightly unfortunate. Of course RestOfMorphic is a primary deliverable. Maintaining it later on though will inevitably be up to the interested parties - that is just how it works.
Raymond
regards, Göran
squeak-dev@lists.squeakfoundation.org