Squeakfoundation February 2003

squeakfoundation@lists.squeakfoundation.org

22 participants
36 discussions

re: release prioritization
by Daniel Vainsencher 28 Feb '03

28 Feb '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.

1 0

re: release prioritization
by Craig Latta 28 Feb '03

28 Feb '03

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, but to what extent should particular tests delay a particular release? I think that's the main issue here. thanks, -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

Collecting tests?
by Marcus Denker 28 Feb '03

28 Feb '03

Hi, Question: Would it make sense to start collecting tests for the base image? 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. Marcus -- Marcus Denker marcus(a)ira.uka.de -- Squeak! http://squeak.de

3 3

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

28 Feb '03

Well, I was thinking you *could* code/maintain some tests -- but even more importantly, get a process going ( perhaps like Andreas just described ) and once it gets going, keep it rolling! Squeak Needs Stewards! -----Original Message----- From: Marcus Denker [mailto:marcus@ira.uka.de] Sent: Friday, February 28, 2003 11:43 AM To: Discussing the Squeak Foundation Subject: Re: [Squeakfoundation]Collecting tests? > Goran, how about adding a "Tests" category to SqueakMap? Marcus, you > could be the Steward of that whole category. Yes, we should have a default-maintainer for all test-packages that the package-maintainer him/herself don't want to manage... Marcus -- Marcus Denker marcus(a)ira.uka.de -- Squeak! http://squeak.de _______________________________________________ Squeakfoundation mailing list Squeakfoundation(a)lists.squeakfoundation.org http://lists.squeakfoundation.org/listinfo/squeakfoundation

1 0

[DOCS] Constructive Development Process (was: re: release prioritization)
by Hannes Hirzel 28 Feb '03

28 Feb '03

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. Serge Stinckwich <Serge.Stinckwich(a)info.unicaen.fr> wrote: > Hi all, > > i just found that the Python community use something they called PEP (Python Enhancements Proposals). > PEP are design documents describing new feature for Python. There is a workflow that deals whith how the PEPs are manage > by the community. > > Look at the PEP Purpose and Guidelines : http://www.python.org/peps/pep-0001.html > and the index of PEP here : http://www.python.org/peps/ > > Maybe, we can build something like that for Squeak : Squeak Enhancements Proposals (SEP) ? > in order to have a more rigourous development process. Is it possible for you to do a short write-up of what you think when you speak of a constructive process? Where do you see the pros and cons? How do you think things should change in the future? A short write-up (bullet list) would already be a great start. If you come to the conclusion that the term 'constructive process' is not well chosen you may change it of course. Perhaps there is already some material on this - then an update and sending in the pointers to the list is sufficient! If you could work on this that would be great! Regards Hannes

1 0

re: release prioritization
by Hannes Hirzel 28 Feb '03

28 Feb '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

1 0

Outstanding 3.4 bugs?
by Ned Konz 28 Feb '03

28 Feb '03

These bugs (and more, like the much-discussed bug with adding an instVar to ClassDescription) still exist in 3.4g. Are we going to do anything about them? [BUG] Flap icons in tools flap disappear in 3.4 (23 February 2003) Jim Benson (23 February 2003) http://swiki.gsug.org:8080/sqbugs/715.html [BUG] Setting a gradient background after setting a texture background (21 February 2003) Michael Roberts (21 February 2003) http://swiki.gsug.org:8080/sqbugs/711.html [BUG] TextPropertiesMorph - overflow (28 January 2003) Webb McDonald (28 January 2003) http://swiki.gsug.org:8080/sqbugs/691.html -- Ned Konz http://bike-nomad.com GPG key ID: BEEA7EFE

5 5

re: release prioritization
by Craig Latta 28 Feb '03

