Squeakfoundation March 2003

squeakfoundation@lists.squeakfoundation.org

27 participants
66 discussions

Re: Shrinking alpha image (was Re: Proposal to get to the triad)
by goran.hultgren＠bluefish.se 21 Mar '03

21 Mar '03

(crossposting, well - it seemed good) Doug Way <dway(a)riskmetrics.com> wrote: > Brent Vukmer wrote: > > How about we just make the "expandToFullSize" script a well-publicized SqueakMap package that Doug owns. > > Yes, the script should probably be a well-publicized package on SqueakMap. > There could even be a shortcut somewhere in the UI of the Basic image to > expand to Full size. As I see it the plan Doug has laid out seems fine. I mean, we aren't really maintaining two images - we are maintaining the smaller one and making sure that the "full script" works. BUT... may I suggest that we set up a goal for 3.6 that SM1.1 is reached before release? Otherwise this "full script" will have problems, since it can't refer to specific versions of packages. And btw, who of us guides should be in charge of making sure that we pin down the list of planned things for 3.6? I have seen numerous posts on this subject but someone needs to collect these into a "big list" that we can condense somewhere and come up with "The Grand 3.6 Plan". In short - who should be the "Release Boss" for 3.6? :-) And the gist of that plan should of course be summarized on this page: http://swiki.squeakfoundation.org/squeakfoundation/79 Daniel? Tim? Ned? Craig? Personally I would like to keep my focus at you-know-what and Doug has already taken on enough IMHO. I think Daniel would make a greate Release Boss... :-) regards, Göran

3 3

Re: [Squeakfoundation] Decision time: Are SCG the steward of thekernel as proposed?
by Daniel Vainsencher 21 Mar '03

21 Mar '03

To add another reason againt a vote on this (not that I care very strongly): I didn't see a need for it because I think we can send the right message without providing an official moment of decision - after all, people do take their risks whatever we might decide, even officially. If SCG fubars it, we won't merge their stuff. If they bring us good patches (the much more likely outcome), we'll merge them whether they have any "officially decided" status or not. Just remember this - once we've made decisions on a topic, we'll always be making decisions on that topic (paraphrasing Frank Herbert, in one of the Dune books). IMHO, giving advice is worth doing permanently, giving official badges isn't. Daniel Doug Way <dway(a)riskmetrics.com> wrote: > > goran.hultgren(a)bluefish.se wrote: > > > > Daniel Vainsencher <danielv(a)netvision.net.il> wrote: > > > I don't know if votes are that important (in the absence of any dissent, > > > at least), but yes anyway. > > > > I looked up the word "dissent" but could still not really figure out > > what you mean. > > Dissent meaning "opposition" or "disagreement". I think he meant that since > nobody strongly objected (on squeak-dev or here) to the idea of SCG becoming > stewards of the kernel, in that sense maybe we didn't really need to vote on > it. > > But I agree that an official vote is good for this type of important decision. > > - Doug Way > _______________________________________________ > Squeakfoundation mailing list > Squeakfoundation(a)lists.squeakfoundation.org > http://lists.squeakfoundation.org/listinfo/squeakfoundation

3 2

updating to next version after declining alpha
by Joshua 'Schwa' Gargus 21 Mar '03

21 Mar '03

I originally posted this to squeak-dev, but it probably should have been sent here. ----- Forwarded message from Joshua 'Schwa' Gargus <schwa(a)cc.gatech.edu> ----- Date: Wed, 19 Mar 2003 21:59:18 -0500 From: "Joshua 'Schwa' Gargus" <schwa(a)cc.gatech.edu> Reply-To: The general-purpose Squeak developers list <squeak-dev(a)lists.squeakfoundation.org> To: Squeak Mailing List <squeak-dev(a)lists.squeakfoundation.org> Subject: updating to next version after declining alpha User-Agent: Mutt/1.2.5.1i Delivered-To: mailman-squeak-dev(a)lists.squeakfoundation.org List-Id: The general-purpose Squeak developers list <squeak-dev.lists.squeakfoundation.org> List-Unsubscribe: <http://lists.squeakfoundation.org/listinfo/squeak-dev>, <mailto:squeak-dev-request@lists.squeakfoundation.org?subject=unsubscribe> List-Archive: <http://lnx-12.ams-2.theinternetone.net/pipermail/squeak-dev> List-Post: <mailto:squeak-dev@lists.squeakfoundation.org> List-Help: <mailto:squeak-dev-request@lists.squeakfoundation.org?subject=help> List-Subscribe: <http://lists.squeakfoundation.org/listinfo/squeak-dev>, <mailto:squeak-dev-request@lists.squeakfoundation.org?subject=subscribe> Errors-To: squeak-dev-bounces(a)lists.squeakfoundation.org I have a comment about Squeak version releases that may or may not have been discussed already. My concern relates to beginning a new alpha branch before the previous version is finalized. This happens every time, and I think that it is unavoidable. I currently have a 3.5 beta "living" image where I keep a lot of important information. I don't want to advance it to 3.6 alpha because I can't afford to mess it up. So, I chose to only receive the final fixes for the 3.5 release. However, some day 3.6 will be stable enough to switch to. My problem involves the uncertainty about being able to successfully update from a 3.5 final release (which may include updates after the choice about whether to go 3.5 or 3.6). Can we manage the update streams in such a way that we can be certain that such updates are possible? In most cases, it probably works fine on its own. However, I think that it is important for users to be able to rely on this invariant. Comments? Joshua ----- End forwarded message -----

1 0

Re: [Squeakfoundation] Decision time: Are SCG the steward of the kernel as proposed?
by Daniel Vainsencher 15 Mar '03

15 Mar '03

I don't know if votes are that important (in the absence of any dissent, at least), but yes anyway. Daniel goran.hultgren(a)bluefish.se wrote: > Hi fellow Guides! > > When I just wrote the "monthly status report" I realized that we haven't > really decided about "giving" SCG the Stewardship of the kernel. Of > course, we guides are by no means "dictators" but we do have a > responsibility to move discussions into decisions and after reading > through this thread (the post from Alexandre Bergel felt like the > "official request" from SCG) it looks to me that everyone is in favour > of this arrangement. > > So someone needs to "hit the club in the desk", or whatever you call it. > > We talked a bit about what being a Steward means and we more or less > came to the conclusion that we don't want to set any rules at this > point. It is better to move ahead and learn. The only "guideline" that > Andreas mentioned would be that as a Steward you simply need to be "more > careful" when evolving the package - you obviously have much more > dependents maintaining something in the kernel. > > What we all wanted was some form of charter from SCG what they plan etc > but I think we have a pretty good picture already and it probably will > not affect the decision here - which is more a question of trust in > their capability and motives. :-) > > So, just to move forward one step: > > Can we Guides agree to give SCG this Stewardship? I vote yes. > > Let us all (us Guides that is) reply to this post so that we get a full > count (6) and then we can make it "official", unless of course someone > is against or still have things to discuss in which case we will just > have to discuss further. > > regards, Göran > > _______________________________________________ > Squeakfoundation mailing list > Squeakfoundation(a)lists.squeakfoundation.org > http://lists.squeakfoundation.org/listinfo/squeakfoundation

3 3

Re: [Squeakfoundation]Proposed 3.5 release plan
by Daniel Vainsencher 12 Mar '03

12 Mar '03

