Re: 3.5 release timing (was Re: Outstanding 3.4 bugs?)

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 <[email protected]> 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
> [email protected]
> http://lists.squeakfoundation.org/listinfo/squeakfoundation
From [email protected] Tue Mar 04 13:34:45 2003
Return-Path: <[email protected]>
Delivered-To: [email protected]
Received: (qmail 8787 invoked from network); 4 Mar 2003 13:34:45 -0000
Received: from smtp.plusnet.ch (HELO obelix.spectraweb.ch) (194.158.230.8)
  by mail.theinternetone.net with SMTP; 4 Mar 2003 13:34:45 -0000
Received: from aSqueakSystem (pop-mu-12-1-dialup-218.freesurf.ch
	[194.230.151.218])id h24DYRm12234;	Tue, 4 Mar 2003 14:34:28 +0100
Message-Id: <[email protected]>
X-Mailer: Celeste 2.0.5168
Date: Tue, 4 Mar 2003 08:39:51 +0100 
To: The general-purpose Squeak developers list
	<[email protected]>
From: Bruce ONeel <[email protected]>
cc: Discussing the Squeak Foundation
	<[email protected]>
cc: [email protected]
Subject: [Squeakfoundation]Re: [UPDATES] 3.4 is now final
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: Tue, 04 Mar 2003 13:34:45 -0000

Excellent!  I'll build the bundles later today and upload
them (thanks to Marcus Denker for the MacOS one)
and then send Ted the updated download page.

When I build the bundles I was going to grab the latest
stable VMs.  If anyone who builds VMs wants something
different email me.   I was also going to build bundles
for MacOS (Carbon), Windows, and the unix systems which
Ian has prebuilt VMs for.  Are there any other bundles that
should be built?

Thanks to all for all the hard work!

cheers

bruce

Doug Way <[email protected]> wrote:
> 
> Hello all, 3.4 is now finalized!
> 
> I just issued an update offering the choice of moving a 3.4gamma image 
> to 3.4, or to 3.5alpha.  (Technically, the choice was already offered 
> in an earlier update when 3.4gamma was created, but since the two 
> update streams contain the same fixes, I offered the choice again.)
> 
> A 3.4 final image/changes/readme .zip file is available on the ftp 
> site, here:
> 
> ftp://st.cs.uiuc.edu/Smalltalk/Squeak/3.4/
> 
> Please give this a quick test if you have a chance, just to make sure 
> there are no major problems with the image.  A major problem roughly 
> meaning: any significant problem which was *not* in 3.4gammaOne.
> 
> This image should be identical to 3.4gammaOne, except for incorporating 
> the last update (5170), and some content changes in the Welcome... 
> window, which were discussed on the SqF list (on Feb. 4 & 8).
> 
> The 3.4 release is still not complete in the sense that the squeak.org 
> downloads page has not been updated to point to the appropriate 3.4 
> bundles.  When that is done, that will be the true "release date" for 
> 3.4.  Allowing a few days to make sure there are no major problems with 
> this image, and also to create the release bundles with VMs, I think we 
> should shoot for updating squeak.org in 3-4 days.
> 
> Anyway, I'd like to thank Scott Wallace for spending time helping me 
> get the update stream going, and with all of the release details.  And, 
> of course, thanks to all of SqC for "releasing" Squeak to the Guides 
> and the community at large!
> 
> - Doug Way
From [email protected] Wed Mar 05 05:47:47 2003
Return-Path: <[email protected]>
Delivered-To: [email protected]
Received: (qmail 11313 invoked from network); 5 Mar 2003 05:47:47 -0000
Received: from mailhost1-sfldmi.sfldmi.ameritech.net (HELO
	mailhost.det2.ameritech.net) (206.141.193.105)
	by mail.theinternetone.net with SMTP; 5 Mar 2003 05:47:47 -0000
Received: from riskmetrics.com ([66.72.186.201])
	by mailhost.det2.ameritech.net
	(InterMail vM.4.01.02.17 201-229-119) with ESMTP
	<20030305054740.SWEY8853.mailhost.det2.ameritech.net@riskmetrics.com>
	for <[email protected]>;
	Wed, 5 Mar 2003 00:47:40 -0500
Date: Wed, 5 Mar 2003 00:47:40 -0500
Subject: Re: [Squeakfoundation]3.5 release timing (was Re: Outstanding 3.4
	bugs?)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v551)
From: Doug Way <[email protected]>
To: Discussing the Squeak Foundation
	<[email protected]>
Content-Transfer-Encoding: 7bit
In-Reply-To: <[email protected]>
Message-Id: <[email protected]>
X-Mailer: Apple Mail (2.551)
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: Wed, 05 Mar 2003 05:47:48 -0000


On Tuesday, March 4, 2003, at 02:52 AM, Daniel Vainsencher wrote:

> ...
> 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.

Yes, those are basically the points I was getting at.

> 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?

Not really.  I'm not sure that the Visibility argument is that 
compelling, though.  I don't mind that much the idea of newbies being 
3-4 months out of sync with what alpha testers are using.  (As long as 
there are enough alpha testers to really test things.)  Although much 
more than 3-4 months might bother me.  I guess it's a matter of degree.

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.

> 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.

That does make some sense.  A "very good" release might be a good start 
before getting down to splitting up the image and other work, as 
opposed to a more average release.  A reference release of sorts.  And 
good PR, I suppose.

It would delay the "getting down to splitting up the image" by at least 
a month, though.  And I'm not sure it's *really* that important.  So 
I'm still on the fence, awaiting a few more opinions.

Post-3.5, people have mentioned quarterly releases as a possible goal, 
while others have mentioned releases every 6 months.  My original 
thought was either every 4 months or 6 months or so.  I kind of like 4 
months, actually... not quite as intense as every 3 months, but still 
reasonably rapid, certainly more rapid than the last several Squeak 
releases.  Whatever the interval, I also like the idea of a somewhat 
regular cycle, in which stuff that doesn't make it in time for the 
release gets put off until the next release, rather than delaying the 
release.

> 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.

Yes.  Now that 3.4 is done, I want to get going on the harvesting tool, 
at least.  Although if we go with a one-month quick cycle for 3.5, the 
tool may not be done early enough to make a big difference.  (There 
would still be value in just getting it done, of course.)  We would 
probably have to do some fix harvesting by hand, at first.

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.

But we do need to decide on the 3.5 release timing very soon...

- Doug Way