Squeakfoundation April 2003

squeakfoundation@lists.squeakfoundation.org

17 participants
30 discussions

How to proceed for the kernel cleaning harvesting
by Stephane Ducasse 05 Apr '03

05 Apr '03

Hi Daniel Sorry I copied from the pipermail. Now I'm in the SqF list again. "I see what you mean. You want to specialize the general process for your particular effort. If you bring your own external reviewer, (and I heard Noury's talk last ESUG, so I have no doubts he can handle the meta aspects) that makes things easier, you don't need to motivate other external reviewers. Because he knows the context, he'll understand what you're doing with less prompting." This was not really my intention. I do not have any predefined idea. We want to follow any process that we make sure that our changes are evaluated in the best way. Now the problem is that if we generated a set of changes and that we have to wait that they are put into the stream to continue, this will not work. We are working on some tightly coupled classes, one which it is really difficult to make independent changes (Or we need a long period of time). Now what we want to know is how can we speed up the process because we cannot allocate resources over a long period of time. At the end, alex and nathanael will just fix the kernel for their PhD and this will be lost for Squeak. Nathanael and alex already fixed parts for their current work, noury did that too on his side. They are willing to **redo** this (with the extra responsibility that it should really work and be clean) which is a big effort. I cannot tell them go slowly because Squeak need you. This will not work. This means that if the process is not fast enough we may arrive to the situation were we will just shared between us (the guus at berne + noury) which would be a pity but a working solution for us (because at the end the kernel we dream about is not the one we will do during the Cleaning Kernel Project. We will do a kernel that allows us to build the one we dream because we are not sure that people will accept our dreams (which I understand perfectly)). Then another issue that the Guides/harvesters should consider is that the Guys from Berne may not be available 100% on that in the future. Roel just got today an excellent position (so he will have to teach, build a team....) within six months, I may find one and have to teach and create a new lab soon. Alex and nathanael will have to focus on their PhDs. So during the next 4 months we are sure to have 4 meta programmers and squeakers available at berne. But after that we will start to be dispersed = less efficient = more busy. I think that the Kernel Cleaning is the first big cleaning process so what is really important for us is that **you** discuss internally and you let us know if/how we can proceed to go fast with those changes. I think that there are some opportunities but you have to understand our constraints. My main points here is that I want to avoid frustration (we learned from Squeak3.3a) and still would like Squeak to get better. "It sounds like the front end of the process will be fine. However, when you specialize a process, you need to make sure the invariants are kept... here are the invariants we do need to intelligently [approve] the changes, so they can get into the update stream." " 1. We might not approve a specific change because we don't agree with the solution, or because we don't agree there's a problem. So, usually, we request changes be independent of one another, so we can review and accept/reject them independently, and evaluating their value by themselves. If you make some changesets interdependent, we still might not accept a changeset, and then it's your problem to work around it. This might still work, because you're working with well defined goals." That's why we started to work on the most obvious problems and let the points were people could disagree at the end. "2. If you want to help me make a positive decision, make it clear what problem you're solving, and what design decisions you're making. I don't need it to be ten lines per method - do the minimum, but communicate your decisions clearly. Making the changesets small helps. When you mix different operations in the same change set, it obfuscates (change set 11 converts Smalltalk -> self environment AND changes Behavior interface, moving things to a new class)." We paied attention to that at the extreme so normally this should not be a problem. Up until now we only fixed trivial and obvious problems. We will not start to touch more conceptual problem before all the stupid, basic engineering problems are into the image. "3. An external reviewer is as valuable as his comments. An anonymous [er] without the text of the review is meaningless. I want to SEE Noury's comments. Why? I know perfectly well he's a brilliant meta-programmer, but other than that, I don't know anything about his criteria. And if he feels something is so-so, I want him to write it down, so I can consider it too." OK "If you keep these invariants, I'll do my best to review your changes (and approve where appropriate) with reasonable dispatch - I think a clean kernel would be a wonderful thing. And within those invariants, as part of a specialized process, which I can agree to, we can change almost any part of the "ceremony" you want, so you can save energy." Ok so let us know. I think that making a try on the current changes could help to tighten the process and see if we can work this way. What I suggest is the following (depending on the availability of Noury's and Roel's time there is a deadline for ESUG for the end of the week) 1. we proceed to an internal/external review as soon as possible. 2. we let you know. 3. you try to assess the changes as fast as you can and report how we can improve communication. 4. If in the meantime you/harvesters evaluate the proposed changes which are simple (the only design point is that we introduced a new class for the navigation and UI related actions that the tools can reuse), and accept them we just pass to the next ones. Stef Prof. Dr. Stéphane DUCASSE http://www.iam.unibe.ch/~ducasse/ "if you knew today was your last day on earth, what would you do different? ... especially if, by doing something different, today might not be your last day on earth" Calvin&Hobbes "The best way to predict the future is to invent it..." Alan Kay. Open Source Smalltalks: http://www.squeak.org, http://www.gnu.org/software/smalltalk/smalltalk.html Free books for Universities at http://www.esug.org/sponsoring/promotionProgram.html Free Online Book at http://www.iam.unibe.ch/~ducasse/WebPages/FreeBooks.html