28 Feb '03

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. In the meantime, I think we do have a constructive process. In particular, we decided we wanted to make a release which supported SqueakMap. We did this, we tested it, and now we're going to release it. > Measuring risk just with a feeling in the guts? No; I think Doug is measuring risk by estimating the impact of leaving out changes on the system's likely audience. > "I feel like releaseing... I'm scary of metaclasses ....people don't use them anyway...". No one said that. :) > But there is no idea if a release is better then an old one on the > existing stuff or not. It's my understanding that we're gradually building up unit tests for the entire system. We're making progress. We're not there yet, but I don't think it should hold up releases, especially minor ones. > For me 3.4 will be a "release" which is not proper Smalltalk (in > the sense of the last 20 years) as it breaks in a fundamental way > without the fix by Andreas. There are many other fundamental bugs in the system, several of which have been in the system for many years. The assertion is that their impact on the usability of 3.4, particularly on its new functionality (SqueakMap), is low. > He really has done an *excellent job*. And the test case he > provided in just 30 minutes is wonderful! And the > community is not able to verify his fix in 3 days ?? I don't think anyone disputes the quality and verification of Andreas' fix. But the actual act of incorporating it into a release, and testing for errors that occur during that act, take time. Given the relatively low impact of that bug (even though that part of the system is indeed fundamental), there seems to be no disadvantage in deferring the fix to 3.5a. It seems to me that we were getting bogged down with a "just one more" mentality. Yes, a particular fix may take add three days to a release cycle, but these delays add up. For me, the delays make the Squeak project markedly less satisfying. Right now, I'd like to be able to tell newcomers "take a look at Squeak from squeak.org" and know that they'll get a release with SqueakMap support. > The 3.4 release was planned for the end of 2002. No we are two month > later. Four, actually. :) > I wonder where this time pressure comes from? Obviously, since this is a volunteer effort, there is no direct time pressure. Rather than time pressure, I think there is motivation; in this case, a motivation to support SqueakMap in the release that most newcomers will use. I also think it'd be good for us as a community to develop expeditious release skills. In my opinion, we were overrating the importance of several features and fixes with regard to the release schedule. > On the other side at least some customers do not want a buggy 3.4. Again, I posit that relatively few people are likely to encounter the bug to which you refer, and those who do will be eminently capable and motivated to ge the fix. If you disagree, let's hear your rationale. As you mentioned, the stakes are relatively low. I'm surprised that you're so upset at deferring the rest of the fixes. This is a minor release (3.x). I'd certainly like to be more conservative with release 4, but the sorts of fixes we're discussing now are what minor releases are for. > On the other side this discussion about "releases" is in some > sense a non issue as probably in the future we will have > different configurations which will be packed for various > target groups and automatically tested before releasing. Indeed. In fact, I think eventually the release artifact will be laughably tiny. > I could live with the idea of a buggy 3.4 if 3.5 for example > is planned for doing in two months time. Then 3.4 would > just be some kind of intermediary release. Precisely. :) > The heading speaks of "priorization". Where are > the plans for future releases? Non-existant! Clearly, then, now is the time to make the schedule. If you have suggestions, let's hear them. Remember that Squeak has never really had a priori feature/fix schedules before. I'm all for them. > Is there a check list what 3.4 should be? Yes. It was verbalized at the Squeak BOF at OOPSLA 2002, then discussed on the list, where consensus was (seemingly) achieved. The checklist consisted simply of "SqueakMap support". > You guides, please do your homework! This stuff needs to be done via public discussion; I don't think it's appropriate for the guides to come up with it by themselves. -C p.s. I'm not even going to touch the Microsoft comments. ;) -- 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: [Squeakfoundation]re: release prioritization (was "ClassBuilder problem")
by Hannes Hirzel 28 Feb '03

28 Feb '03

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...". Releaseing something at the moment just means that enough new features have been added and the guides feel that people have not been complaining too much about new bugs. But there is no idea if a release is better then an old one on the existing stuff or not. Be assured the first thing I will do after downloading your release is to include the fix of Andreas and already I will not work on your "release" anymore. And many of the list members will just do the same. For me 3.4 will be a "release" which is not proper Smalltalk (in the sense of the last 20 years) as it breaks in a fundamental way without the fix by Andreas. He really has done an *excellent job*. And the test case he provided in just 30 minutes is wonderful! And the community is not able to verify his fix in 3 days ?? I wonder where this time pressure comes from? The 3.4 release was planned for the end of 2002. No we are two month later. So what? Are customers pressing somewhere? In fact that would be good. On the other side at least some customers do not want a buggy 3.4. MS projects often get delayed much longer and with the .NET initiative (an approach with a VM as well!) they want to do it "right", even if that causes delays! Again: where is the time pressure? There a good releases and others. Regards Hannes Hirzel P.S. On the other side this discussion about "releases" is in some sense a non issue as probably in the future we will have different configurations which will be packed for various target groups and automatically tested before releasing. I could live with the idea of a buggy 3.4 if 3.5 for example is planned for doing in two months time. Then 3.4 would just be some kind of intermediary release. P.S. 2 The heading speaks of "priorization". Where are the plans for future releases? Non-existant! Is there a check list what 3.4 should be? I didn't find it yet although as a member of the documentation team I had surfed a lot over the existing Squeak web pages and I was active at the mailing list. You guides , please do your homework!

2 1

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

28 Feb '03

I second Craig - let's release. As I've said before, when thinking about adding any sort of fix at this point we need to weight the real cost of adding it (including risks that the bug fix is imperfect, or reveals another bug, or..) to the real cost of not adding it (remember we can back port a bug fix to a finalized version, after the change has been tested to death in the new development version, if we get complaints about it). In this specific case, IIUC, the analysis is like this - 1. Not that many newbies try to reshape ClassDescription. 2. Archive viewer bug fix gets auto-installed by SARInstaller (which, btw, has it's own problems). Therefore, release without it, patch later iff needed. Daniel Craig Latta <craig(a)netjam.org> wrote: > > 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)] > _______________________________________________ > 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