Squeakfoundation February 2003

squeakfoundation@lists.squeakfoundation.org

22 participants
36 discussions

Possible extra text for Welcome window in 3.4
by Doug Way 24 Mar '03

24 Mar '03

Scott mentioned awhile ago that he would be releasing a candidate image for 3.4gamma. I thought it might be helpful to at least have a mention of SqueakMap somewhere in one of the introductory windows of the image. So, here's a proposed paragraph blurb introducing SqueakMap. I thought it might be best located in the "Welcome to..." window, after the very first section but before the "Morphic" section. (The "*here*" link would be a DoIt link which would execute "TheWorldMenu openPackageLoader".) Or, it could go in ReadMe.txt or somewhere else, but I think the Welcome window might be best. Feel free to improve the wording, etc. (In theory, we could also have an introduction to the Guides, but I'm not sure that's as important. There's not really any mention of Squeak Central in the intro windows, anyway.) - Doug --------------------------------------- <bold>What's new in Squeak 3.4</bold> An exciting feature which has been made available in the 3.4 release is SqueakMap, a package catalog system for Squeak. As of this release, over 100 packages/applications have been added to SqueakMap by members of the Squeak community. You can easily browse and install these packages directly in Squeak by using the SqueakMap Package Loader, which is available from the "open..."/"Package Loader" menu (or, by clicking *here*). For more information on SqueakMap, see *http://minnow.cc.gatech.edu/squeak/squeakmap*.

5 16

Re: [Squeakfoundation]re: Outstanding 3.4 bugs?
by Daniel Vainsencher 04 Mar '03

04 Mar '03