1 0

How to proceed for the kernel cleaning harvesting
by Stephane Ducasse 05 Apr '03

05 Apr '03

Hi doug and others We are starting to make progress on the kernel cleaning. However I would like to avoid to have 200 changesets to be included before putting some of them in the stream. What is important is that we are decomposing our changes (with pain instead of doing three changes at once we really do them one by one slowly) into small changesets so that people can understand them. We are also building a testSuite that we will keep in the future as a kind of specification of what we did. We are four working on that and we have our own internal reviewing. We are also introducing a deprecation schema so that tools build before the cleaning will be notified when they used an old method and that people can query the deprecated method. This way we could build a simple tool to identify deprecated methods and build a database with that information for later migration. Now the problem is that cleaning the kernel is somehow special and the order of the changesets may be really important. So change 0001 should be put in before 0004 for example. We are focusing on specific parts and we have some major milestones as explained on the page. http://minnow.cc.gatech.edu/squeak/3083 We can document what we are doing but if for every method move we have to write 10 lines this will never scale. Normally there is a preamble that explain the change but often we cannot spend time motivate them because this is obvious. So I would like to know if some harvesters are really interested in reviewing what we are doing, we are looking for a meta-aware one. I asked Noury (the best meta programmer I know in france father of metaclassTalk which already cure some part of the VW kernel for his PhD) to be an external reviewer. But he is not an harvester but could become one (Noury?) So as soon as our own reviewing process will finish for the first 40 changesets we will send them into the stream. But we would like to know how to minimize energy. Stef Prof. Dr. Stéphane DUCASSE http://www.iam.unibe.ch/~ducasse/ "if you knew today was your last day on earth, what would you do different? ... especially if, by doing something different, today might not be your last day on earth" Calvin&Hobbes "The best way to predict the future is to invent it..." Alan Kay. Open Source Smalltalks: http://www.squeak.org, http://www.gnu.org/software/smalltalk/smalltalk.html Free books for Universities at http://www.esug.org/sponsoring/promotionProgram.html Free Online Book at http://www.iam.unibe.ch/~ducasse/WebPages/FreeBooks.html

2 1

None of the KCP people are in the squeakF list
by Stephane Ducasse 05 Apr '03

05 Apr '03

Hi Just to let you know that we do not have access to the SqueakFoundation answer to my email because none of us in there. I made the mistake to send it there while I only wanted to reach the harvesters. So if a good soul could forward us the key reactions this would be cool. Stef Prof. Dr. Stéphane DUCASSE http://www.iam.unibe.ch/~ducasse/ "if you knew today was your last day on earth, what would you do different? ... especially if, by doing something different, today might not be your last day on earth" Calvin&Hobbes "The best way to predict the future is to invent it..." Alan Kay. Open Source Smalltalks: http://www.squeak.org, http://www.gnu.org/software/smalltalk/smalltalk.html Free books for Universities at http://www.esug.org/sponsoring/promotionProgram.html Free Online Book at http://www.iam.unibe.ch/~ducasse/WebPages/FreeBooks.html

1 0

Re: [Squeakfoundation]Re: Sublicensing seems possible
by Daniel Vainsencher 05 Apr '03

05 Apr '03

Ugh.. adding more political motivations and limitations to the license? I'd be happy to drop that clause entirely (though it might not be practical). But why should we strengthen this limitation? I'm sure you see that using the license as a weapon puts more legal pressure on it. Look how much clearer BSD is than GPL. If someone is a miser, bad karma is punishment enough IMO. Daniel Tim Rowledge <tim(a)sumeru.stanford.edu> wrote: > > On Friday, April 4, 2003, at 04:25 PM, Andreas Raab wrote: > >> Since they were modifying and extending the system they _had_ > >> to release those changes under the SqueakL just like the rest > >> of us. > > > > Slight correction: Squeak-L is not viral. It does not require you to > > release > > modifications under Squeak-L. All it requires is to make the code > > "publicly > > available". > > That could actually be a problem in some cases. Say developer X > releases some system changes as required but insists on the GPL. They > have been publically released but are effectively unusable within the > main system. And I suppose that in a sense it would 'block' us from > implementing the same thing unless one could prove it clean. Ugly. > Perhaps we need to assert that 'publically available' is interpreted as > 'usable in the main public image'. > > tim > -- > tim(a)sumeru.stanford.edu > > _______________________________________________ > Squeakfoundation mailing list > Squeakfoundation(a)lists.squeakfoundation.org > http://lists.squeakfoundation.org/listinfo/squeakfoundation

1 0

Re: [Squeakfoundation]How to proceed for the kernel cleaning harvesting
by Daniel Vainsencher 05 Apr '03

05 Apr '03

