re: Shrinking alpha image

Hi Daniel--

> Let me explain how little is too much - when we posted 3.5a, and
> released it with two fixes that people asked for, that was probably too
> much. Yes, I know I was one of the people for it, but consider this
> consequence - 3.5 is in beta, soon in gamma. Have we heard one voice on
> any squeak list saying "gee guys this actually works"? not that I
> noticed.
> 
> It's already in. The advocates for it have "won". If there's a screw up
> (for example, it clashses with another recent change), we'll find it
> when we're into 3.6. If we don't actually test releases, there's no
> point in having release cycles at all...

	Whoever does the testing...

-	You can't call it alpha until you know what changes you plan to have.
-	You can't call it beta until all those changes are represented.
-	You can't call it gamma until all those changes have been tested.

	I think adhering to that would help a lot. Of course, to be verifiable,
it would require rather more documentation than we do now. I think it'd
be worthwhile, though (and not terribly onerous if each change's
implementor took responsibility for testing and documenting that they'd
done so).


-C

--
Craig Latta
http://netjam.org/resume
[email protected]
From [email protected] Thu Mar 20 23:36:50 2003
Return-Path: <[email protected]>
Delivered-To: [email protected]
Received: (qmail 12698 invoked from network); 20 Mar 2003 23:36:50 -0000
Received: from unknown (HELO plato.hosting-dns.net) (64.247.50.2)
  by mail.theinternetone.net with SMTP; 20 Mar 2003 23:36:50 -0000
Received: from 12-234-228-203.client.attbi.com ([12.234.228.203]
	helo=netjam.org)
	by plato.hosting-dns.net with asmtp (SSLv3:RC4-MD5:128)
	(Exim 3.36 #1)	id 18w9aW-0004Uz-00
	for [email protected];
	Thu, 20 Mar 2003 18:36:44 -0500
Message-ID: <[email protected]>
Date: Thu, 20 Mar 2003 15:36:35 -0800
From: Craig Latta <[email protected]>
Organization: the NetJam project
X-Mailer: Mozilla 4.78 [en]C-CCK-MCD {Sony}  (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Discussing the Squeak Foundation 
 <[email protected]>
References: <[email protected]>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-AntiAbuse: This header was added to track abuse, please include it with any
	abuse report
X-AntiAbuse: Primary Hostname - plato.hosting-dns.net
X-AntiAbuse: Original Domain - lists.squeakfoundation.org
X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [0 0]
X-AntiAbuse: Sender Address Domain - netjam.org
Subject: [Squeakfoundation]
 re: Decision time: Are SCG the steward ofthekernel as proposed?
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: Thu, 20 Mar 2003 23:36:50 -0000


	Daniel writes:

> To add another reason againt a vote on this (not that I care very
> strongly): I didn't see a need for it because I think we can send the
> right message without providing an official moment of decision -
> after all, people do take their risks whatever we might decide, even
> officially.
> 
> If SCG fubars it, we won't merge their stuff. If they bring us good
> patches (the much more likely outcome), we'll merge them whether they
> have any "officially decided" status or not. Just remember this -
> once we've made decisions on a topic, we'll always be making
> decisions on that topic (paraphrasing Frank Herbert, in one of the
> Dune books). IMHO, giving advice is worth doing permanently, giving
> official badges isn't.

	I agree with this, and it's why I abstained. (By the way, Göran, when
one abstains, it's called an "abstention".)


-C

--
Craig Latta
http://netjam.org/resume
[email protected]
From [email protected] Fri Mar 21 00:10:10 2003
Return-Path: <[email protected]>
Delivered-To: [email protected]
Received: (qmail 20342 invoked from network); 21 Mar 2003 00:10:10 -0000
Received: from unknown (HELO lucy.riskmetrics.com) (12.3.62.14)
  by mail.theinternetone.net with SMTP; 21 Mar 2003 00:10:10 -0000
Received: from riskmetrics.com (w018.z064003232.det-mi.dsl.cnc.net
	[64.3.232.18]) by lucy.riskmetrics.com with SMTP (Microsoft Exchange Internet
	Mail Service Version 5.5.2650.21)
	id GZW8S8CW; Thu, 20 Mar 2003 19:03:07 -0500
Message-ID: <[email protected]>
Date: Thu, 20 Mar 2003 19:09:43 -0500
From: Doug Way <[email protected]>
X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: [email protected]
References: <[email protected]>
	<[email protected]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: [Squeakfoundation]3.6 release timing (was Re: Shrinking alpha image)
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, 21 Mar 2003 00:10:11 -0000


[email protected] wrote:
> 
> (crossposting, well - it seemed good)

(Yeah, occasional crossposting is probably unavoidable.  Perhaps we should
only crosspost when we want to shift discussion from squeak-dev over to the
SqF list (and maybe vice versa).  Then all follow-ups should only be posted to
the newly added list, as I'm doing here.  For example, squeak-dev can still be
a place where planning-related discussions will often happen (since it's a
free-for-all), but in more of a brainstorming phase, and to get as much input
as possible from the community.  But then when final decisions need to be
made, the discussions should happen here on the SqF list.)

> As I see it the plan Doug has laid out seems fine. I mean, we aren't
> really maintaining two images - we are maintaining the smaller one and
> making sure that the "full script" works.
> 
> BUT... may I suggest that we set up a goal for 3.6 that SM1.1 is reached
> before release? Otherwise this "full script" will have problems, since
> it can't refer to specific versions of packages.

Sounds like a good idea.  I was guessing that SM1.1 would be out relatively
soon (within 1-2 months?)  Making it a requirement for 3.6 could give you an
extra incentive. ;-)

> And btw, who of us guides should be in charge of making sure that we pin
> down the list of planned things for 3.6? I have seen numerous posts on
> this subject but someone needs to collect these into a "big list" that
> we can condense somewhere and come up with "The Grand 3.6 Plan". In
> short - who should be the "Release Boss" for 3.6? :-)
> 
> And the gist of that plan should of course be summarized on this page:
> http://swiki.squeakfoundation.org/squeakfoundation/79
> 
> Daniel? Tim? Ned? Craig?
> 
> Personally I would like to keep my focus at you-know-what and Doug has
> already taken on enough IMHO.