I agree this is the most important bug that's up for discussion about 3.4. I'm not sure it's worse than the 3.2 bug we're trying to solve (public release doesn't include SM). Opinions? Suggestion - make 3.5 a very short release, consisting mainly of getting as many fixes in as we can, and giving them a proper testing. It's an opportunity for us Guides to warm up at doing the whole process ourselves. I'm talking about a time scale of 1 month total - 2 weeks alpha, 1 week beta, 1 week gamma, release. We start with specific, very doable goals (maybe even decide in advance a prioritized list of fixes we want to get in, not trying to catch up with everything that's up for harvesting), and basically spill them all into the update stream on day one, with the rest of the time for integration. Fixes that aren't ready for integration (meaning, posted tested, and reviewed by someone) by the end of week 1 will wait for 3.6. Doug, guys, do you think this is reasonable? desirable? Daniel Bert Freudenberg <bert(a)isg.cs.uni-magdeburg.de> wrote: > Am Freitag, 28.02.03 um 02:01 Uhr schrieb Doug Way: > > > > Craig Latta wrote: > >> > >> Hi Ned-- > >> > >>> Are we going to do anything about them? > >> > >> I think we should address them in 3.5, not 3.4. In the > >> absence of other > >> open issues, I think we should release 3.4. > > > > I was going to agree with Craig here, these bugs alone don't seem > > serious > > enough to postpone the 3.4 release. > > Are you going to include the other things that already have fixes? > > The "release" will be the one newbies use. They might not know how to > update, or even if they do, they might hesitate to do so (it is > somewhat scary to change your tires while running at 100 mph, isn't > it?). > > For example, I consider project publishing to be extremely important > for newbies and it has a bug we ran into, which fortunately was fixed > by Nishihara Satoshi > (http://groups.yahoo.com/group/squeak/message/54616). I tried with > 3.4gammaOne and the fix is not in there. > > -- Bert > > _______________________________________________ > Squeakfoundation mailing list > Squeakfoundation(a)lists.squeakfoundation.org > http://lists.squeakfoundation.org/listinfo/squeakfoundation

4 3

Re: [Squeakfoundation]re: release prioritization (was "ClassBuilder problem")
by Daniel Vainsencher 04 Mar '03

04 Mar '03

Hannes raised an important question - where does time pressure come from? He also raised another important question - why didn't we meet our stated goals? I think these are important enough, they deserve answering, not arguing about them. Time pressure comes from the nature and purpose of releases. One can say that any image at all of Squeak, with any combinations of changesets loaded, is a version of Squeak. What separates a release from any other version is that it's visible. All of it's natural and most important qualities come simply from that: it's rarity causes it to be visible. It's important to remember that people measure the quality of an implementation mostly by it's releases - not by fixes/packages that can be loaded, because probably no two pair of people will apply the same ones. This is meant to change when we have configurations, but that's the way it is now. What that means, is that right now, people measure us by 3.2. Most everyone on the list knows of SM, and loaded it for their 3.2, or just uses 3.4, which is nicely stable enough to load anything that doesn't touch the core as Island or Traits do. So we don't suffer much from the delay of this release. Or rather, not directly. Because newbies surely do. To newbies, loading anything into Squeak is still quite complicated, and the first thing they're likely to be told is not to use the official release, but a development release. That's a sign of a project that's not releasing often enough. If your production and your development are very different, you stop feeling the pains of the production, and you stop being aware of what your product is like, and you focus on the wrong things. If we have bugs (and we have more than just those handful that were mentioned), the solution isn't to delay the release, it is to have SUnit tests, use them, and keep them green. Think longer term - it's not about making a perfect release - that'll always be a good excuse to delay a little more. It's about having many releases, at quite frequent, predictable intervals, that are getting better and better, and keeping production and development close. That'll give us long term properties that will keep Squeak getting better. And no, I don't promise to never break anything that's worked before. First, nobody's ever promised that, neither the previous regime, nor any other maintainer except maybe Knuth. Second, the main technical benefit of an open source project is parallelized testing/debugging. But that is completely dependent on people actually doing it. Third, to promise strictly monotone-improving releases, I'd need SUnit tests with every change that gets submitted. Hmm :-) Now, why didn't all of the refactorings get in? well, there's a page on squeakfoundation swiki, devoted to the status of the intended refactorings. They're almost all done and waiting for (come on, I'm sure you know - ) testing. When people want to see them get in, they'll start testing, and as soon as people tell their authors that they load, or they don't load, or there's this problem or that or it's all very nice, we can actually do the work of clearing them to get in the image. In 3.5, of course. Why didn't we meet our goals? because the goals we stated and the actions of the wider community were not in line. I'm not shocked - this is a community, not an army unit. Also, the new "regime" is pretty new, so us and said community are still getting used to each other. Having alot of these releases, a time when emotions run high and soul searching is popular, will make the adaptation go faster. Daniel Hannes Hirzel <hannes.hirzel.squeaklist(a)bluewin.ch> wrote: > Roel Wuyts <roel.wuyts(a)iam.unibe.ch> wrote: > > Somebody needs to decide what is a release and what's get in there, and > > it was decided that these were the Guides. I trust them to do an > > excellent job at this, that is why they are responsible. I can imagine > > that there is some 'bigger plan' for which they want to have this > > release. The question for me is: 'what is this bigger plan'. If it is > > only that it was promised to have a new release by a certain time, then > > I agree with you that we can wait. But I guess the plan for 3.4 was to > > have SM up and running, and that is also important to get out so that > > everybody can enjoy it. > > Yes, adding SM and not breaking existing things. > > > >From http://swiki.squeakfoundation.org/squeakfoundation/79 > <citation> > 3.4 -- The main purpose of this release is to create an up to date, > viable version, that's a good starting point to making Squeak more > modular and it's development more decentralized. > > Changes: > - Includes non-modules related updates from 3.3a, including the dynamic > filelist services refactoring. > - An option to load the SqueakMap package catalog and the base Package > Loader from the net. > - A dynamic open menu so packages can now register there and become > first class applications. > - Refactorings making various parts of the image easily removable. See > Modularizing the Squeak image for the plan and status. > - Various other fixes have been included. > > Release is tentatively set to end of 2002. > </citation> > > > Regarding "Refactoring making various packages easily removable": > > There is just Balloon3DRemoval and GamesRemoval. I do not consider this > goal is met. > > > And breaking an important thing and not including the fix is surely not > good stewardship as well. > > > Again: Where does this time pressure at the expense of quality come > from? > > > Cheers > Hannes > _______________________________________________ > Squeakfoundation mailing list > Squeakfoundation(a)lists.squeakfoundation.org > http://lists.squeakfoundation.org/listinfo/squeakfoundation

4 3

re: release prioritization
by Hannes Hirzel 03 Mar '03

03 Mar '03

Hello Craig Craig Latta <craig.latta(a)netjam.org> wrote: > > Hi Hannes-- > > > > > Not having a proper test culture in Squeak leads us to have this > > > > kind of funny discussions. > > > > > > Perhaps you could elaborate as to what you consider a proper > > > test culture. > > > > An example of an emerging test culture > > > > > "Brent Vukmer" <bvukmer(a)blackboard.com> wrote: > > > I installed the MetaClassBuilderFix SAR in a 3.4gamma image, > > > installed the ClassBuilder test suite, > > > and then ran the ClassBuilder test suite > > > -- 3 out of 3 tests passed. > > Indeed, Great! You got the message about tests ;-) Let's move on to the next topic >but to what extent should particular tests delay a particular > release? I think that's the main issue here. > > > thanks, > > -C > Excellent question! IMHO the main issue is that if I look at http://swiki.squeakfoundation.org/squeakfoundation/70 I see the names of the guides: * Doug Way * Daniel Vainsencher * Ned Konz * Craig Latta * Göran Hultgren * Tim Rowledge Then I click on the link 'Release Plan' (http://swiki.squeakfoundation.org/squeakfoundation/79) Then I read 3.4 -- The main purpose of this release is to create an up to date, viable version, that's a good starting point to making Squeak more modular and it's development more decentralized. Changes: - Includes non-modules related updates from 3.3a, including the dynamic filelist services refactoring. - An option to load the SqueakMap package catalog and the base Package Loader from the net. - A dynamic open menu so packages can now register there and become first class applications. - Refactorings making various parts of the image easily removable. See Modularizing the Squeak image for the plan and status. - Various other fixes have been included. Release is tentatively set to end of 2002. ------ Now a question everybody who is looking at your work would come up with: Are these goals met and if yes by which criteria is this evaluated. You have put five points on this list. What do you have to say about them at the end of February? Postponing an issue is fully a viable option if there are important new reasons coming up. This has to be discussed and communicated. And: A list of open issues and major known bugs is surely a useful tool for guiding a development process. I do not see any links on the above mentioned pages. In the SqC area for various reasons Dan Ingalls used to be the "development process" (chief programmer approach). Because of his long experience he just took care of a lot of things. In the post SqC area the process should be made more explicit. We have all these nice tools and communication aids (mailing lists, Swikis / even world wide phone calls are accessible for many) - why not use them? I'm hoping that this stimulates you to not soley focus on schedule issues. I really recommend you to (re)read the excellent write-up by Daniel Vainsencher about the nature of releases http://aspn.activestate.com/ASPN/Mail/Message/squeak/1555651 (Email from today). Regards and happy Squeaking! Hannes P.S. My emphasis for having a proper (not perfect!) 3.4 release is motivated by my fears it might be the base for further development for a rather long time. This is fed by the fact that on the release plan (http://swiki.squeakfoundation.org/squeakfoundation/79) there is no single sentence about 3.5 not to speak of 3.6 and 3.7.

2 1

Re: [Squeakfoundation]re: release prioritization (was "ClassBuilder problem")
by Hannes Hirzel 03 Mar '03

03 Mar '03

Roel Wuyts <roel.wuyts(a)iam.unibe.ch> wrote: > Somebody needs to decide what is a release and what's get in there, and > it was decided that these were the Guides. I trust them to do an > excellent job at this, that is why they are responsible. I can imagine > that there is some 'bigger plan' for which they want to have this > release. The question for me is: 'what is this bigger plan'. If it is > only that it was promised to have a new release by a certain time, then > I agree with you that we can wait. But I guess the plan for 3.4 was to > have SM up and running, and that is also important to get out so that > everybody can enjoy it. Yes, adding SM and not breaking existing things. >From http://swiki.squeakfoundation.org/squeakfoundation/79 <citation> 3.4 -- The main purpose of this release is to create an up to date, viable version, that's a good starting point to making Squeak more modular and it's development more decentralized. Changes: - Includes non-modules related updates from 3.3a, including the dynamic filelist services refactoring. - An option to load the SqueakMap package catalog and the base Package Loader from the net. - A dynamic open menu so packages can now register there and become first class applications. - Refactorings making various parts of the image easily removable. See Modularizing the Squeak image for the plan and status. - Various other fixes have been included. Release is tentatively set to end of 2002. </citation> Regarding "Refactoring making various packages easily removable": There is just Balloon3DRemoval and GamesRemoval. I do not consider this goal is met. And breaking an important thing and not including the fix is surely not good stewardship as well. Again: Where does this time pressure at the expense of quality come from? Cheers Hannes

4 3

RE: [Squeakfoundation]Collecting tests?
by Brent Vukmer 03 Mar '03

03 Mar '03

I posted the "Kernel-Tests-ClassBuilder" tests to SqueakMap. I think it would be better to have tests in package-size chunks, like that. Goran, how about adding a "Tests" category to SqueakMap? Marcus, you could be the Steward of that whole category. That would be A Very Good Thing. -----Original Message----- From: Ned Konz [mailto:ned@bike-nomad.com] Sent: Friday, February 28, 2003 11:06 AM To: Discussing the Squeak Foundation Subject: Re: [Squeakfoundation]Collecting tests? On Friday 28 February 2003 04:08 am, Marcus Denker wrote: > Question: Would it make sense to start collecting tests > for the base image? As opposed to misplacing them? Of course it would. > What I have in mind is a SqueakMap Package that contains > all tests that get posted to the list. Just as a kind > of ad-hoc facility until better things are established. That sounds like a great idea. Do you want to maintain this? Thanks, -- Ned Konz http://bike-nomad.com GPG key ID: BEEA7EFE _______________________________________________ Squeakfoundation mailing list Squeakfoundation(a)lists.squeakfoundation.org http://lists.squeakfoundation.org/listinfo/squeakfoundation

6 7

re: release prioritization (was "ClassBuilder problem")
by Craig Latta 03 Mar '03

03 Mar '03

Colin writes: > I think it would be worth delaying the release of 3.4 to include this > fix. Having easy-to-install packages for Traits and Islands would be > very beneficial. The more people can play around with and exercise > that code, the better. I don't think that's a convincing rationale for inclusion in 3.4. The 3.4 release is a vehicle for SqueakMap. I think only problems which have a catastrophic effect on a newcomer's ability to use SqueakMap should delay 3.4. Ned writes (on the Foundation list): > ...since Andreas just posted the ClassBuilder fix, I'm thinking that > may be worth including and postponing the release by a few days for > people to test. Why? (And I don't use question marks lightly in this message, since I know they could cause more delay. :) > Since I'm doing that, I could also perhaps include Ned's recent > ArchiveViewer fix, since I've looked at that and its seems > straightforward and is a somewhat important fix. (: I don't think "somewhat important" cuts it at this release stage. Instead, I think it's better to weigh the results of leaving something out, rather than of including it. My recollection of our group discussions at OOPSLA, in November 2002, were that we would take 3.2, add SqueakMap support to it, and release it as 3.4. It is now February 2003. This surprises me, even given our history. :) I think we should release 3.4 now, and defer all outstanding available fixes into the 3.5a stream (subject to harvester approval). In our current situation, I think anyone likely to encounter the bugs described recently will be able to get them easily from the update stream. In the meantime, newcomers will have easier access to SqueakMap sooner. I think it's time to release. thanks, -C -- Craig Latta improvisational musical informaticist craig(a)netjam.org www.netjam.org/resume Smalltalkers do: [:it | All with: Class, (And love: it)]

3 3

Re: [Squeakfoundation]Collecting tests?
by Daniel Vainsencher 01 Mar '03

01 Mar '03

Why generate a class? this could make things hard to find. Just make a tool that adds a new method to "MiscTestCase". Maybe we won't accept this mess into the image <g>, but it makes adding a test trivial, and if it's good, it certainly can be maintained by someone on SM, and it's very easy to factor it out into it's own class in time. Daniel Mike Roberts <mike(a)mjr104.co.uk> wrote: > On Fri, Feb 28, 2003 at 05:39:52PM +0100, Andreas Raab wrote: > > Add a place to Squeak where it's _really_ easy to write a single > > test without having to make a class first > > > > I like your thoughts. How about a 'Test Pit' which is similar to a Workspace but allows you to write simple assertions about what you are testing. I can imagine how it would work but don't know how to implement it... (except in Python). Could you bind a subset of the methods of TestCase into the scope of the workspace so you could just write quick statements and then hit a button to do-it all and give you a quick result. Or maybe you could have a global QuickTest bound in the workspace which provided assert: deny: etc. Then you could possibly hit a button to generate a proper class for you after asking you for the name. If the text in the workspace only used the protocol of TestCase then it could just become the body of a test - you could neaten it up/ improve with the browser(s) later. > > The only thing I'm not quite sure about is getting the objects in that you want to test if they already exist somewhere. Maybe you could enable morph-workspace dropping, although I haven't played with that yet so I'm not exactly sure how that works. > > Does this sound like what you had in mind? > > If this was in the Tools flap then you could grab it out, write a test and then there could be suitable buttons for 'mail to list' etc. > > Mike > _______________________________________________ > Squeakfoundation mailing list > Squeakfoundation(a)lists.squeakfoundation.org > http://lists.squeakfoundation.org/listinfo/squeakfoundation

3 2

Re: release prioritization
by Craig Latta 28 Feb '03

28 Feb '03

> Great! You got the message about tests ;-) I've known the importance of tests for quite some time. -C -- Craig Latta improvisational musical informaticist craig(a)netjam.org www.netjam.org/resume Smalltalkers do: [:it | All with: Class, (And love: it)]

1 0

Re: release prioritization (was "ClassBuilder problem")
by Daniel Vainsencher 28 Feb '03

28 Feb '03

Actually, I think it would require some changes, if only because the process of making a release would need to be automated to the point that it doesn't take too much time. But Doug is more qualified to answer this. Daniel Simon Michael <simon(a)joyful.com> wrote: > Daniel Vainsencher <danielv(a)netvision.net.il> writes: > > If we have bugs (and we have more than just those handful that were > > mentioned), the solution isn't to delay the release, it is to have SUnit > > tests, use them, and keep them green. Think longer term - it's not about > > making a perfect release - that'll always be a good excuse to delay a > > little more. It's about having many releases, at quite frequent, > > predictable intervals, that are getting better and better, and keeping > > production and development close. That'll give us long term properties > > that will keep Squeak getting better. > > +1, well said. > > I've found releasing on the first of every month to be a useful discipline. > What changes would be needed to make this practical for squeak, I wonder ? > Maybe none. > > Thanks for your work, guides. > -Simon > _______________________________________________ > Squeakfoundation mailing list > Squeakfoundation(a)lists.squeakfoundation.org > http://lists.squeakfoundation.org/listinfo/squeakfoundation

1 0

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