I'd like to get the removing process underway, and get our new harvesting process warmed up, and then we have a lot to talk about - * Shutting up the network classes use of UI (hopefully, based on MichaelRs work) * Using one of the Streams-should-not-represent-resources refactorings (Flow/IOHandle) * Streams-should-be-clean (Flow again) * Closures, which require replacing the compiler with Anthony's SmaCC based parser+RB AST+visitors, and adding primitives * And yes, somewhere in there, an image format change. Daniel Doug Way <dway(a)riskmetrics.com> wrote: > > Daniel Vainsencher wrote: > > > > Sounds fine to me. Small comments - > > In my eyes, the reason is more to have an unusually clean release, > > before we an unusual mess of things by starting to pull stuff out, than > > to fix any two particular bugs. Those two happen to be ones we'd like to > > release before 3.6. > > Yes, I'll add a comment about wanting to have a release free of major bugs as > a sort of baseline fr people to use, before the "turmoil" of package removal > etc. in 3.6 begins. > > > I think if we haven't decided it by now, it's quite unlikely that 3.5+1 > > will be 4.0. We haven't prepared for or talked about a compatibility > > break at all, and it seems to me like the sort of thing you want to do > > right at the beginning of a release cycle. So 3.6 is pretty definite. > > I agree. I think there's been a sort of assumption that we would want to get > started with splitting packages off of the image for at least one release > before worrying about a possible image format change. So if there are no > objections I'll remove the tentative tone about "3.6" in the announcement and > declare that the post-3.5 release will definitely be called 3.6. > > We will need to start thinking about when a possible image format change might > happen, which Tim brought up recently. I think we're agreed that a major > version number change should be used for an image format change, it's just a > matter of when... we could go from 3.6 -> 4.0, or 3.6 -> 3.7 -> 4.0, or... > Anyway, we don't have to decide on that now. Perhaps Tim can comment further. > > - Doug Way > _______________________________________________ > Squeakfoundation mailing list > Squeakfoundation(a)lists.squeakfoundation.org > http://lists.squeakfoundation.org/listinfo/squeakfoundation

2 1

Re: [Squeakfoundation]Proposed 3.5 release plan
by Daniel Vainsencher 12 Mar '03

12 Mar '03

