re: release prioritization

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
[email protected]
www.netjam.org/resume
Smalltalkers do: [:it | All with: Class, (And love: it)]
From [email protected] Fri Feb 28 11:51:53 2003
Return-Path: <[email protected]>
Delivered-To: [email protected]
Received: (qmail 19567 invoked from network); 28 Feb 2003 11:51:53 -0000
Received: from mxout3.netvision.net.il (194.90.9.24)
  by mail.theinternetone.net with SMTP; 28 Feb 2003 11:51:53 -0000
Received: from [80.178.112.97] ([80.178.112.97]) by mxout3.netvision.net.il
 (iPlanet Messaging Server 5.2 HotFix 1.08 (built Dec  6 2002))
 with SMTPA id <[email protected]>; Fri,
 28 Feb 2003 13:51:52 +0200 (IST)
Date: Fri, 28 Feb 2003 13:52:45 +0300
From: Daniel Vainsencher <[email protected]>
Subject: Re: [Squeakfoundation]re: release prioritization (was
 "ClassBuilder problem")
To: Discussing the Squeak Foundation
 <[email protected]>
Message-id: <[email protected]>
X-Mailer: Celeste 2.0.5108
Content-transfer-encoding: 7BIT
cc: The general-purpose Squeak developers list
	<[email protected]>
X-BeenThere: [email protected]
X-Mailman-Version: 2.1
Precedence: list
Reply-To: Discussing the Squeak Foundation
	<[email protected]>
List-Id: Discussing the Squeak Foundation
 <squeakfoundation.lists.squeakfoundation.org>
List-Unsubscribe: <http://lists.squeakfoundation.org/listinfo/squeakfoundation>,
	<mailto:[email protected]?subject=unsubscribe>
List-Archive: <http://lnx-12.ams-2.theinternetone.net/pipermail/squeakfoundation>
List-Post: <mailto:[email protected]>
List-Help: <mailto:[email protected]?subject=help>
List-Subscribe: <http://lists.squeakfoundation.org/listinfo/squeakfoundation>,
	<mailto:[email protected]?subject=subscribe>
X-List-Received-Date: Fri, 28 Feb 2003 11:51:54 -0000

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 <[email protected]> wrote:
> Roel Wuyts <[email protected]> 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
> [email protected]
> http://lists.squeakfoundation.org/listinfo/squeakfoundation
From [email protected] Fri Feb 28 12:08:48 2003
Return-Path: <[email protected]>
Delivered-To: [email protected]
Received: (qmail 16184 invoked from network); 28 Feb 2003 12:08:48 -0000
Received: from iramx1.ira.uni-karlsruhe.de (141.3.10.80)
  by mail.theinternetone.net with SMTP; 28 Feb 2003 12:08:48 -0000
Received: from i09nbmarcus.atis.uni-karlsruhe.de ([141.3.8.99])
	by iramx1.ira.uni-karlsruhe.de with esmtp (Exim 3.30 #10 (Debian))
	id 18ojJn-0005bV-00; Fri, 28 Feb 2003 13:08:47 +0100
Received: from marcus by i09nbmarcus.atis.uni-karlsruhe.de with local (Exim
	3.33 #2 (Debian))
	id 18ojJL-0005hZ-00; Fri, 28 Feb 2003 13:08:19 +0100
Date: Fri, 28 Feb 2003 13:08:19 +0100
From: Marcus Denker <[email protected]>
To: [email protected]
Message-ID: <[email protected]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
Subject: [Squeakfoundation]Collecting tests?
X-BeenThere: [email protected]
X-Mailman-Version: 2.1
Precedence: list
Reply-To: Discussing the Squeak Foundation
	<[email protected]>
List-Id: Discussing the Squeak Foundation
 <squeakfoundation.lists.squeakfoundation.org>
List-Unsubscribe: <http://lists.squeakfoundation.org/listinfo/squeakfoundation>,
	<mailto:[email protected]?subject=unsubscribe>
List-Archive: <http://lnx-12.ams-2.theinternetone.net/pipermail/squeakfoundation>
List-Post: <mailto:[email protected]>
List-Help: <mailto:[email protected]?subject=help>
List-Subscribe: <http://lists.squeakfoundation.org/listinfo/squeakfoundation>,
	<mailto:[email protected]?subject=subscribe>
X-List-Received-Date: Fri, 28 Feb 2003 12:08:48 -0000

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 [email protected]  -- Squeak! http://squeak.de