Right.  Although I am sort of the "Release Master" or "Implementor", meaning
the guy in charge of moving the release from alpha->beta->gamma->final, and
making sure it happens reasonably on schedule.  But yeah, someone else should
probably be in charge of pinning down the release "content".

> I think Daniel would make a greate Release Boss... :-)

I might nominate Daniel also, partly because he's posted on the topic in the
past, and his current role as guide of "image detanglement" is somewhat
nebulous and is partly covered by Ned's and Craig's roles anyway.  But if he
doesn't want to do it and someone else does, that would be fine, too.

On a related note:  As the release implementor (or scheduler or whatever the
best term is), I'd like us to come to a decision on when we want to release
3.6.

The last few Squeak releases have typically had 6-12 months in between each
release.  I'm pretty sure that most of us agree 12 months is too long.  There
were some suggestions on squeak-dev of having six months between releases, or
having them every three months (quarterly), along with some nonsense about
having them once per month. ;-)  My initial thoughts were to have them every 4
or 6 months.

Another alternative is to not have a regular schedule, but to just come up
with a list of features we'd like to see in the next release, and then put out
the release whenever it gets done.  But I liked Daniel's argument about having
the release timing be a higher priority than the content.  That way, people
can depend on new features coming out on a regular basis, and we won't have
releases that drag on for a year.  If some features on the to-do list aren't
finished by the time we're scheduled to move to beta, they get put off until
the next release.  (Of course, we'd try to make sure the most important
features got worked on right at the beginning of the alpha cycle, so at least
they would be finished.  In a dire situation, we could postpone a release, but
the general rule would be that the timing is more important than the content.)

Assuming we go with a regular schedule, I would propose having them every 4
months.  This was about how often the releases happened up until 2.8, I
think.  Having them every 6 months would work too, but I like the idea of
moving things along a little bit faster.  Having them every 3 months feels too
fast to me, though... my release duties would happen at a more hurried pace
and might start to impinge on the "fun" aspect of being a guide.  Also, that
might not allow enough time for a reasonable beta cycle along with a longish
alpha cycle.  I'm guessing our beta cycle should be something like 5-6 weeks?

And having releases every 4 months would make the tri-annual releases, which
brings up the "triad" again. :-)  Anyway, I could be convinced to go slower
than this, but I don't think I'd want to go any faster. 

If we stick with the "First Fridays" release date, that would put the release
date of 3.6 on August 1st.

We can then come up with a list of content that we think can reasonably get
done in that time.

Thoughts on this?

- Doug Way


p.s. Even before we decide on the content for 3.6, I think we could get
started on harvesting fixes for 3.6 right away.  I'll send out another note
shortly about this... getting the harvesting rules nailed down so I know what
to do.
From [email protected] Fri Mar 21 06:41:47 2003
Return-Path: <[email protected]>
Delivered-To: [email protected]
Received: (qmail 19793 invoked from network); 21 Mar 2003 06:41:46 -0000
Received: from mailhost2-sfldmi.sfldmi.ameritech.net (HELO
	mailhost.det3.ameritech.net) (206.141.193.106)
	by mail.theinternetone.net with SMTP; 21 Mar 2003 06:41:46 -0000
