Re: Re: Shrinking alpha image (was Re: Proposal to get to the triad)

[email protected]
Newsgroups gmane.comp.lang.smalltalk.squeak.foundation
Message-ID <[email protected]>
Doug Way <[email protected]> wrote:
> 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.

Well, I want a person. Obviously I struck the wrong chord by writing
"Release Boss" but I simply meant someone that moderates the discussion
and makes sure we get the general plan straight.

And the plan is of course just a plan - the use of it is so that we
hopefully work in the same direction. If we don't then so be it. But
hopefully the chance of us working in the same direction is more likely
if we have a common plan. Right?! And as Doug explains below, the plan
shouldn't typically include stuff that we don't "have" of course.

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

Exactly. Personally I think it is vital for us to know if we are
adopting Anthony's stuff in 3.6 or later.
We can't just throw it in on a whim.

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

Again, exactly.

> 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 

Yes. Exactly. (Hmmm, I am repeating myself here)

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

Yes.

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

regards, Göran
From [email protected] Fri Mar 21 07:49:25 2003
Return-Path: <[email protected]>
Delivered-To: [email protected]
Received: (qmail 16707 invoked from network); 21 Mar 2003 07:49:25 -0000
Received: from sark.cc.gatech.edu (130.207.7.23)
  by mail.theinternetone.net with SMTP; 21 Mar 2003 07:49:25 -0000
Received: from gaia.cc.gatech.edu (gaia.cc.gatech.edu [130.207.3.8])
	by sark.cc.gatech.edu (8.12.8/8.12.8) with ESMTP id h2L7nNlF014883
	for <[email protected]>;
	Fri, 21 Mar 2003 02:49:23 -0500 (EST)
Received: (from schwa@localhost)
	by gaia.cc.gatech.edu (8.12.8/8.12.8) id h2L7nMDW008987
	for [email protected];
	Fri, 21 Mar 2003 02:49:22 -0500 (EST)
Date: Fri, 21 Mar 2003 02:49:22 -0500
From: "Joshua 'Schwa' Gargus" <[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]updating to next version after declining alpha
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 07:49:25 -0000

I originally posted this to squeak-dev, but it probably should have
been sent here.


----- Forwarded message from Joshua 'Schwa' Gargus <[email protected]> -----

Date: Wed, 19 Mar 2003 21:59:18 -0500
From: "Joshua 'Schwa' Gargus" <[email protected]>
Reply-To: The general-purpose Squeak developers list
	<[email protected]>
To: Squeak Mailing List <[email protected]>
Subject: updating to next version after declining alpha
User-Agent: Mutt/1.2.5.1i
Delivered-To: [email protected]
List-Id: The general-purpose Squeak developers list
 <squeak-dev.lists.squeakfoundation.org>
List-Unsubscribe: <http://lists.squeakfoundation.org/listinfo/squeak-dev>,
	<mailto:[email protected]?subject=unsubscribe>
List-Archive: <http://lnx-12.ams-2.theinternetone.net/pipermail/squeak-dev>
List-Post: <mailto:[email protected]>
List-Help: <mailto:[email protected]?subject=help>
List-Subscribe: <http://lists.squeakfoundation.org/listinfo/squeak-dev>,
	<mailto:[email protected]?subject=subscribe>
Errors-To: [email protected]

I have a comment about Squeak version releases that may or may not
have been discussed already.  My concern relates to beginning a new
alpha branch before the previous version is finalized.  This happens
every time, and I think that it is unavoidable.  

I currently have a 3.5 beta "living" image where I keep a lot of 
important information.  I don't want to advance it to 3.6 alpha 
because I can't afford to mess it up.  So, I chose to only receive
the final fixes for the 3.5 release.  However, some day 3.6 will
be stable enough to switch to.  My problem involves the uncertainty
about being able to successfully update from a 3.5 final release 
(which may include updates after the choice about whether to go
3.5 or 3.6).  

Can we manage the update streams in such a way that we can be certain
that such updates are possible?  In most cases, it probably works fine
on its own.  However, I think that it is important for users to be 
able to rely on this invariant.

Comments?

Joshua

----- End forwarded message -----
From [email protected] Fri Mar 21 08:19:48 2003
Return-Path: <[email protected]>
Delivered-To: [email protected]
Received: (qmail 2289 invoked from network); 21 Mar 2003 08:19:48 -0000
Received: from ns.bluefish.se (HELO leia.bluefish.se) (213.212.22.234)
  by mail.theinternetone.net with SMTP; 21 Mar 2003 08:19:48 -0000