Sounds fine to me. Small comments - In my eyes, the reason is more to have an unusually clean release, before we an unusual mess of things by starting to pull stuff out, than to fix any two particular bugs. Those two happen to be ones we'd like to release before 3.6. I think if we haven't decided it by now, it's quite unlikely that 3.5+1 will be 4.0. We haven't prepared for or talked about a compatibility break at all, and it seems to me like the sort of thing you want to do right at the beginning of a release cycle. So 3.6 is pretty definite. Daniel Doug Way <dway(a)riskmetrics.com> wrote: > > On Mon, 10 Mar 2003 19:34:07 -0500, Doug Way wrote: > > > > ... > > So, let's assume we go ahead with the current plan for 3.5 (only the > > two > > bugfixes unless another major bug comes up, release on April 4th). We > > can > > discuss it a bit more, but I'd like to announce this on squeak-dev > > sometime > > tomorrow as planned. > > > > Then, I could harvest the two bugfixes and put them in the 3.5alpha > > update > > stream. Then, soon after that (maybe a few days), we might as well > > move 3.5 > > straight to beta. At that point, we could offer the usual choice in > > the > > update stream for whether people want to move to 3.5beta or join the > > new > > 3.6alpha update stream. > > > > With 3.6alpha open, even while 3.5beta is still around, we could start > > harvesting the fixes on sqfixes into 3.6alpha and see some of the > > faster > > turnaround and "visibility" that we've been hoping to achieve. > > There doesn't seem to be violent disagreement to this basic proposed > plan so far :-), but I should probably flesh it out a bit more before > announcing it on squeak-dev. > > (In some ways this seems like a bit of overkill in terms of process, > for a two-fix release. New VMs probably do not need to be built in > this case, and perhaps we don't need to bother with the usual press > releases. (?) You could make a good argument that this could be more > of a patch release, possibly named 3.4.1. But then even such a patch > release would still need a testing period to make sure the fixes > actually worked and didn't cause further problems. So I guess I don't > have a big problem with calling it 3.5.) > > Anyway, here's the fleshed out proposed plan. Let me know if the dates > and everything else sound reasonable. If it is, I'll announce it > tomorrow night on squeak-dev. > > ----------------------- > > The 3.5 release will be a short release for the purpose of fixing a > couple of serious bugs that have cropped up, and (to a lesser extent) > to serve as a simple first-time release for the Guides, from beginning > to end. > > The proposed release date is April 4th. This will give us a chance to > get a release out quickly with these important fixes, but it will also > give us a little bit of time to plan the post-3.5 release. > > The two fixes are MetaClassBuilderFix from Andreas Raab which fixes the > class builder problem, and reverting a method which caused problems for > anyone saving a project containing a .gif or .jpg (which is quite > common). > > There won't be any other fixes accepted for this quick release, unless > something comes up of similar severity to the project-saving bug. > (Minimum requirements would be: several people independently mention it > as a problem, the bug didn't exist in 3.2, and then the guides have to > agree that it's worth including.) The reason we are being strict about > this is because of the very short release cycle. > > However, this doesn't mean that the harvesting process started up at > http://swiki.gsug.org:8080/SQFIXES/ will come to a standstill. Within > a week, a 3.6alpha update stream will open up, and we can start moving > fixes into it quickly. (We haven't officially decided that the next > release will be called 3.6, but for now I'll use that name. 3.6 will > have a longer release cycle.) > > Craig Latta suggested a "First Fridays" scheme for the final release > date, which we will try here. (Releasing on the first Friday of the > month.) That way we won't sometimes be releasing on a weekend, for > example, which can be a problem for some people. > > Dates: > > Sometime tomorrow or so - Add the two fixes to the 3.5alpha update > stream. > > Monday, March 17 - Move 3.5 to beta, and create a 3.6alpha update > stream, allowing the usual choice when updating. > > Friday, March 28 - Create a gamma candidate image. Also, have a plan > for the 3.6 release ready by this date. The plan should include a > proposed list of major features, and a release date. > > Wednesday, April 2 - If the gamma image is okay, move image to final. > Otherwise, create gammaTwo and delay one week. (Not likely with this > particular release, but this will be the general rule.) > > Friday, April 4 - Release! Bundles are uploaded to the ftp site, and > squeak.org is updated. > > _______________________________________________ > Squeakfoundation mailing list > Squeakfoundation(a)lists.squeakfoundation.org > http://lists.squeakfoundation.org/listinfo/squeakfoundation

2 1

Re: [Squeakfoundation]3.5 release timing (was Re: Outstanding 3.4 bugs?)
by Daniel Vainsencher 12 Mar '03

12 Mar '03

Doug, You're the Harvest Master, your word is law ;-) I'll go with whatever you think is best (and I thought of sending this before you agreed with me, honest! :-). I propose you announce a capsule decision on squeak-dev when you think the month should start. I agree with everything you said. About Accufonts, I think it depends on what Cees/Andrew can tell us about any discussions with Apple. It might be worth doing it regardless just to make sure we don't in any way delay/obstruct any advancement of the license front. I would really love to know that Andrew and Cees are talking, and we're getting Andrew's best (non-official) advice about how to go about this. Daniel Doug Way <dway(a)riskmetrics.com> wrote: > > On Wednesday, March 5, 2003, at 09:06 PM, Daniel Vainsencher wrote: > > > [about one quick fixes release] > > > > Doug said: > >> That does make some sense. A "very good" release might be a good > >> start > >> before getting down to splitting up the image and other work, as > >> opposed to a more average release. A reference release of sorts. And > >> good PR, I suppose. > >> > >> It would delay the "getting down to splitting up the image" by at > >> least > >> a month, though. > > People are posting "Remove <whatever>" packages, though slowly. I think > > I can help people to speed up and focus this process independent of the > > release schedule, as long as the fixes made do not break refactorings > > by > > including too many things. So as long as the fixes release is focused > > on > > the important stuff, I see no conflict. > > > > When we start 3.6, we'll have a few more removals ready to go. > > Yes, that's true... that work could continue during a short 3.5 bugfix > release. > > >> And I'm not sure it's *really* that important. So > >> I'm still on the fence, awaiting a few more opinions. > > Yup, I'd like to hear more too, but keeping in mind that - > > > >> But we do need to decide on the 3.5 release timing very soon... > > > > Daniel > > Well, I haven't seen any more opinions coming in against the idea of a > short bugfix release for 3.5 (although not many in favor have come in > either, aside from a few on squeak-dev). > > After thinking about it for awhile, I'm inclined to go along with the > idea of a short 3.5 bugfix release. We'd need to set the release date > for about 1 month from now, or perhaps 1 month from when we begin > harvesting fixes (which from the looks of it should be very soon). 2 > weeks alpha, 1 week beta, 1 week gamma, or something like that. > > I'm assuming that future releases (3.6 and beyond) will have a longer, > normal release cycle, which would allow enough time for enhancements, > refactorings, and package removals, in addition to bugfixes. Somewhere > between 3 and 6 months per release is what has been tossed around, but > we don't have to decide that just yet. > > If we do go ahead with this short plan for 3.5, we will need to be > strict about letting in only bugfixes, and even then trying to avoid > fixes which are overly invasive or widespread. As an example, the > Morphic Cleanup Project stuff seems to be mostly refactorings as > opposed to bugfixes. Very useful refactorings, of course. :-) But as > such, I would think most of that sort of stuff would wait until > 3.6alpha to be included. (Which isn't really *that* far away anyway, > and an organized project like MCP would probably warrant consideration > for inclusion right at the beginning of 3.6alpha.) > > IMHO, possibly the only non-bugfix item worth considering for 3.5 would > be removing the Apple fonts (assuming we decided to go with the simple > Accufont solution at first since that's pretty well tested), if we were > worried about delaying progress with Apple on the licensing issues. > But even that might be a stretch. > > Anyway, my two cents. > > - Doug Way > > _______________________________________________ > Squeakfoundation mailing list > Squeakfoundation(a)lists.squeakfoundation.org > http://lists.squeakfoundation.org/listinfo/squeakfoundation