Received: from riskmetrics.com ([66.72.186.201])
	by mailhost.det3.ameritech.net
	(InterMail vM.4.01.02.17 201-229-119) with ESMTP
	<20030321064144.QLUH176.mailhost.det3.ameritech.net@riskmetrics.com>
	for <[email protected]>;
	Fri, 21 Mar 2003 01:41:44 -0500
Date: Fri, 21 Mar 2003 01:41:44 -0500
Subject: Re: [Squeakfoundation] Re: Shrinking alpha image (was Re: Proposal to
	get to the triad)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v548)
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.548)
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, 21 Mar 2003 06:41:47 -0000


Well, I think the general idea is that, for each release, we want to 
come up with a "release plan" containing a small handful of items which 
we predict will be included in that release.  Maybe we don't exactly 
need a "release boss" for this.  Maybe a discussion moderator.  Or not.

The kinds of release plan items I'm thinking of are high-level things 
like "Removing the Apple fonts from the release" or "Incorporating 
Anthony's blockclosure work" or "Splitting off 5 to 10 packages from 
the image".

We certainly don't want to be in the business of mandating or 
predicting ahead of time all of the bugfixes and small enhancements 
which should go in the next release.  Incorporating these will involve 
using fixed standards for harvesting, and we usually won't be able to 
predict which fixes will be coming in a future release, so we shouldn't 
bother including that type of information in a release plan.  Even 
medium-sized enhancements may not need to be in a plan.  (Depends on 
what "medium-sized" means, I guess.)

But those high-level items I mentioned above are things which are 
significant enough that we do need to plan around them to some extent, 
and they seem appropriate to include in a "release plan".  They'll 
typically be things that other people in the community have already 
worked on (or are currently working on), where a decision needs to be 
made whether it should be part of the release.  We can still apply our 
fixed standards to incorporating these high-level items, but that's not 
sufficient in and of itself... there should still be some planning 
involved.

I guess there are also things that we think someone should tackle, such 
as cleaning up/replacing the FileDirectory stuff.  I see your point 
that we should probably not proclaim that this problem will be tackled 
in the next release, if no work has already been started on it by 
anyone... rather, we would somehow encourage people in the community to 
work on it first and then see where things stand.

(You also made some points about the lack of testing of the 3.5 items.  
Mostly that's a matter of enforcing our fixed harvesting standards 
(that we're just now coming up with), and having a reasonably long beta 
cycle (which 3.5 didn't really have, but we should have in the future). 
   Actually, there were some SUnit tests submitted for the ClassBuilder 
fix that I verified, but I admit there were none for the project saving 
bugfix, and to be honest I have no idea if that bug has really been 
fixed or not.)

- Doug


On Thursday, March 20, 2003, at 04:47 PM, Daniel Vainsencher wrote:

> I've said before that I think a "release boss" is either something we
> can't have, or a misnomer. Raising awareness of projects that people 
> are
> starting already is just fine, but IMO, we can't, and shouldn't, do 
> much
> more.
>
> Let me explain how little is too much - when we posted 3.5a, and
> released it with two fixes that people asked for, that was probably too
> much. Yes, I know I was one of the people for it, but consider this
> consequence - 3.5 is in beta, soon in gamma. Have we heard one voice on
> any squeak list saying "gee guys this actually works"? not that I
> noticed.
>
> It's already in. The advocates for it have "won". If there's a screw up
> (for example, it clashses with another recent change), we'll find it
> when we're into 3.6. If we don't actually test releases, there's no
> point in having release cycles at all - it just generates fruitless
> discussion. We could for that matter just stop every 300 updates or 3
> months and call it a release, and the name would be worthless.
>
> I think the solution is a strict "if you want it, you test it" policy.
> Bug fixes don't go into the image unless they're externally tested and
> so forth.
>
> Heck, adding code that's very broken is much healthier (in alpha phase)
> - at least it's likely to bug enough people that they'll make sure it
> gets fixed (at least while avoiding the "it's so central/complex nobody
> can fix it" syndrome of 3.3 modules).
>
> Generally, I think we can have either a real policy (fixed standards),
> or a real leadership (human voice telling people what direction to go),
> not both. Since more people in the community already want to pull a
> specific direction, than want to apply specific standards, I think our
> policies and actions as Guides should complement by focusing on setting
> standards.
>
> If we need to help specific directions materialize, it is more by 
> giving
> direct, quick feedback and help to people that want to do them, than by
> proclaiming it should be done.
>
> That might just be a bias on my part talking, but it'll definitely 
> color
> what I'm going to focus on.
>
> Daniel