Hi Stef. I see what you mean. You want to specialize the general process for your particular effort. If you bring your own external reviewer, (and I heard Noury's talk last ESUG, so I have no doubts he can handle the meta aspects) that makes things easier, you don't need to motivate other external reviewers. Because he knows the context, he'll understand what you're doing with less prompting. It sounds like the front end of the process will be fine. However, when you specialize a process, you need to make sure the invariants are kept... here are the invariants we do need to intelligently [approve] the changes, so they can get into the update stream. 1. We might not approve a specific change because we don't agree with the solution, or because we don't agree there's a problem. So, usually, we request changes be independent of one another, so we can review and accept/reject them independently, and evaluating their value by themselves. If you make some changesets interdependent, we still might not accept a changeset, and then it's your problem to work around it. This might still work, because you're working with well defined goals. 2. If you want to help me make a positive decision, make it clear what problem you're solving, and what design decisions you're making. I don't need it to be ten lines per method - do the minimum, but communicate your decisions clearly. Making the changesets small helps. When you mix different operations in the same change set, it obfuscates (change set 11 converts Smalltalk -> self environment AND changes Behavior interface, moving things to a new class). 3. An external reviewer is as valuable as his comments. An anonymous [er] without the text of the review is meaningless. I want to SEE Noury's comments. Why? I know perfectly well he's a brilliant meta-programmer, but other than that, I don't know anything about his criteria. And if he feels something is so-so, I want him to write it down, so I can consider it too. If you keep these invariants, I'll do my best to review your changes (and approve where appropriate) with reasonable dispatch - I think a clean kernel would be a wonderful thing. And within those invariants, as part of a specialized process, which I can agree to, we can change almost any part of the "ceremony" you want, so you can save energy. Daniel Stephane Ducasse <ducasse(a)iam.unibe.ch> wrote: > Hi doug and others > > We are starting to make progress on the kernel cleaning. However I > would like to avoid to have 200 changesets to be included before > putting some of them in the stream. > > What is important is that we are decomposing our changes (with pain > instead of doing three changes at once we really do them one by one > slowly) into > small changesets so that people can understand them. We are also > building a testSuite > that we will keep in the future as a kind of specification of what we > did. We are four working on that and we have our own internal > reviewing. We are also introducing a deprecation schema so that tools > build before the cleaning will be notified when they used an old method > and that people can query the deprecated method. This way we could > build a simple tool to identify deprecated methods and build a database > with that information for later migration. > > Now the problem is that cleaning the kernel is somehow special and the > order of the changesets may be really important. So change 0001 should > be put in before 0004 for example. We are focusing on specific parts > and we have some major milestones as explained on the page. > http://minnow.cc.gatech.edu/squeak/3083 > > We can document what we are doing but if for every method move we have > to write 10 lines this will never scale. Normally there is a preamble > that explain the change but often we cannot spend time motivate them > because this is obvious. So I would like to know if some harvesters are > really interested in reviewing what we are doing, we are looking for a > meta-aware one. I asked Noury (the best meta programmer I know in > france father of metaclassTalk which already cure some part of the VW > kernel for his PhD) to be an external reviewer. But he is not an > harvester but could become one (Noury?) > > So as soon as our own reviewing process will finish for the first 40 > changesets we will send them into the stream. But we would like to know > how to minimize energy. > > > Stef > > > > > Prof. Dr. Stéphane DUCASSE > http://www.iam.unibe.ch/~ducasse/ > "if you knew today was your last day on earth, what would you do > different? ... especially if, > by doing something different, today might not be your last day on > earth" Calvin&Hobbes > > "The best way to predict the future is to invent it..." Alan Kay. > > Open Source Smalltalks: http://www.squeak.org, > http://www.gnu.org/software/smalltalk/smalltalk.html > Free books for Universities at > http://www.esug.org/sponsoring/promotionProgram.html > Free Online Book at > http://www.iam.unibe.ch/~ducasse/WebPages/FreeBooks.html > _______________________________________________ > Squeakfoundation mailing list > Squeakfoundation(a)lists.squeakfoundation.org > http://lists.squeakfoundation.org/listinfo/squeakfoundation

1 0

RE: [Squeakfoundation]WeakArray bug (was Re: [UPDATES] 3.5gamma)
by Daniel Vainsencher 05 Apr '03

05 Apr '03

Andreas Raab <andreas.raab(a)gmx.de> wrote: > > We need more explicit reviews. > Or more explicit goals ;-) Sure. My experience is that the goals one thought up initially are usually no longer precise enough by the time you're done, so maybe the thinking cap trigger should be the review. Basically, with our current process, that means that the harvesters should use [approved] with care. Daniel > > -----Original Message----- > > From: squeakfoundation-bounces(a)lists.squeakfoundation.org > > [mailto:squeakfoundation-bounces@lists.squeakfoundation.org] > > On Behalf Of Daniel Vainsencher > > Sent: Saturday, April 05, 2003 3:14 AM > > To: Discussing the Squeak Foundation > > Subject: [Squeakfoundation]WeakArray bug (was Re: [UPDATES] 3.5gamma) > > > > > > About the 3.5/3.6 decision, sounds reasonable to me. > > > > About why we got to the state where one of us says a bug > > critical enough > > to stop the release from going out, when we're in gamma - I think we > > included the fix with the implicit goal of "fixing the class builder" > > but with the explicit SUnit test of "classes with instance > > variables and > > subclasses can be reshaped properly". > > > > Nobody said "this fix does X, which is enough. It doesn't do Y, but we > > can live with that", where Y would be "allow the whole > > hierarchy to get > > rebuilt", for example. > > > > We need more explicit reviews. > > > > Daniel > > > > Doug Way <dway(a)riskmetrics.com> wrote: > > > > > > Daniel Vainsencher wrote: > > > > > > > > <shifting to sqf list> > > > > > > > > That's an interesting point. Does that mean we actually > > delay 3.5, when > > > > the 3.6 update stream has already started? another > > question is, how did > > > > we get into gamma, when apparently, one of our two goals > > for the release > > > > isn't actually achieved? > > > > > > Tim did mention this as a bug on March 14. There wasn't > > any mention of > > > whether it was a serious enough problem to try to fix in > > 3.5, so I ignored it > > > for the moment, hoping that someone would come up with a fix. > > > > > > It did appear to be possibly related to the ClassBuilder > > problem, but that > > > wasn't certain, either. The problem occured with or > > without the ClassBuilder > > > fix. > > > > > > Just now I did a quick check of when the bug was > > introduced. I was guessing > > > that maybe Andreas introduced it with the ClassBuilder > > refactoring/cleanup in > > > 3.4alpha, which was when the other ClassBuilder bug was > > introduced. However, > > > that was not the case... I tested 3.2 and the bug is there, > > too. Turns out > > > this bug is as old as the hills... the bug exists back in > > 2.6! It does not > > > exist in 2.4, though. (It's always nice to have old images > > lying around. :-) > > > I didn't have a 2.5 image handy, though.) > > > > > > So, given that the bug is 3+ years old, and we don't yet > > have a fix that we > > > agree on, I think it's pretty safe to say that we don't > > need to address this > > > in 3.5. As soon as someone comes up with a good fix, we > > can include it in > > > 3.6alpha. (Maybe Brent's fix is sufficient, I don't know, > > but it hasn't > > > gotten any feedback yet.) > > > > > > - Doug Way > > > > > > > > > > Daniel > > > > > > > > Tim Rowledge <tim(a)sumeru.stanford.edu> wrote: > > > > > Daniel Vainsencher <danielv(a)netvision.net.il> wrote: > > > > > > > > > > > AFAICT, this fix is KCP territory. Unless there is a > > very good reason > > > > > > otherwise, I would await their recommendation (and > > not delay the > > > > > > release). > > > > > Well since the 3.5 release was purported to be mostly > > to include a fix > > > > > for a very similar bug and the bug in question has > > pretty similar > > > > > effects - cannot recompile a number of classes - I'd > > say that without a > > > > > fix we really shouldn't even consider 3.5 in beta in > > any meaningful > > > > > sense. > > > > > > > > > > tim > > > > > -- > > > > > Tim Rowledge, tim(a)sumeru.stanford.edu, > > http://sumeru.stanford.edu/tim > > > > > Spellchecker not found. > > Press -- to continue ... > > > > _______________________________________________ > > > > Squeakfoundation mailing list > > > > Squeakfoundation(a)lists.squeakfoundation.org > > > > http://lists.squeakfoundation.org/listinfo/squeakfoundation > > > _______________________________________________ > > > Squeakfoundation mailing list > > > Squeakfoundation(a)lists.squeakfoundation.org > > > http://lists.squeakfoundation.org/listinfo/squeakfoundation > > _______________________________________________ > > Squeakfoundation mailing list > > Squeakfoundation(a)lists.squeakfoundation.org > > http://lists.squeakfoundation.org/listinfo/squeakfoundation > > > > _______________________________________________ > Squeakfoundation mailing list > Squeakfoundation(a)lists.squeakfoundation.org > http://lists.squeakfoundation.org/listinfo/squeakfoundation