Received: from [213.80.63.110] (helo=aSqueakSystem)
	by leia.bluefish.se with smtp (Exim 3.12 #1 (Debian))
	id 18wHkh-00050e-00
	for <[email protected]>;
	Fri, 21 Mar 2003 09:19:47 +0100
X-Mailer: Celeste 2.0.4917
Date: Fri, 21 Mar 2003 09:04:41 +0100 
In-reply-to: <[email protected]>
Subject: [Squeakfoundation]3.6 release timing (was Re: Shrinking alpha image)
To: Discussing the Squeak Foundation
	<[email protected]>
References: <[email protected]>
	<[email protected]> <[email protected]>
From: [email protected]
Message-Id: <[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, 21 Mar 2003 08:19:49 -0000

Howdy!

Doug Way <[email protected]> wrote: 
> [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.)

Sounds like a reasonable plan.

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

Exactly. :-)

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

Yes. I don't care who does it, just as long as someone makes an
inventory and selects the stuff that we should aim for.

> 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.
[SNIP of good arguments on cycle that I agree with]

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

Sounds dandy. And just to make it clear - I agree with the idea of
focusing on time before content.

> We can then come up with a list of content that we think can reasonably get
> done in that time.
> 
> Thoughts on this?

Nope, not really - I like it.

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

Right.

regards, Göran
From [email protected] Fri Mar 21 08:19:48 2003
Return-Path: <[email protected]>
Delivered-To: [email protected]
Received: (qmail 2298 invoked from network); 21 Mar 2003 08:19:48 -0000
Received: from ns.bluefish.se (HELO leia.bluefish.se) (213.212.22.234)
  by mail.theinternetone.net with SMTP; 21 Mar 2003 08:19:48 -0000
Received: from [213.80.63.110] (helo=aSqueakSystem)
	by leia.bluefish.se with smtp (Exim 3.12 #1 (Debian))
	id 18wHki-00050e-01
	for <[email protected]>;
	Fri, 21 Mar 2003 09:19:48 +0100
X-Mailer: Celeste 2.0.4917
Date: Fri, 21 Mar 2003 08:59:21 +0100 
In-reply-to: <[email protected]>
Subject: [Squeakfoundation] re: Decision time: Are SCG the steward ofthekernel
	as proposed?
To: Discussing the Squeak Foundation
	<[email protected]>
References: <[email protected]>
	<[email protected]>
From: [email protected]
Message-Id: <[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, 21 Mar 2003 08:19:49 -0000

Craig Latta <[email protected]> wrote:
> 
> 	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".)

Not to start another fruitless discussion (but that is probably exactly
what I am doing), but I thought the idea of having someone as a Steward
for a piece of Squeak was that the Steward had the "final saying" on
that piece. You know, delegated responsibility. Otherwise the point of
having Stewards seems a bit... moot.

That is also why the "trust" part is important. Of course, we could say
NO, but that would probably essentially mean that we lost that Steward.
And hopefully before that the arguments pro and con had time to boil
down to something good. But having us say NO should be a very, very
uncommon thing.

It still feels like the Steward should take the decisions - I mean, why
should people otherwise be interested in being Stewards if it still
means that everything needs to be crosschecked with us? The idea is to
*distribute* the responsibilities but if no power of decisions comes
with those responsibilities then the incentive of becoming a Steward is
lost. IMHO.

Well, perhaps I have missed something here.

regards, Göran
From [email protected] Fri Mar 21 08:24:36 2003
Return-Path: <[email protected]>
Delivered-To: [email protected]
Received: (qmail 10754 invoked from network); 21 Mar 2003 08:24:36 -0000
Received: from iramx1.ira.uni-karlsruhe.de (141.3.10.80)
  by mail.theinternetone.net with SMTP; 21 Mar 2003 08:24:36 -0000
Received: from acb2efc2.ipt.aol.com ([172.178.239.194] helo=wombat.local.)
	by iramx1.ira.uni-karlsruhe.de with asmtp (Exim 3.30 #10 (Debian))
	id 18wHpL-00042m-00; Fri, 21 Mar 2003 09:24:36 +0100
Received: from marcus by wombat.local. with local (Exim 3.33 #2 (Debian))
	id 18wHmo-0001Ux-00; Fri, 21 Mar 2003 09:21:58 +0100
Date: Fri, 21 Mar 2003 09:21:57 +0100
From: Marcus Denker <[email protected]>
To: Discussing the Squeak Foundation
	<[email protected]>
Subject: Re: [Squeakfoundation] Re: Shrinking alpha image (was Re: Proposal to
	get to the triad)
Message-ID: <[email protected]>
References: <[email protected]>
	<[email protected]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <[email protected]>;
	from [email protected] on Fri, Mar 21, 2003 at 01:41:44AM -0500
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 08:24:37 -0000

On Fri, Mar 21, 2003 at 01:41:44AM -0500, Doug Way wrote:
> 
>    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.)
> 
Another Question is what to do about failing Testcases... the baseimage
testing package allready accumulated 16(!) failing tests. 

Will this be of any relevance to the release process?

Somehow I have the impression that a central testing server would help
a lot: If we'd get an email every week (or even day), we would have
much more pressure to actually harvest the existing bugfixes.


       Marcus


-- 
Marcus Denker [email protected]  -- Squeak! http://squeak.de
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.