9 12

Proposed 3.5 release plan
by Doug Way 12 Mar '03

12 Mar '03

On Mon, 10 Mar 2003 19:34:07 -0500, Doug Way wrote: > > ... > So, let's assume we go ahead with the current plan for 3.5 (only the > two > bugfixes unless another major bug comes up, release on April 4th). We > can > discuss it a bit more, but I'd like to announce this on squeak-dev > sometime > tomorrow as planned. > > Then, I could harvest the two bugfixes and put them in the 3.5alpha > update > stream. Then, soon after that (maybe a few days), we might as well > move 3.5 > straight to beta. At that point, we could offer the usual choice in > the > update stream for whether people want to move to 3.5beta or join the > new > 3.6alpha update stream. > > With 3.6alpha open, even while 3.5beta is still around, we could start > harvesting the fixes on sqfixes into 3.6alpha and see some of the > faster > turnaround and "visibility" that we've been hoping to achieve. There doesn't seem to be violent disagreement to this basic proposed plan so far :-), but I should probably flesh it out a bit more before announcing it on squeak-dev. (In some ways this seems like a bit of overkill in terms of process, for a two-fix release. New VMs probably do not need to be built in this case, and perhaps we don't need to bother with the usual press releases. (?) You could make a good argument that this could be more of a patch release, possibly named 3.4.1. But then even such a patch release would still need a testing period to make sure the fixes actually worked and didn't cause further problems. So I guess I don't have a big problem with calling it 3.5.) Anyway, here's the fleshed out proposed plan. Let me know if the dates and everything else sound reasonable. If it is, I'll announce it tomorrow night on squeak-dev. ----------------------- The 3.5 release will be a short release for the purpose of fixing a couple of serious bugs that have cropped up, and (to a lesser extent) to serve as a simple first-time release for the Guides, from beginning to end. The proposed release date is April 4th. This will give us a chance to get a release out quickly with these important fixes, but it will also give us a little bit of time to plan the post-3.5 release. The two fixes are MetaClassBuilderFix from Andreas Raab which fixes the class builder problem, and reverting a method which caused problems for anyone saving a project containing a .gif or .jpg (which is quite common). There won't be any other fixes accepted for this quick release, unless something comes up of similar severity to the project-saving bug. (Minimum requirements would be: several people independently mention it as a problem, the bug didn't exist in 3.2, and then the guides have to agree that it's worth including.) The reason we are being strict about this is because of the very short release cycle. However, this doesn't mean that the harvesting process started up at http://swiki.gsug.org:8080/SQFIXES/ will come to a standstill. Within a week, a 3.6alpha update stream will open up, and we can start moving fixes into it quickly. (We haven't officially decided that the next release will be called 3.6, but for now I'll use that name. 3.6 will have a longer release cycle.) Craig Latta suggested a "First Fridays" scheme for the final release date, which we will try here. (Releasing on the first Friday of the month.) That way we won't sometimes be releasing on a weekend, for example, which can be a problem for some people. Dates: Sometime tomorrow or so - Add the two fixes to the 3.5alpha update stream. Monday, March 17 - Move 3.5 to beta, and create a 3.6alpha update stream, allowing the usual choice when updating. Friday, March 28 - Create a gamma candidate image. Also, have a plan for the 3.6 release ready by this date. The plan should include a proposed list of major features, and a release date. Wednesday, April 2 - If the gamma image is okay, move image to final. Otherwise, create gammaTwo and delay one week. (Not likely with this particular release, but this will be the general rule.) Friday, April 4 - Release! Bundles are uploaded to the ftp site, and squeak.org is updated.

2 1

Decision time: Are SCG the steward of the kernel as proposed?
by goran.hultgren＠bluefish.se 12 Mar '03

12 Mar '03

Hi fellow Guides! When I just wrote the "monthly status report" I realized that we haven't really decided about "giving" SCG the Stewardship of the kernel. Of course, we guides are by no means "dictators" but we do have a responsibility to move discussions into decisions and after reading through this thread (the post from Alexandre Bergel felt like the "official request" from SCG) it looks to me that everyone is in favour of this arrangement. So someone needs to "hit the club in the desk", or whatever you call it. We talked a bit about what being a Steward means and we more or less came to the conclusion that we don't want to set any rules at this point. It is better to move ahead and learn. The only "guideline" that Andreas mentioned would be that as a Steward you simply need to be "more careful" when evolving the package - you obviously have much more dependents maintaining something in the kernel. What we all wanted was some form of charter from SCG what they plan etc but I think we have a pretty good picture already and it probably will not affect the decision here - which is more a question of trust in their capability and motives. :-) So, just to move forward one step: Can we Guides agree to give SCG this Stewardship? I vote yes. Let us all (us Guides that is) reply to this post so that we get a full count (6) and then we can make it "official", unless of course someone is against or still have things to discuss in which case we will just have to discuss further. regards, Göran

4 3

re: 3.5 release timing
by Daniel Vainsencher 11 Mar '03

11 Mar '03

This is all fine, except that in most cases, we don't know or control what will be in a release in advance. The most we can do is try to influence it, by explaining what is important in our opinions and why. I think it's more practical for us to be flexible about the content, but harsh about the timing/standards required for getting in. I'm starting to agree, though, that what grand plans we do make, we should announce before the previous release is out. About the contents of this specific release, I agree the project fix and the class builder fix are desirable (and are probably practical, since we have candidate fixes for both), but wouldn't reject out of hand other fixes posted if they are properly reviewed, tested, and very simple. Also, I think the font license non-issues should be smoked out finally by pulling in some apple-font removing package from SM. I would like to enlist at least all guides to help in making QA tags widely used. This requires, on the one hand, being the "bad people" and requiring more QA tags for submissions that don't have them, and OTOH, when review tags are added, doing our own review and highlighting what isn't good enough, to clarify what the tags actually mean. Being demanding is sometimes considered neither fun nor popular. but I submit to you that - A. it may not be popular, but it'll be far more popular than having a slow/ineffective feedback cycles. B. It CAN be a LOT of fun if you get in the right, nasty mood for it ;-) Daniel

3 5

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 March 2003