1 0

Re: [Squeakfoundation]Re: Sublicensing seems possible
by Daniel Vainsencher 05 Apr '03

05 Apr '03

The subprojects mentioned are new. Schools are starting to think about all the teacher hours they could pay with their software licensing budgets. Various user groups are starting to tailor free alternatives for them to consider. People often check out and maybe even use whatever tools they have preinstalled on their computers. Do you see where this is going? [what's stopping open source/free software people from contributing to Squeak] If they happen to know about Smalltalk, or like reading licenses for fun, probably nothing. If they compare Python and Squeak, notice that Squeak isn't DFSG, and isn't OSI (but Python is...), they might just think "why bother?". And there goes another one... BTW, have you looked at the DFSG? if you did, you might wish Squeak's license did fit that definition, because it's really quite nice. Licenses that are _fair_... gee, imagine that. Daniel Gary Fisher <gafisher(a)sprynet.com> wrote: > ----- Original Message ----- > From: "Daniel Vainsencher" <danielv(a)netvision.net.il> > Subject: Re: [Squeakfoundation]Re: Sublicensing seems possible > > > > And the fact that the world doesn't want to buy iraqi oil doesn't limit > > the iraqies, it just limits the world, right? > > > > Um, it would if the Iraqis were offering it for free. (-: > > > You don't want kids in schools to have Squeak preinstalled on their > > computers, simply because it is part of DebianJr/DebianEdu/Debian > > multimedia project (I can never remember their precise name)? > > > > Daniel, I'd like to see every school running Debian but the fact is most > aren't; further, I strongly suspect most schools where Squeak is installed > aren't running Debian either. My own experience is that a certain decidedly > un-open OS rules the roost thus far, but Squeak doesn't really seem to care. > > > You don't want the hoards of people that contribute their programming > > time to free software in stiffer/poorer languages to feel free and safe > > to contribute Squeak code? > > > > I do. > > > > So do I, nor do I see what's holding them back. > > Gary > > _______________________________________________ > Squeakfoundation mailing list > Squeakfoundation(a)lists.squeakfoundation.org > http://lists.squeakfoundation.org/listinfo/squeakfoundation

4 7

WeakArray bug (was Re: [UPDATES] 3.5gamma)
by Daniel Vainsencher 05 Apr '03

05 Apr '03

About the 3.5/3.6 decision, sounds reasonable to me. About why we got to the state where one of us says a bug critical enough to stop the release from going out, when we're in gamma - I think we included the fix with the implicit goal of "fixing the class builder" but with the explicit SUnit test of "classes with instance variables and subclasses can be reshaped properly". Nobody said "this fix does X, which is enough. It doesn't do Y, but we can live with that", where Y would be "allow the whole hierarchy to get rebuilt", for example. We need more explicit reviews. Daniel Doug Way <dway(a)riskmetrics.com> wrote: > > Daniel Vainsencher wrote: > > > > <shifting to sqf list> > > > > That's an interesting point. Does that mean we actually delay 3.5, when > > the 3.6 update stream has already started? another question is, how did > > we get into gamma, when apparently, one of our two goals for the release > > isn't actually achieved? > > Tim did mention this as a bug on March 14. There wasn't any mention of > whether it was a serious enough problem to try to fix in 3.5, so I ignored it > for the moment, hoping that someone would come up with a fix. > > It did appear to be possibly related to the ClassBuilder problem, but that > wasn't certain, either. The problem occured with or without the ClassBuilder > fix. > > Just now I did a quick check of when the bug was introduced. I was guessing > that maybe Andreas introduced it with the ClassBuilder refactoring/cleanup in > 3.4alpha, which was when the other ClassBuilder bug was introduced. However, > that was not the case... I tested 3.2 and the bug is there, too. Turns out > this bug is as old as the hills... the bug exists back in 2.6! It does not > exist in 2.4, though. (It's always nice to have old images lying around. :-) > I didn't have a 2.5 image handy, though.) > > So, given that the bug is 3+ years old, and we don't yet have a fix that we > agree on, I think it's pretty safe to say that we don't need to address this > in 3.5. As soon as someone comes up with a good fix, we can include it in > 3.6alpha. (Maybe Brent's fix is sufficient, I don't know, but it hasn't > gotten any feedback yet.) > > - Doug Way > > > > Daniel > > > > Tim Rowledge <tim(a)sumeru.stanford.edu> wrote: > > > Daniel Vainsencher <danielv(a)netvision.net.il> wrote: > > > > > > > AFAICT, this fix is KCP territory. Unless there is a very good reason > > > > otherwise, I would await their recommendation (and not delay the > > > > release). > > > Well since the 3.5 release was purported to be mostly to include a fix > > > for a very similar bug and the bug in question has pretty similar > > > effects - cannot recompile a number of classes - I'd say that without a > > > fix we really shouldn't even consider 3.5 in beta in any meaningful > > > sense. > > > > > > tim > > > -- > > > Tim Rowledge, tim(a)sumeru.stanford.edu, http://sumeru.stanford.edu/tim > > > Spellchecker not found. Press -- to continue ... > > _______________________________________________ > > Squeakfoundation mailing list > > Squeakfoundation(a)lists.squeakfoundation.org > > http://lists.squeakfoundation.org/listinfo/squeakfoundation > _______________________________________________ > Squeakfoundation mailing list > Squeakfoundation(a)lists.squeakfoundation.org > http://lists.squeakfoundation.org/listinfo/squeakfoundation

2 1

3.5 Release Date (was Re: A naive question about the speedoptimization of anthony)
by Doug Way 05 Apr '03

05 Apr '03

Hi all. According to the 3.5 plan, the original "First Fridays" final release date for 3.5 was today, Friday the 4th. I posted in "WeakArray bug" thread that I don't think we need to hold up the 3.5 release for a fix for that particular bug, since it's an old bug, we haven't agreed on a fix, and even an agreed-upon fix would need some time for testing. However, there's also the issue of possibly adding the closure-compatible VM additions. I actually don't have a big problem with adding these in 3.5, if the various VM folks agree that it's a good idea, since they can't really affect anything else. I am assuming there are no licensing issues with the VM additions... they'd just be Squeak-L. Let's hear some opinions from the VM-interested folks on this. The other issue is that we originally planned to have a 3.6 Release Plan ready as part of the 3.5 final release. We still have some work to do on that, so in any case I think it might be a good idea to postpone the 3.5 release to next Friday, the 11th. This will give us some time to hash out a rough 3.6 plan (it doesn't have to be that detailed), and also time to decide whether to include the closure VM additions. I like the idea of still releasing it on a Friday, too. :-) I wouldn't normally be this cavalier about postponing a release date, but in this case I think there isn't that much demand to see 3.5 right away, since it doesn't have much new stuff and since 3.4 was released quite recently. 3.6 will probably be a different story. Does this sound reasonable? - Doug -------- Original Message -------- Subject: Re: A naive question about the speed optimization of anthony Date: Fri, 4 Apr 2003 00:58:08 -0500 From: Doug Way <dway(a)riskmetrics.com> Reply-To: The general-purpose Squeak developers list<squeak-dev(a)lists.squeakfoundation.org> To: The general-purpose Squeak developers list<squeak-dev(a)lists.squeakfoundation.org> I understand that they're harmless changes also. I would tend to just include them in 3.6alpha and not mess with 3.5gamma at this stage. There's not that much disadvantage to adding them in 3.6alpha... they could be added right away (since the 3.6alpha update stream is open), and the actual closure (non-VM) code wouldn't be added until later in 3.6alpha anyway, if it is added. Although if all of the VM maintainers think it is worth adding in 3.5, we could consider that. - Doug Way On Thursday, April 3, 2003, at 03:48 PM, Daniel Vainsencher wrote: > Yeah, I see what you mean about it being quite harmless, so I don't > feel > very strongly about it. I do want to make to advance this thing, but I > don't want to push for something that adds (slight) risk to a release > that I advocated be short only because it is relatively > complication-free (ha, theories - see the weakness weaknes thread). > > So, I'll accept whatever other people decide, and it's really mostly up > to Doug and the VM maintainers. > > Daniel > > Andreas Raab <andreas.raab(a)gmx.de> wrote: >> Daniel, >> >>> Well, making the VMs "closure compatible" soon is a good thing. >>> >>> Changing gamma versions isn't. >> >> Well, it's your choice. I was just pointing out that the changes are >> "harmless" in terms of actually affecting anything and therefore >> could be >> considered for inclusion. >> >> Cheers, >> - Andreas >> >>> >>> I withdraw from this discussion - I don't have anything more to add. >>> >>> Doug's call. >>> >>> Hmm, just thought about an alternative that might be better - >>> add it to >>> 3.6, and use 3.6 to make the 3.5 VMs. If that's the only >>> difference (and >>> 3.5 didn't contain a lot), it should be compatible anyway. But, >>> again, >>> whatever you guys decide. >>> >>> Daniel >>> >>> Andreas Raab <andreas.raab(a)gmx.de> wrote: >>>>> It'll be 3.6a (3.5 is now gamma), >>>> >>>> So what. We're effectively talking about five methods with >>> no implication >>>> whatsoever on any part of the VM or the image. Even if they >>> were entirely >>>> broken they'd affect nothing. If you want to move towards >>> that direction >>>> it's definitely worthwhile considering. >>>> >>>> Cheers, >>>> - Andreas >>>

1 0

Re: [UPDATES] 3.5gamma
by Daniel Vainsencher 05 Apr '03

05 Apr '03

<shifting to sqf list> That's an interesting point. Does that mean we actually delay 3.5, when the 3.6 update stream has already started? another question is, how did we get into gamma, when apparently, one of our two goals for the release isn't actually achieved? Daniel Tim Rowledge <tim(a)sumeru.stanford.edu> wrote: > Daniel Vainsencher <danielv(a)netvision.net.il> wrote: > > > AFAICT, this fix is KCP territory. Unless there is a very good reason > > otherwise, I would await their recommendation (and not delay the > > release). > Well since the 3.5 release was purported to be mostly to include a fix > for a very similar bug and the bug in question has pretty similar > effects - cannot recompile a number of classes - I'd say that without a > fix we really shouldn't even consider 3.5 in beta in any meaningful > sense. > > tim > -- > Tim Rowledge, tim(a)sumeru.stanford.edu, http://sumeru.stanford.edu/tim > Spellchecker not found. Press -- to continue ...

3 2

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

Squeakfoundation April 2003