Hi all
I have been thinking about the next steps. Here are a list of propositions for 3.10/4.0 that I would like to work on and welcome company. Ideally I would like to build a group of people that have fun to work on these items. We could even try to have some regular chats one day a week and FUN.
I think that Squeak 10/4 should not be compatible to free us but at the same time it should prepare the coming of new assets (sophie/tweak).
Here are the main actions I would like to see happening:
- be able to load Tweak
- be able to load Sophie infrastructural elements (ressource location...) => even substitute current Squeak ones with sophie ones (Rome renderer)
- curve/remove Etoy/projects (without having to reload them)
- remove nebraska and others/ remove packages early in the process
- new compile method format if available else klaus fix for source limits
- may be newcompiler if ready
- aggressive cleans in a lot of areas
- look at Pavel overrides problems => ideally be able to use Pavel image as a basis for 10/4
- Use tool builder (looking at the tool plus) and change the current tools (the ones that deserve migration)
- more tests
- may be using MC2 if ready
- better integration of AST and refactoring support
So if you want to help there on a regular basis or on specific items please say it
Stef
Stéphane Ducasse puso en su mail :
Of the long list, I have deep wish to help in:
- curve/remove Etoy/projects (without having to reload them)
- remove nebraska and others/ remove packages early in the process
look at Pavel overrides problems => ideally be able to use Pavel image as a basis for 10/4
So, if you think I could do something useful ....
Edgar
__________________________________________________ Preguntá. Respondé. Descubrí. Todo lo que querías saber, y lo que ni imaginabas, está en Yahoo! Respuestas (Beta). ¡Probalo ya! http://www.yahoo.com.ar/respuestas
On Sun, 15 Oct 2006 10:40:42 +0200, Stéphane Ducasse wrote:
Hi all
I have been thinking about the next steps. Here are a list of propositions for 3.10/4.0 that I would like to work on and welcome company. Ideally I would like to build a group of people that have fun to work on these items.
...
- new compile method format if available else klaus fix for source
limits
Tim, what are your plans with my "inspiration" on source files' limits.
- may be newcompiler if ready
I'm contributing to decompiler as much as I can. But the way I understand Squeak community is, the new compiler will *not* make it into mainstream. So it can only be distributed as an optional package, and besides the package owner's own priorities IMO there is no 3.10/4.0 deadline for the new compiler.
- look at Pavel overrides problems
=> ideally be able to use Pavel image as a basis for 10/4
After all the mistakes from the past, *not* accepting Pavel's overrides will only split the community further.
So if you want to help there on a regular basis or on specific items please say it
As said above, I'm working on the new decompiler.
/Klaus
Stef
I don't know what other people think, but these long feature lists just give me the shivers. What if instead of listing feature X, Y, and Z (on many of which the implementation hasn't even started) we simply have a schedule that says:
a) Open discussion: Two months of determining what's ready to go into the next release. At the end of the that period there should be a list of things that we'd like to have in the next release.
b) Alpha phase: Two months of "getting stuff in" for those things that we agreed upon in the first phase. At the end of this phase, any new feature that isn't in yet, won't get in.
c) Beta phase: Two months of testing, fixing bugs updating the docs and packages at Squeakmap. At the end of which we have a new release.
Six months, and it should be done. With clear deadlines what is expected to happen when. With proposals made by the people who have done the work already. With work that is already finished and only needs inclusion instead of stuff on which work hasn't even begun yet.
Cheers, - Andreas
Great idea. We also need some kind of list (on a website) that shows what things are out there that need work, so people looking for something to do know where to look. I know the bug reports provide this a little, but I really see a bug list as something different then a "needed features" list.
From: Andreas Raab andreas.raab@gmx.de Reply-To: The general-purpose Squeak developers listsqueak-dev@lists.squeakfoundation.org To: The general-purpose Squeak developers listsqueak-dev@lists.squeakfoundation.org Subject: Re: Roadmap proposal for 3.10/4.0 Date: Sun, 15 Oct 2006 12:04:44 -0700
I don't know what other people think, but these long feature lists just give me the shivers. What if instead of listing feature X, Y, and Z (on many of which the implementation hasn't even started) we simply have a schedule that says:
a) Open discussion: Two months of determining what's ready to go into the next release. At the end of the that period there should be a list of things that we'd like to have in the next release.
b) Alpha phase: Two months of "getting stuff in" for those things that we agreed upon in the first phase. At the end of this phase, any new feature that isn't in yet, won't get in.
c) Beta phase: Two months of testing, fixing bugs updating the docs and packages at Squeakmap. At the end of which we have a new release.
Six months, and it should be done. With clear deadlines what is expected to happen when. With proposals made by the people who have done the work already. With work that is already finished and only needs inclusion instead of stuff on which work hasn't even begun yet.
Cheers,
- Andreas
Yes we should do that.
Great idea. We also need some kind of list (on a website) that shows what things are out there that need work, so people looking for something to do know where to look. I know the bug reports provide this a little, but I really see a bug list as something different then a "needed features" list.
Andreas Raab wrote:
I don't know what other people think, but these long feature lists just give me the shivers. What if instead of listing feature X, Y, and Z (on many of which the implementation hasn't even started) we simply have a schedule that says:
a) Open discussion: Two months of determining what's ready to go into the next release. At the end of the that period there should be a list of things that we'd like to have in the next release.
b) Alpha phase: Two months of "getting stuff in" for those things that we agreed upon in the first phase. At the end of this phase, any new feature that isn't in yet, won't get in.
c) Beta phase: Two months of testing, fixing bugs updating the docs and packages at Squeakmap. At the end of which we have a new release.
Six months, and it should be done. With clear deadlines what is expected to happen when. With proposals made by the people who have done the work already. With work that is already finished and only needs inclusion instead of stuff on which work hasn't even begun yet.
Cheers,
- Andreas
+1
Isn't the list that Stef is starting the same list you propose be produced after the first two months?
Don't get me wrong, a plan is a good thing to have I'm just trying to understand how you wont end up with a big list that will give you the shivers... :o)
Z.
Andreas Raab wrote:
I don't know what other people think, but these long feature lists just give me the shivers. What if instead of listing feature X, Y, and Z (on many of which the implementation hasn't even started) we simply have a schedule that says:
a) Open discussion: Two months of determining what's ready to go into the next release. At the end of the that period there should be a list of things that we'd like to have in the next release.
Zulq Alam wrote:
Isn't the list that Stef is starting the same list you propose be produced after the first two months?
It could end up being similar, but the main difference is that I'm not willing to consider anything that hasn't been done already. Out of that list there were two items that I would consider "ready for inclusion" (which really means: ready for discussion), namely Klaus' fix for the source code management and some of the fixes that Pavel needs. None of the other items on the list are even close to being considered ready for inclusion; on many of the items work hasn't even started.
And *if* any items on that list get done in the first two months we can decide to include them. But I don't want to start out with a long list of features that nobody has the time and the energy to implement.
Don't get me wrong, a plan is a good thing to have I'm just trying to understand how you wont end up with a big list that will give you the shivers... :o)
Simple: By strictly not doing anything "new" but rather only pick from what's already there. The release process isn't the place to start new projects, it's the place to select from the existing projects those that should be part of the next release.
Cheers, - Andreas
I disagree on that one. I think that we can have a vision and create a group that works on that vision. I do not see a problem even if people want to do something and fail. This does not mean that we should not reasonable goals.
Removing Etoy for example, (even if pavel already did it is something) that could and should be done.
It could end up being similar, but the main difference is that I'm not willing to consider anything that hasn't been done already. Out of that list there were two items that I would consider "ready for inclusion" (which really means: ready for discussion), namely Klaus' fix for the source code management and some of the fixes that Pavel needs. None of the other items on the list are even close to being considered ready for inclusion; on many of the items work hasn't even started.
And *if* any items on that list get done in the first two months we can decide to include them. But I don't want to start out with a long list of features that nobody has the time and the energy to implement.
Don't get me wrong, a plan is a good thing to have I'm just trying to understand how you wont end up with a big list that will give you the shivers... :o)
Simple: By strictly not doing anything "new" but rather only pick from what's already there. The release process isn't the place to start new projects, it's the place to select from the existing projects those that should be part of the next release.
Cheers,
- Andreas
+1
I think it would be good to have a more formal process. It would be nice if we could have a single place to go to see what is going on, who is working on what and if there is any progress. I like the idea of organizing around current contributions and providing a structure so that everyone can understand the process of harvesting changes for adoption in the main image.
It would also, as Andreas suggested, be a good idea to voice support for activities in process, so that those efforts can be encouraged and supported by anyone with spare time before adoption is considered.
Beyond that each team gains momentum and organization in its own way and it seems to me that persuading the community in any direction is very difficult. I have seen really cool stuff evolve by itself.
So my suggestion is push for organization but accept the chaos that is Squeak.
Ron Teitelbaum
-----Original Message----- From: squeak-dev-bounces@lists.squeakfoundation.org [mailto:squeak-dev- bounces@lists.squeakfoundation.org] On Behalf Of Andreas Raab Sent: Sunday, October 15, 2006 3:05 PM To: The general-purpose Squeak developers list Subject: Re: Roadmap proposal for 3.10/4.0
I don't know what other people think, but these long feature lists just give me the shivers. What if instead of listing feature X, Y, and Z (on many of which the implementation hasn't even started) we simply have a schedule that says:
a) Open discussion: Two months of determining what's ready to go into the next release. At the end of the that period there should be a list of things that we'd like to have in the next release.
b) Alpha phase: Two months of "getting stuff in" for those things that we agreed upon in the first phase. At the end of this phase, any new feature that isn't in yet, won't get in.
c) Beta phase: Two months of testing, fixing bugs updating the docs and packages at Squeakmap. At the end of which we have a new release.
Six months, and it should be done. With clear deadlines what is expected to happen when. With proposals made by the people who have done the work already. With work that is already finished and only needs inclusion instead of stuff on which work hasn't even begun yet.
Cheers,
- Andreas
"Ron Teitelbaum" Ron@USMedRec.com writes:
+1
I think it would be good to have a more formal process. It would be nice if we could have a single place to go to see what is going on, who is working on what and if there is any progress. I like the idea of organizing around current contributions and providing a structure so that everyone can understand the process of harvesting changes for adoption in the main image.
Me three. In my mind, working out a good process is the most important thing that the Squeak community needs. I argued so back when the Castaways bullied in and tried to fix our community against our will [1], and in most ways we are in about the same position now as then.
The one good process change I see is that we can elect board members now. That's an excellent and crucial step forward.
The next big thing to focus on, IMHO, is managing changes to the shared image. Part of that is surely to develop an idea of membership. Using computer-generated popularity rankings is a poor way to go. [2,3]
For big changes to the shared image, Andreas's notes earlier in the thread sound terrific to me.
For small changes, we still seem to be operating in a vacuum. I am unmotivated to fix bugs in core Squeak and in the Unix port, because in both cases the fixes are often ignored. SharedQueue, one of our fundamental synchronization constructs, has been broken for over a year now, despite a fix being available [4]. Should I ever again blow away a Saturday like that? Nobody likes being a sucker who fights harder for something than its own management.
So here's a challenge for you, board: how do we get fixes processed? All the really cool Squeak stuff happens at the periphery [3]. The question for the board is thus: how do we handle the simple, prosaic patches?
-Lex
[1] When I reread this old thread: http://lists.squeakfoundation.org/pipermail/squeak-dev/2005-February/088316....
I again wonder how things would have gone if the "Squeak Foundation Formation" group had continued its work, instead of being de facto shut down by the Castaways.
[2] "[Elections] reputation systems for membership" http://lists.squeakfoundation.org/pipermail/elections/2005-December/000010.h...
[3] "Squeak as Commons", my first sketch for a community organization: http://people.squeakfoundation.org/article/44.html
For small changes, we still seem to be operating in a vacuum. I am unmotivated to fix bugs in core Squeak and in the Unix port, because in both cases the fixes are often ignored. SharedQueue, one of our fundamental synchronization constructs, has been broken for over a year now, despite a fix being available [4]. Should I ever again blow away a Saturday like that? Nobody likes being a sucker who fights harder for something than its own management.
I added this improved SharedQueue as SharedQueue2 to 3.9 very early:
| MarcusDenker 10-07-05 18:09 in 3.9 for further testing
Sadly, nobody tested it. The next entry on mantis is yours from end of september (we where past gamma then, so we can't do this change):
| lexspoon 09-28-06 10:47 | It has been a year, now, and no problems have come to light. We should start migrating to this. | All it requires is replacing SharedQueue by SharedQueue2.
So I don't see how it is my fault to not have added this: It is a grave change, breaking the image on that level is far from fun, so this is not a fix to be added and then tested ("let's see if it works"). It needs at least some testing by someone before that.
If somebody would have tested it, I would have added it to 3.9a.
Even your note, if you would have posted that half a year earlier, this change would be in 3.9. Or you could have written a mail. *something*. *anything*.
What I think as strange is that people critize so hard for the percived fact that there was a bottleneck in getting things accepted in 3.9. I don't think that there was a too big one, compared to earlier release cycles. There was a bottleneck in reviewing and testing. And with that, everybody could have helped. And some people did.
In 3.9a, we managed to get mantis down to 275 entries, closing over 800. That's *a lot*. And two month ago, I would have bet that if people would evaluate the negative aspects of 3.9a, they would have said something like a) "this guy adds every crap", not "b) there is a bottleneck, nothing got accepted". And I am actually even now convenced that a) actually is kind of more true than b).
Marcus
On Tue, Oct 17, 2006 at 11:43:46PM +0200, Marcus Denker wrote:
What I think as strange is that people critize so hard for the percived fact that there was a bottleneck in getting things accepted in 3.9. I don't think that there was a too big one, compared to earlier release cycles.
Agreed.
There was a bottleneck in reviewing and testing. And with that, everybody could have helped. And some people did.
Agreed.
I did a very small amount of helping here, so let me offer my feedback. For me, it was difficult to review changes and test things because this often required downloading a complete new version of an image. This is time consuming and not much fun, so I did not do it very often.
The solution is simple. Use a release stream with change sets just like SqC did. That makes it easy and *enjoyable* to keep a testing image that is up to date with the release stream, and that contains a complete record of all the things that have been changed in the recent development process. I can see what changes occurred in what change sets, and when they were applied. I can read the preambles to get an explanation of why they are there. Last but not least, I can be reasonably confident that the author initials are those of the actual author.
In 3.9a, we managed to get mantis down to 275 entries, closing over 800. That's *a lot*.
Excellent. Well done indeed!
Dave
Marcus Denker denker@iam.unibe.ch writes:
I added this improved SharedQueue as SharedQueue2 to 3.9 very early:
| MarcusDenker 10-07-05 18:09 in 3.9 for further testing
Sadly, nobody tested it.
Right. As a result of this process, Squeak ends up using the known-broken code instead of the tested, believed-fixed code.
Strange, no? Everyone involved does good work, and we end up in a situation like this.
-Lex
On 24.10.2006, at 22:27, Lex Spoon wrote:
Marcus Denker denker@iam.unibe.ch writes:
I added this improved SharedQueue as SharedQueue2 to 3.9 very early:
| MarcusDenker 10-07-05 18:09 in 3.9 for further testing
Sadly, nobody tested it.
Right. As a result of this process, Squeak ends up using the known-broken code instead of the tested, believed-fixed code.
If it was tested, why not communicate it?
Strange, no? Everyone involved does good work, and we end up in a situation like this.
Actually, there was a last "ok, this works" missing. If it was so important, why didn't you add a comment to mantis or send a mail? Fixes and especially anhancements need to be actively supported, especially by their creators.
In this case it was *only* missing this last "please add this, I tested it in 3.9a, it works".
Marcus
Marcus Denker denker@iam.unibe.ch writes:
In this case it was *only* missing this last "please add this, I tested it in 3.9a, it works".
Right, sure. To be clear, I actually was not criticizing your and whoever else's individual decisions in this case. You've obviously done a huge amount of work for Squeak, and the parts I know about are very well done.
I am simply saying that the level of process and testing required is stiffling out some changes. If you do not have months to campaign and write tests and followup with bug-tracking discussions, it is hard to get a patch into Squeak. In a word, for good or for ill, Squeak is very conservative these days, at least with its core image.
-Lex
Lex Spoon wrote:
So here's a challenge for you, board: how do we get fixes processed? All the really cool Squeak stuff happens at the periphery [3]. The question for the board is thus: how do we handle the simple, prosaic patches?
From my point of view there is a really simple answer to that question: By delegating them to the maintainers. And if they aren't any, it won't get fixed. It's as simple as that. After all you can always volunteer for the maintainer position and if, and ONLY if, you get turned down you have something to complain about. In other words, I do accept your complaint about Unix code since we have a maintainer there and we should figure out what's going wrong. I do NOT accept the complaint about SharedQueue unless you are willing to sign up for the job of maintaining Collections or at least the part of it you were just working on.
Cheers, - Andreas
Andreas Raab andreas.raab@gmx.de writes:
Lex Spoon wrote:
So here's a challenge for you, board: how do we get fixes processed? All the really cool Squeak stuff happens at the periphery [3]. The question for the board is thus: how do we handle the simple, prosaic patches?
From my point of view there is a really simple answer to that question: By delegating them to the maintainers. And if they aren't any, it won't get fixed. It's as simple as that. After all you can always volunteer for the maintainer position and if, and ONLY if, you get turned down you have something to complain about. In other words, I do accept your complaint about Unix code since we have a maintainer there and we should figure out what's going wrong. I do NOT accept the complaint about SharedQueue unless you are willing to sign up for the job of maintaining Collections or at least the part of it you were just working on.
I like your approach. Let the individual maintainers, or stewards as called in some proposals, make these decisions.
As is, I do not think there is an official list of maintainers/stewards that is actually paid attention to. Am I wrong? The idea seems to circulate, but never become official in any way.
-Lex
Lex Spoon skrev:
Andreas Raab andreas.raab@gmx.de writes:
Lex Spoon wrote:
So here's a challenge for you, board: how do we get fixes processed? All the really cool Squeak stuff happens at the periphery [3]. The question for the board is thus: how do we handle the simple, prosaic patches?
From my point of view there is a really simple answer to that question: By delegating them to the maintainers. And if they aren't any, it won't get fixed. It's as simple as that. After all you can always volunteer for the maintainer position and if, and ONLY if, you get turned down you have something to complain about. In other words, I do accept your complaint about Unix code since we have a maintainer there and we should figure out what's going wrong. I do NOT accept the complaint about SharedQueue unless you are willing to sign up for the job of maintaining Collections or at least the part of it you were just working on.
I like your approach. Let the individual maintainers, or stewards as called in some proposals, make these decisions.
As is, I do not think there is an official list of maintainers/stewards that is actually paid attention to. Am I wrong? The idea seems to circulate, but never become official in any way.
-Lex
This is the most official list http://www.squeak.org/Community/Teams/ Whether it's paid attention to is another issue ;-) Karl
On Tue, 2006-10-24 at 22:48 +0200, karl wrote:
Lex Spoon skrev:
As is, I do not think there is an official list of maintainers/stewards that is actually paid attention to. Am I wrong? The idea seems to circulate, but never become official in any way.
-Lex
This is the most official list http://www.squeak.org/Community/Teams/ Whether it's paid attention to is another issue ;-) Karl
And as the previous Team Leader I will say this is THE official team list and has been now for at least a year.
Ken
Ken Causey ken@kencausey.com writes:
On Tue, 2006-10-24 at 22:48 +0200, karl wrote:
Lex Spoon skrev:
As is, I do not think there is an official list of maintainers/stewards that is actually paid attention to. Am I wrong? The idea seems to circulate, but never become official in any way.
-Lex
This is the most official list http://www.squeak.org/Community/Teams/ Whether it's paid attention to is another issue ;-) Karl
And as the previous Team Leader I will say this is THE official team list and has been now for at least a year.
Hmm, this lists teams. What about portions of the image? Or is it sort of the same thing, and you mean that we should have, for example, a Collections Team and a Concurrency Team and a Morphic Team ?
-Lex
On Tue, 2006-10-24 at 14:48 -0700, Lex Spoon wrote:
Hmm, this lists teams. What about portions of the image? Or is it sort of the same thing, and you mean that we should have, for example, a Collections Team and a Concurrency Team and a Morphic Team ?
-Lex
Well it should be noted that this is a complete list of all 'official' teams which is a mixture of Steward Teams (those who have accepted responsibility for some part of the Basic Squeak Image) and other teams like the Website team and future/speculative teams. Any team that is responsible for some part of the image should have 'Stewards' as part of the name and the description should list the Class Categories in the image for which that team is responsible. For example:
Morphic Stewards - Maintaining the Morphic- category of classes in the Basic Squeak Image
There is currently no Collections or Concurrency Team. But then there is also no Concurrency class category so it's unlikely a team would be named that (although the I/O Stewards team is an example that shows that the name is not necessarily exactly that of a class category in every example).
Ken
Ken Causey ken@kencausey.com writes:
Well it should be noted that this is a complete list of all 'official' teams which is a mixture of Steward Teams (those who have accepted responsibility for some part of the Basic Squeak Image) and other teams like the Website team and future/speculative teams. Any team that is responsible for some part of the image should have 'Stewards' as part of the name and the description should list the Class Categories in the image for which that team is responsible. For example:
Morphic Stewards - Maintaining the Morphic- category of classes in the Basic Squeak Image
Okay, I'll start thinking of maintainership as you describe. It looks like a good approach to me.
This leaves another thorny question, of course: what *does* happen with code that has no stewarding team? Does it not get bug fixes? Does Marcus simply get it dumped on his head to sort out? Maybe that's the best kind of approach that is possible.
-Lex
On Wed, 2006-10-25 at 12:54 -0700, Lex Spoon wrote:
Ken Causey ken@kencausey.com writes:
Well it should be noted that this is a complete list of all 'official' teams which is a mixture of Steward Teams (those who have accepted responsibility for some part of the Basic Squeak Image) and other teams like the Website team and future/speculative teams. Any team that is responsible for some part of the image should have 'Stewards' as part of the name and the description should list the Class Categories in the image for which that team is responsible. For example:
Morphic Stewards - Maintaining the Morphic- category of classes in the Basic Squeak Image
Okay, I'll start thinking of maintainership as you describe. It looks like a good approach to me.
This leaves another thorny question, of course: what *does* happen with code that has no stewarding team? Does it not get bug fixes? Does Marcus simply get it dumped on his head to sort out? Maybe that's the best kind of approach that is possible.
-Lex
Yes, if a change is fundamentally related to a class category for which there is no stewards team then the responsibility falls back on the release team. Clearly the forming of steward teams has not progressed as quickly as hoped.
Of course anyone who cares to spend a quiet afternoon Squeaking is more than welcome to grab a bug or two and post fixes to the appropriate Mantis reports. This would at least lower the workload for the release team. But then we all dream from time to time. ;)
Ken
sounds good idea. Why not in fact.
Stef
On 15 oct. 06, at 21:04, Andreas Raab wrote:
I don't know what other people think, but these long feature lists just give me the shivers. What if instead of listing feature X, Y, and Z (on many of which the implementation hasn't even started) we simply have a schedule that says:
a) Open discussion: Two months of determining what's ready to go into the next release. At the end of the that period there should be a list of things that we'd like to have in the next release.
b) Alpha phase: Two months of "getting stuff in" for those things that we agreed upon in the first phase. At the end of this phase, any new feature that isn't in yet, won't get in.
c) Beta phase: Two months of testing, fixing bugs updating the docs and packages at Squeakmap. At the end of which we have a new release.
Six months, and it should be done. With clear deadlines what is expected to happen when. With proposals made by the people who have done the work already. With work that is already finished and only needs inclusion instead of stuff on which work hasn't even begun yet.
Cheers,
- Andreas
Maybe high on the list are tests (maybe even an automatic test procedure mentioned on this list) and (more important) fix current defects.
Stéphane Ducasse wrote:
Hi all
I have been thinking about the next steps. Here are a list of propositions for 3.10/4.0 that I would like to work on and welcome company. Ideally I would like to build a group of people that have fun to work on these items. We could even try to have some regular chats one day a week and FUN.
I think that Squeak 10/4 should not be compatible to free us but at the same time it should prepare the coming of new assets (sophie/tweak).
Here are the main actions I would like to see happening:
- be able to load Tweak - be able to load Sophie infrastructural elements (ressourcelocation...) => even substitute current Squeak ones with sophie ones (Rome renderer)
- curve/remove Etoy/projects (without having to reload them) - remove nebraska and others/ remove packages early in the process - new compile method format if available else klaus fix for sourcelimits
- may be newcompiler if ready - aggressive cleans in a lot of areas - look at Pavel overrides problems => ideally be able to use Pavel image as a basis for 10/4 - Use tool builder (looking at the tool plus) and change thecurrent tools (the ones that deserve migration)
- more tests - may be using MC2 if ready - better integration of AST and refactoring supportSo if you want to help there on a regular basis or on specific items please say it
Stef
Could we please just have a minimal image for v4.0? The current Squeak images are huge and have lots of stuff I don't want.
I want an image that doesn't have Morphic but just a command line, like Pavel's kernel image. Everything else should be a separately maintained project that you can load in - if you want it.
For ease of use, you can also release developer's images with combinations of packages, but I don't believe that these should be the official "Squeak 3.10" image.
Stéphane Ducasse wrote:
Hi all
I have been thinking about the next steps. Here are a list of propositions for 3.10/4.0 that I would like to work on and welcome company. Ideally I would like to build a group of people that have fun to work on these items. We could even try to have some regular chats one day a week and FUN.
I think that Squeak 10/4 should not be compatible to free us but at the same time it should prepare the coming of new assets (sophie/tweak).
Here are the main actions I would like to see happening:
- be able to load Tweak
I'm assuming this is just an option, and won't mean ugly things like Object>>loadTweak.
- be able to load Sophie infrastructural elements (ressourcelocation...) => even substitute current Squeak ones with sophie ones (Rome renderer)
- curve/remove Etoy/projects (without having to reload them) - remove nebraska and others/ remove packages early in the process - new compile method format if available else klaus fix for sourcelimits
- may be newcompiler if ready
Perhaps it is better to include these projects in the release that happens *after* they are ready.
- aggressive cleans in a lot of areas
Yes please!
- look at Pavel overrides problems => ideally be able to use Pavel image as a basis for 10/4 - Use tool builder (looking at the tool plus) and change thecurrent tools (the ones that deserve migration)
- more tests - may be using MC2 if ready - better integration of AST and refactoring support
Please make this a loadable option.
Michael.
squeak-dev@lists.squeakfoundation.org
-
Andreas Raab -
Brad Fuller -
David T. Lewis -
Edgar J. De Cleene -
J J -
karl -
Ken Causey -
Klaus D. Witzel -
Lex Spoon -
Marcus Denker -
Michael van der Gulik -
Ramon Leon -
Ron Teitelbaum -
stephane ducasse -
Stéphane Ducasse -
Zulq Alam