Squeak-dev February 2003

squeak-dev@lists.squeakfoundation.org

195 participants
766 discussions

RE: Possible goals for future releases (was: Re: Let's Release 3. 4)
by Swan, Dean 01 Mar '03

01 Mar '03

> -----Original Message----- > From: Cees de Groot [mailto:cg@cdegroot.com] > Sent: Friday, February 28, 2003 6:31 PM > To: The general-purpose Squeak developers list > Subject: Re: Possible goals for future releases (was: Re: > Let's Release > 3.4) >You set goals or you set dates. As long as this is a volunteer effort >where people wildly fluctuate in the amount of time they can contribute, >you cannot set both. > >I'm in favor of setting dates. I think you need to propose targets for BOTH goals and dates, with an understanding that either the goals or the dates are the higher priority. Some goals may be high enough in importance that you are willing to move the date, and some goals may not be that important. Setting dates provides a motivation for people to choose to spend some of their time on things that they want included. If you only set dates and no goals, Squeak is less likely to get assigned a priority in people's daily lives, and the date may arrive with nothing new to release. I think these ideas are fairly basic principles of project management, but feel free to disabuse me of my pre-conceptions. -Dean Swan

2 1

Beta test Bitstream Vera fonts available.
by Jim.Gettys＠hp.com 01 Mar '03

01 Mar '03

Not yet under the final license, but you can download from: See: http://www.gnome.org/fonts for all the gory details. Enjoy. - Jim -- Jim Gettys Cambridge Research Laboratory HP Labs, Hewlett-Packard Company Jim.Gettys(a)hp.com

8 24

re: release prioritization
by Daniel Vainsencher 01 Mar '03

01 Mar '03

Hi Hannes. Let's see if we can summarize and answer your points - [Tests] Tests are needed, us Guides know this, you're preaching to the choir. The community should continue to supply tests, and some will be used to approve releases. We won't use tests we don't have. If someone compiles, as has been suggested, a test package on SM, it might help. [Status - everyone should know where each release stands. Could be solved with a bug/issue DB] You're right. We need such a tool, but - we need more urgently a fix tracking tool, to make sure we don't lose work that people submit - fixes are higher priority than bugs, because people become more upset when you lose their changesets than when you ignore their bugs. We're planning to make such a tool, but we haven't made much progress in that, either. We could really use some help from the community with either of them. About reporting status - Actually, in the Linux community, there's a guy that simply follows the discussions, Linus and gets updates from other developers, and maintains a list of patches/issues, and where in the pipeline they are (planning coding testing in - sort of like the list I made for refactorings). He updates this list and posts it publically every so often. This could be done once a month. As you say, it would help everyone immensely, by keeping us all on the same page and showing us exactly what's stuck. If anyone from the documentation project or at all is volunteering to provude such a status report on a regular basis, that'd bee a meaningful contribution to the community. [You want a near perfect release for 3.4] Your objections have been noted, the bugs have been rated as non-critical, and a release will be issued at Doug's convinience. Fixes for the bugs that have been proposed will be reviewed and passed into 3.5a quite soon after the release of 3.4. [You fear that 3.4 will last a long time because there's no explicit plan for 3.5] One will be made, after 3.4 is laid to rest, with the participation of the community, as you've been told by both Craig and I before. Your fears are probably unfounded - we have spoken about 3.5 as a probably second short release to get the process optimized. You're welcome to find this on the squeakfoundation archives, where all discussions on this topic reside. [focus] We don't at all focus solely on schedule issues, to say this is to ignore the distinguishable amounts of verbiage us Guides have been generating, some of us more than others, on completely other topics <embarrassed grin>. But actually, our sole page of real hard policy, which is linked off the release plan page, is "the lifecycle of a release" page, which you should read, because it's concerned with quality, and it is that that we're attempting to follow. Daniel Hannes Hirzel <hannes.hirzel.squeaklist(a)bluewin.ch> wrote: > 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: release prioritization
by Hannes Hirzel 01 Mar '03

01 Mar '03

Hi 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. > Cheers Hannes

3 2

Re: [Squeakfoundation]re: release prioritization (was "ClassBuilderproblem")
by Doug Way 01 Mar '03

01 Mar '03

Hannes Hirzel wrote: > > Hi Doug > > Doug Way <dway(a)riskmetrics.com> wrote: > > > > Okay, I'm very easily talked out of delaying the 3.4 release any > > further :-) (and was having second thoughts after posting that last > > message), so I agree with the prevailing opinion to leave this change > > out and go ahead with the release. > > Well of course you guides can do anything you want "releasing" things, > i.e. putting a label on a jar and call it a "release". Not having a > proper test culture in Squeak leads us to have this kind of funny discussions. > Measuring risk just with a feeling in the guts? "I feel like > releaseing... > I'm scary of metaclasses ....people don't use them anyway...". Well, the way I phrased it ("I'm very easily talked out of delaying the 3.4 release...") may have made it seem that I suddenly decided to go ahead with the release on a whim. But that's not really the case. I (and the other Guides) believe that leaving this fix out is the right thing to do at this stage of the release. We do have some (admittedly rough) standards that we're trying to follow during the release cycle. See: http://swiki.squeakfoundation.org/squeakfoundation/89 3.4 is currently in "gamma" status, which is basically a candidate final release, and that means that only critical problems should hold up the release. It's hard to define "critical" precisely, but it would have to be something that made the system unusable to a large portion of users. The ClassBuilder problem is significant, but would really only affect people who need to rebuild all of their classes, which is only required by a few (relatively experimental) packages. And there may be significant risk in adding this fix to 3.4 at this late stage... changing the ClassBuilder is a pretty fundamental change. It might have some subtle side effect on the way classes are made obsolete, I don't know. I'm sure Andreas would not absolutely guarantee that it is side-effect-free. :-) So, even allowing 3 days to test this sort of change might not be enough. Anyway, these are typical issues for any software release. At some point you do have to decide that enough changes/fixes have gone into a particular release, and we need to put the remaining larger changes/fixes into the next release. I was starting to fall into the "just one more fix" trap myself here. Of course there needs to be an overall plan, too, which we roughly adhered to for 3.4, although the final release date is now quite late for various reasons, mostly related to the Guides taking over responsibility from SqC. (We are new at this, after all.) Regarding 3.5 content, I agree that that needs to be discussed... I imagine discussions will start up on that topic soon on the SqF list. (Ah, I see you just started a thread here on squeak-dev...) - Doug Way

1 0

Possible goals for future releases (was: Re: Let's Release 3.4)
by Hannes Hirzel 01 Mar '03

01 Mar '03

"Brent Vukmer" <bvukmer(a)blackboard.com> wrote: > Newbies need SqueakMap! Let's get the SqueakMap love out there. > > We can do all of the following things starting next week: > --start collecting a queue of 3.5a fixes > --test the ClassBuilder stuff > --start documenting what was and was not accomplished in 3.4 release > --set goals for the 3.5 release Goals? Why not start discussing them now? A starter for the discussion - ---- Release 3.5 - Include the ClassBuilder stuff - Include what MCP accomplished - Refactorings making various parts of the image easily removable. (was in 3.4 - http://swiki.squeakfoundation.org/squeakfoundation/79) - Have it tested with 1000 unit tests before releasing 3.5 final. Release date for 3.5 beta - End of March Release date for 3.5 gamma - End of April Release date for 3.5 final - End of May Motto - a fresh Squeak! or - a tested and polished Squeak! ---- Release 3.6 (final for end of August) Include basic Zurgle refactorings ? Include Anthony Hannans work ? Have a clean up of MetaClass and Co by Berne ? Motto - <no idea yet> ---- Release 3.7 (final scheduled for end of November) Have documentation updated and integrated in various ways with the image. Core is "only" 1000 classes. "Virtual Releases" - Anglo-Saxon edition (the current stream) International edition (Nihongo and others, UCS/Unicode integrated into the VM) Berne edition (Language experiments - alternate syntaxes) > Let's roll let's roll let's roll! Yessss .... Cheers Hannes

2 1

Let's Release 3.4
by Brent Vukmer 28 Feb '03

28 Feb '03

Newbies need SqueakMap! Let's get the SqueakMap love out there. We can do all of the following things starting next week: --start collecting a queue of 3.5a fixes --test the ClassBuilder stuff --start documenting what was and was not accomplished in 3.4 release --set goals for the 3.5 release Let's roll let's roll let's roll!

1 0

Re: [DOCS] Constructive Development Process (was: re: release prioritization)
by Daniel Vainsencher 28 Feb '03

28 Feb '03

I'd be willing to work with something like this. A few comments - IMO, SQEPs need a lighter name. BOOS (Benevolent Oligarchy Of Squeak), aka, Squeak Guides. I think we really prefer the chosen name, if you don't mind. Didn't quite understand the intended difference between that and the editor. I don't mind (read - would be glad if) there's someone else that handles all the SQEP initially, but since we're likely to decide if it's going into the image (assuming that it even should) maybe we're the editors? like I said, I don't understand that nuance. SQEPs should also have a section where they detail a transition plan, including * how it avoid breaking anything important, and * what it's likely to break anyway, and * how it get's split into lots of little stages that people can approve in finite time, accepting finite risk * How it'll be presented to the community in a testing friendly format before us Guides are make positive decisions about it (I promise to immidiately reject anything, without undue delays, if so requested by the author ;-). Daniel Serge Stinckwich <Serge.Stinckwich(a)info.unicaen.fr> wrote: > On Fri, 28 Feb 2003 17:32:55 +0100 > Hannes Hirzel <hannes.hirzel.squeaklist(a)bluewin.ch> wrote: > > > > > Craig > > > > Craig Latta <craig.latta(a)netjam.org> wrote: > > > I think we do have a constructive process. > > > > You rise an important issue. I think this deserves attention. > > > > Serge Stinckwich was suggesting on 17-Feb that we should think about the > > development process. > > I start to write a text for the development process. Right now, it's just a rough copy of Python PEP > with some Squeak adaptations. Your comments are welcome. > > Look at : http://www.iutc3.unicaen.fr/serge/244 > > -- > Serge Stinckwich -< ) multiagent.com > Université de Caen>CNRS UMR 6072>GREYC>MAD /~\ squeak.org > http://www.iutc3.unicaen.fr/serge/ (/ | zope.org > Smalltalkers do: [:it | All with: Class, (And love: it)] _|_/ debian.org

1 0

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
by Daniel Vainsencher 28 Feb '03

28 Feb '03

Makes perfect sense to me. Daniel Jimmie Houchin <jhouchin(a)texoma.net> wrote: > From my memory, it seems that the most recent goal of a 3.4 release was > to finalize Squeak as a release which primarily occurred under the > stewardship of Squeak Central. > > Squeak 3.5x and forward were to be the releases under the Guide system. > It can be somewhat confusing since it appears that a "Guide" is > releasing 3.4. However, the purpose did not change. > > While Squeak is not currently under any commercial or business type time > pressure, there are people who do base certain events on releases. For > example Stephane Ducasse sometimes releases materials (writings) which > are based on a certain Squeak release. Some people burn cds for > education and other distributions. So having a certain release which is > frozen does advantage these people. Sometimes do to their release > schedules some time pressure can be asserted. > > I hope this makes sense. > > Jimmie Houchin

1 0

← Newer
1
2
3
4
5
6
7
8
9
...
77
Older →

Jump to page: