Squeakfoundation March 2003

squeakfoundation@lists.squeakfoundation.org

27 participants
66 discussions

RE: [Squeakfoundation]3.4 press release
by Brent Vukmer 07 Mar '03

07 Mar '03

Maybe modify "Beneath its graphical user interface, it is powered by a descendant of the Smalltalk-80 language."? I don't know if you want to mention Morphic, but you could say something like "incorporated key concepts from Self" -----Original Message----- From: Cees de Groot [mailto:cg@cdegroot.com] Sent: Thursday, March 06, 2003 4:40 PM To: squeakfoundation(a)lists.squeakfoundation.org Subject: [Squeakfoundation]3.4 press release Hi, I had a bit less time than I expected tonight, so I wasn't able to give the attention I wanted to the 3.4 press release. Nevertheless, I dare to ask you to take a look at this draft: http://swiki.squeakfoundation.org/squeakfoundation/95 and comment on it. The last paragraph is destined to become the standard Squeak blurb for press releases, so I'd appreciate some extra attention to detail here. Regards, Cees h.t. External Relations Volunteer

2 1

FW: [Squeakfoundation]Stewards and Squeak Packages
by Brent Vukmer 06 Mar '03

06 Mar '03

oops .. meant to post this to SqueakFoundation list -----Original Message----- From: Brent Vukmer Sent: Thursday, March 06, 2003 5:26 PM To: The general-purpose Squeak developers list Subject: RE: [Squeakfoundation]Stewards and Squeak Packages I have re-titled, and lightly edited these three pages ( mostly, gotten rid of "Core" language ): "Factoring Squeak 3.4+ into Packages" ( http://minnow.cc.gatech.edu/squeak/3084 ) "3.4 Packages" ( http://minnow.cc.gatech.edu/squeak/3085 ) "Stewards for Packages" ( http://minnow.cc.gatech.edu/squeak/3088 ) The only long-term purpose for the "3.4 Packages" page is a historical record to compare too, as we factor the image going forward... Further comments/edits/puns are welcome!

1 0

Re: [Squeakfoundation]Stewards and Squeak Packages
by Daniel Vainsencher 06 Mar '03

06 Mar '03

Ok, I'll be reviewing those in detail. A pretty good start. At the Becoming a Steward page, I added a relevant mail of mine from a while ago. Please let me know if it conveys the spirit of it, or is nothing but a favorite rant. http://minnow.cc.gatech.edu/squeak/3091 Daniel Brent Vukmer <bvukmer(a)blackboard.com> wrote: > Please review the following Swiki pages: > "Core Packages" ( http://minnow.cc.gatech.edu/squeak/3084 ) > "3.4 Core Packages" ( http://minnow.cc.gatech.edu/squeak/3085 ) > "Stewards for Core Packages" ( http://minnow.cc.gatech.edu/squeak/3088 ) > > I think that the "Stewards for Core Packages" page is a decent beginning for a Stewards sign-up sheet. > _______________________________________________ > Squeakfoundation mailing list > Squeakfoundation(a)lists.squeakfoundation.org > http://lists.squeakfoundation.org/listinfo/squeakfoundation

1 0

Stewards and Squeak Packages
by Brent Vukmer 06 Mar '03

06 Mar '03

Please review the following Swiki pages: "Core Packages" ( http://minnow.cc.gatech.edu/squeak/3084 ) "3.4 Core Packages" ( http://minnow.cc.gatech.edu/squeak/3085 ) "Stewards for Core Packages" ( http://minnow.cc.gatech.edu/squeak/3088 ) I think that the "Stewards for Core Packages" page is a decent beginning for a Stewards sign-up sheet.

2 1

Future release process (was: [Squeakfoundation]3.5 release timing)
by Daniel Vainsencher 06 Mar '03

06 Mar '03

Doug Way <dway(a)riskmetrics.com> wrote: > Not really. I'm not sure that the Visibility argument is that > compelling, though. No, no no - misunderstanding. These are not arguments I am giving for making more releases! They are desirable properties of our process, which are affected by releases, but which I think we can better improve by other means. > Okay, perhaps by Visibility you also mean the fact that a newbie's bug > report might get fixed and released into a stable version sooner with > frequent releases than it would have otherwise. For a start, a newbies bug should not be irrelevant - "Already fixed in the 3.7 alpha". But I think it's even more important to focus on visibility for non-newbies. When something is in beta/gamma stages, right now, everything that people develop for the image basically stops getting feedback, because nobody is trying to harvest it. Even worse, even in alpha, harvesting is going too slowly, so that work and feedback is often separated by months. This means people don't SEE what they are doing. It's like driving with your eyes closed, based on reports from the person in the other seat, except he's reading a book most of the time. Making release faster could bring this does from six months to two. What we need, really, is for this to work in a framework of days or weeks. Which means making things alot more distributed. An official policy allows people to give themselves feedback. If the policy specifies tools like SLint, they can even get some objective feedback. And project groups like MCP and KCP allow people to get feedback from a group of focused experts. Both are not tied too the release cycle. > In the meantime, I will try to outline a brief harvesting process (say, > tomorrow), at least, that we could debate very briefly and then use to > harvest things, by hand at first, and then use that process as a basis > for the tool. I think we can speed up harvesting in a simple way. Specify these "goodness criteria"- - Has gone through indepedent review - Has been independently tested - Has been passed through SLint, with every finding inspected (and the relevant ones fixed) - Has a detailed documentation of the rationale for every change - Is small (<10k) These aren't absolute requirements. Instead, they determine priority. The more of these properties you fix has, the sooner it'll happen. We can do this by simply sorting the list accordingly. Then, if people care about a specific fix, they'll review it, test it, SLint it, document it, and make sure it is in small pieces. That will surely improve speed up the bottleneck process of evaluation. Fixes that don't recieve this attention, might not (yet) deserve ours. Daniel

2 1

Squeakland fixes
by Michael Rueger 06 Mar '03

06 Mar '03

Hi all, attached are the form related fixes from the squeakland update stream. Especially nr 143 would be important in respect to the "black rectangles" problem. Michael

1 0

Re: New download page for 3.4
by Ted Kaehler 05 Mar '03

05 Mar '03

Bruce, The new download page for 3.4 is out on Squeak.org. --Ted. At 5:24 PM +0100 3/5/03, Bruce O'Neel wrote: > >A new download page for the 3.4 release. Thanks!

3 3

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

05 Mar '03

I think Ian raises an important point. We need to remember what goals our releases are intended to achieve. First of all, their importance is waning. This is a good thing, and has several reasons. - Nobody is waiting for us to publish their cool application. - Starting from a stable 3.4 image, a person can right now write a script that loads his favorite packages from SM and his favorite fixes, and get almost whatever image they want. This can even be put on SM and thus shared, though it's not very well integrated because SM doesn't have support for card versions/other amenities that may or may not be required (Goran - ;-). - Soon we will have dependencies, and people will maintain their own "distributions". What are releases still needed for? - Newbies coming in without the knowledge to determine their own environment. These are certainly no reason to have very frequent releases. They're a moderate/weak reason to have one fix release, in order to fix project saving, but I suspect most of the project saving people of the world either can fix the bug from knowledge, or are getting their image from squeakland, which I've heard has it fixed. - A common reference platform for human communication (I have 7.8, update 100023, and these loaded, and the Muffin Materialization demo just doesn't work!). Doesn't require releasing very often, quarterly is probably better than monthly, less confusion. - A common platform for packages, in the presence of a process where things are leaving the image, and becoming packages maintained by the community. Ah. Since we don't yet know how it'll work, we just don't know. I'll bet it won't require releasing very often at least until we're in there removing the Browser, or Compiler. Nothing really should care very much if Celeste is in or not. So why are people (me included) clamouring for more frequent releases? well, they all seem to be really asking for two things - visibility and speed. Visibility - we know where we are, what we have is more or less what newbies are downloading, what we're using off the update stream is as near as possible everything that's been reviewed. Speed - get things harvested faster, get fixes/enhancements stabilized faster. Does anybody see any other reason to have very frequent releases? The only thing here that depends on the releases, is the aspect of making something nice for the newbie, and around quarterly would probably be just dandy. So what am I saying? I think getting one more release relatively quickly, with just fixes, would be a good thing, because we'd have a very good release out there, and be quite sure we can make those whenever we want. Call me insecure, but I prefer to have a very good release out there, and not a "maybe about the same, maybe not quite as good" release, where we still depended on Scott. Then we can rest easy and think about other things. Whether it takes 4 weeks or 8 isn't that critical to me. And then, we have some issues with our process, regarding speed and visibility, that we should improve. Part of it is having a clear message out there about how to get ones fixes in quickly (do all the work for us, of course :-). Part of it is maybe some distributed way of getting feedback, maybe without depending on a magic server somewhere spewing reports. Daniel Ian Piumarta <ian.piumarta(a)inria.fr> wrote: > > On Tue, 4 Mar 2003, Doug Way wrote: > > > Hmm. Having gone through the process (well, at least most of it), I > > suppose a one-month release might be barely workable if the goal was > > limited to fixes only as you say. One problem has been coordinating > > things via email (such as new VM releases, getting problems fixed), but > > I suppose these things get better when people know what to expect after > > the first time through. > > On a personal note I'll just mention that making a VM release takes me an > entire day (while I recompile on four different machines and construct > more than a dozen seperate archives, _very_ slowly and methodically to > make sure I don't mess anything up too badly). I wouldn't want to do this > every single month. (Consider the 3.4gamma1 release as an > exception.) Every quarter might be acceptable. > > I realise that the VMs change much more slowly than the image itself and > new VM releases are only really be needed when something in the VM related > code (or the plugins) changes. OTOH, it would be slightly confusing if > the latest VMs had lower version numbers than the latest stable images > (pretty much consistently, modulo the occasionaly four-week period when > the versions coincide after a VM-related change). > > I think the whole regular release cycle is a bad idea anyway. Even with > the current infrequent big releases I tend to lag behind the stable image > by a version or two, since there's just not enough incentive to change > until something is _obviously_ better (or new and exciting) in the latest > image. My most recent image change was from 2.3 to 2.8. If releases were > more frequent then deltas would be smaller and I'd be even less likely to > notice new stuff or improvements and hence track the latest image. I'm > probably not alone in thinking/working this way. > > Just my 2 centimes of a Euro worth. > > Ian > > _______________________________________________ > Squeakfoundation mailing list > Squeakfoundation(a)lists.squeakfoundation.org > http://lists.squeakfoundation.org/listinfo/squeakfoundation

2 1

Re: Outstanding 3.4 bugs?
by Daniel Vainsencher 04 Mar '03

04 Mar '03

Simon, the reason I very much am waiting to hear Doug on this topic, and speaking about 1 month releases should be very tentative, is that none of us has Actually Done It. Doug might know how much the price of a release is, and how much it might be reduced, and whether he has time for it/someone else can do it in reasonable time, and those'll be the prime considerations in deterimining how often it will happen. Even doing only a short first release (without setting a fixed rythm yet), as I propose, depends on these parameters. Daniel Simon Michael <simon(a)joyful.com> wrote: > Tim Rowledge <tim(a)sumeru.stanford.edu> writes: > > I find it just about impossible to imagine getting stuff done that > > quickly given the geographic and chronologic spread of people involved. > > It'll take more than two weeks before any decent number of people heve > > even downloaded 3.4, let alone done anything much to find and fix any > > bugs. > > I think it's hard to imagine because we're all used to a different > process. However, with a steady monthly rhythm and known dates we would > all soon adjust. Eg when the world knows that "3.x comes out on the 1st" > it will get downloaded a lot quicker. If bugs or major enhancements aren't > ready in time for the release, fine, they show up next month (or the month > after or..). > > NB in the worst case, release time rolls around and noone's had time to do > anything this month, we'd be just re-releasing (we'd probably skip that > one). That's fine. The larger process is far more important. > > Of course we can debate the optimal duration of an "iteration" - one > month, two months, three.. personally I feel one month works here. A > faster cycle allows us to learn and improve the process more quickly. > _______________________________________________ > Squeakfoundation mailing list > Squeakfoundation(a)lists.squeakfoundation.org > http://lists.squeakfoundation.org/listinfo/squeakfoundation

4 3

UI editor?
by Timothy 04 Mar '03

04 Mar '03

Is there any UI editor in the works? I look at Squeak every so often, but I still see no way of creating user interfaces that do not require a inordinate amount of work. Morphic may be fine for animating bunnies, but what about writing a user interface?

2 1

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