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

[Tests are already failing, is it relevant to harvesting?]
No. Solutions are harvested, not problems. BUT - tests are supposed to
be relevant earlier in the process - to what people work on, and submit
fixes for, and claim is [su] compliant. But to help with that, the tests
have to be more visible.

[Testing server would add visibility and help us USE our measures]
I agree. I think such a server would be a great opportunity. Note that
one you have the technology of a server that brings up images,
configures them, and runs tests, you can also use it to do many other
things:
- SLint reports on the image, or other metrics
- running graphs of results over updates.

Anyway, something that would be able to just:
- Get a latest image
- Load updates
- load test packages
- run them
- email results to list

Would be great. I think a first iteration could be in the form of an SM
package, that once loaded, performs the rest of the process. It could be
platform specific and use OSProcess to start the other image. The first
release needn't even be completely automatic - it could helps automate
this process for a person that runs it manually every week, and adds
comments on the results.

This would already make the tests much more visible.

Daniel

Marcus Denker <[email protected]> wrote:
> 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
> 
> _______________________________________________
> Squeakfoundation mailing list
> [email protected]
> http://lists.squeakfoundation.org/listinfo/squeakfoundation
From [email protected] Fri Mar 21 18:08:09 2003
Return-Path: <[email protected]>
Delivered-To: [email protected]
Received: (qmail 1571 invoked from network); 21 Mar 2003 18:08:09 -0000
Received: from mxout4.netvision.net.il (194.90.9.27)
  by mail.theinternetone.net with SMTP; 21 Mar 2003 18:08:09 -0000
Received: from [80.178.97.232] ([80.178.97.232]) by mxout4.netvision.net.il
 (iPlanet Messaging Server 5.2 HotFix 1.08 (built Dec  6 2002))
 with SMTPA id <[email protected]> for
 [email protected]; Fri,
 21 Mar 2003 20:10:17 +0200 (IST)
Date: Fri, 21 Mar 2003 20:09:08 +0300
From: Daniel Vainsencher <[email protected]>
Subject: Re: [Squeakfoundation] Re: Shrinking alpha image (was Re: Proposal to
 get to the triad)
To: Discussing the Squeak Foundation
 <[email protected]>
Message-id: <[email protected]>
MIME-version: 1.0
X-Mailer: Celeste 2.0.5108
Content-type: TEXT/PLAIN
Content-transfer-encoding: 8BIT
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 18:08:10 -0000

I'll tell you what I think is worth doing, which is what I intend to do
-
- Play an XP "customer" for anyone that wants to do something that I
think is important. By this I mean trying to find the "business value"
of different features in what they're doing, and helping to clarify
what's important. Where my added value is as someone in the "business"
of making Squeak better, not too technically involved in any specific
solution.
- Occaisonally start discussions about those larger, harder to integrate
pieces of work, like network rewrites, compiler changes and so forth.
Again, representing the position of how do we make Squeak better,
without getting into a mess.
- Raising awareness - both by summerizing what's been discussed, and by
following up on things that happen.

I don't think these roles are very coupled - we can definitely share in
them.

Daniel

[email protected] wrote:
> 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.
> 
> regards, Göran
> _______________________________________________
> Squeakfoundation mailing list
> [email protected]
> http://lists.squeakfoundation.org/listinfo/squeakfoundation
From [email protected] Fri Mar 21 20:33:37 2003
Return-Path: <[email protected]>
Delivered-To: [email protected]
Received: (qmail 1063 invoked from network); 21 Mar 2003 20:33:37 -0000
Received: from mxout2.netvision.net.il (194.90.9.21)
  by mail.theinternetone.net with SMTP; 21 Mar 2003 20:33:37 -0000
Received: from [80.178.97.232] ([80.178.97.232]) by mxout2.netvision.net.il
 (iPlanet Messaging Server 5.2 HotFix 1.08 (built Dec  6 2002))
 with SMTPA id <[email protected]> for
 [email protected]; Fri,
 21 Mar 2003 22:33:35 +0200 (IST)
Date: Fri, 21 Mar 2003 20:27:48 +0300
From: Daniel Vainsencher <[email protected]>
Subject: [Squeakfoundation]3.6 release timing (was Re: Shrinking alpha image)
To: Discussing the Squeak Foundation
 <[email protected]>
Message-id: <[email protected]>
X-Mailer: Celeste 2.0.5108
Content-transfer-encoding: 7BIT
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 20:33:38 -0000

[Cross posting moves threads, cycle >~4 mo]
Sure.

[Sm 1.1 in Squeak 3.6, me or someone as release content prognosticator]
If someone does want the job, they're welcome to it. As for me - Goran,
I haven't had as much time/inclination to help with SM as I thought I
might, but let me know if you need testing/someone to play XP customer,
or any other specific kind of help. I wouldn't say that 1.1 will or even
should be in 3.6, but I'd be damn happy to help it get there! :-)

[3.6 harvesting to start soon]
Sure. I'll be looking at the recent posts of removal scripts and
reviewing them, so we can start putting some shrinking into the image.

Daniel

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.)
> 
> > 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.
> _______________________________________________
> Squeakfoundation mailing list
> [email protected]
> http://lists.squeakfoundation.org/listinfo/squeakfoundation
From [email protected] Fri Mar 21 20:33:38 2003
Return-Path: <[email protected]>
Delivered-To: [email protected]
Received: (qmail 1111 invoked from network); 21 Mar 2003 20:33:38 -0000
Received: from mxout2.netvision.net.il (194.90.9.21)
  by mail.theinternetone.net with SMTP; 21 Mar 2003 20:33:38 -0000
Received: from [80.178.97.232] ([80.178.97.232]) by mxout2.netvision.net.il
 (iPlanet Messaging Server 5.2 HotFix 1.08 (built Dec  6 2002))
 with SMTPA id <[email protected]> for
 [email protected]; Fri,
 21 Mar 2003 22:33:36 +0200 (IST)
Date: Fri, 21 Mar 2003 20:54:27 +0300
From: Daniel Vainsencher <[email protected]>
Subject: [Squeakfoundation] re: Decision time: Are SCG the steward ofthekernel
 as proposed?
To: Discussing the Squeak Foundation
 <[email protected]>
Message-id: <[email protected]>
MIME-version: 1.0
X-Mailer: Celeste 2.0.5108
Content-type: TEXT/PLAIN
Content-transfer-encoding: 8BIT
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 20:33:38 -0000

Distributing the decision making is something I care about as much as
you do. However, we need to be careful of oversimplifying ideas that
will keep us from making progress.

I think this applies in two ways to our process.
1. Distributing decision making doesn't have to be an all or nothing
proposition.
2. An artifact and it's set of policies, to remain viable over time need
to be coherent. This does (IMO) preclude a number of different groups
each pulling in their own direction. The weaker version of this
argument, which I'll be far less hesitant about defending, is that
making a *product release* at a specific date, precludes a number of
groups each with commitment power.

To avoid going all theoretical, I'll note that Linus does distribute a
lot of the decision making in Linux kernel development, but still,
nobody puts anything into his tree without his say so. BTW, the
infrastructures and the communities and the their leaders are very
different, but I think this much does apply to us too.

And in our specific case, you don't see me telling KCP or MCP *what* to
do. They both control that aspect. I do give guidance on what will make
their work easier to accept into the mainstream, and mostly in terms of
process, not content. If they decide to make radical changes, they'll
have to convince people it's worthy, and provide an upgrade path we can
support, but I won't tell them "no" a priori.

Daniel

[email protected] wrote:
> 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
> _______________________________________________
> Squeakfoundation mailing list
> [email protected]
> http://lists.squeakfoundation.org/listinfo/squeakfoundation
From [email protected] Fri Mar 21 20:33:39 2003
Return-Path: <[email protected]>
Delivered-To: [email protected]
Received: (qmail 1119 invoked from network); 21 Mar 2003 20:33:38 -0000
Received: from mxout2.netvision.net.il (194.90.9.21)
  by mail.theinternetone.net with SMTP; 21 Mar 2003 20:33:38 -0000
Received: from [80.178.97.232] ([80.178.97.232]) by mxout2.netvision.net.il
 (iPlanet Messaging Server 5.2 HotFix 1.08 (built Dec  6 2002))
 with SMTPA id <[email protected]> for
 [email protected]; Fri,
 21 Mar 2003 22:33:37 +0200 (IST)
Date: Fri, 21 Mar 2003 21:00:19 +0300
From: Daniel Vainsencher <[email protected]>
Subject: Re: [Squeakfoundation]updating to next version after declining alpha
To: Discussing the Squeak Foundation
 <[email protected]>
Message-id: <[email protected]>
X-Mailer: Celeste 2.0.5108
Content-transfer-encoding: 7BIT
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 20:33:39 -0000

Hmm, do you have any ideas on how we can do this? it seems to me that
two ideas here are in conflict -
1. "I should get backported fixes into 3.5 that worked in 3.6, without
moving into 3.6 while it's alpha"
2. "When 3.6 becomes gamma, I should be able to upgrade 3.5 after all"

You can do either one of those manually now, by simply proceeding up
only one of the upgrade paths, but I don't have ideas on how you can
have both. 

On another note, some people might ask "why do you keep important stuff
in your image anyway?"

Daniel

Joshua 'Schwa' Gargus <[email protected]> wrote:
> 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 -----
> _______________________________________________
> Squeakfoundation mailing list
> [email protected]
> http://lists.squeakfoundation.org/listinfo/squeakfoundation
From [email protected] Fri Mar 21 22:39:28 2003
Return-Path: <[email protected]>
Delivered-To: [email protected]
Received: (qmail 24250 invoked from network); 21 Mar 2003 22:39:28 -0000
Received: from sark.cc.gatech.edu (130.207.7.23)
  by mail.theinternetone.net with SMTP; 21 Mar 2003 22:39:28 -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 h2LMdQlF007712
	for <[email protected]>;
	Fri, 21 Mar 2003 17:39:26 -0500 (EST)
Received: (from schwa@localhost)
	by gaia.cc.gatech.edu (8.12.8/8.12.8) id h2LMdPQr011192
	for [email protected];
	Fri, 21 Mar 2003 17:39:25 -0500 (EST)
Date: Fri, 21 Mar 2003 17:39:25 -0500
From: "Joshua 'Schwa' Gargus" <[email protected]>
To: Discussing the Squeak Foundation
	<[email protected]>
Subject: Re: [Squeakfoundation]updating to next version after declining alpha
Message-ID: <[email protected]>
References: <[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 09:00:19PM +0300
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 22:39:28 -0000

On Fri, Mar 21, 2003 at 09:00:19PM +0300, Daniel Vainsencher wrote:
> Hmm, do you have any ideas on how we can do this? it seems to me that
> two ideas here are in conflict -
> 1. "I should get backported fixes into 3.5 that worked in 3.6, without
> moving into 3.6 while it's alpha"
> 2. "When 3.6 becomes gamma, I should be able to upgrade 3.5 after all"

Right.  I don't see that there necessarily a conflict, at least 
conceptually; for instance, Debian lets you do these kind of things.
However, you are probably right that there is a conflict once we 
examine things from the point of view of Squeak update streams and
changesets.

> 
> You can do either one of those manually now, by simply proceeding up
> only one of the upgrade paths, but I don't have ideas on how you can
> have both. 

Hmm, I need to introduce some terminology.  Call "base 3.5/6" the state
of the image right after the version is advanced, but before any further
updates are loaded.  Call "current 3.5/6" the state of the image with
all of the updates currently available in the appropriate update stream 
loaded.

Most of the time, when backported fixes get added to current 3.5, you'll
be lucky and things won't break if you update with all of the changes
up to current 3.6.  However, sometimes they will, but you should be 
able to notice this by testing.

Backported fixes could be tested by filing in the fix to a current 3.5
and then updating it to current 3.6.  If it breaks, then we could figure
out why, and either fix it so that it would be smooth sailing to 3.6, or
decided that it's not worth the effort.  New 3.6 changesets could be 
tested to ensure that they work with a current 3.6, and a 3.5 updated
to current 3.6.

This would admittedly be more work for those in charge of the update
streams, probably too much  I thought about only allowing updates from 
a final 3.5, so the 3.6 update stream only had to be tested against a 
final 3.5 and a base 3.6, but this wouldn't work if some earlier 3.5 
changeset caused problems that precluded later updating, since that 
changeset couldn't retroactively be removed from the update stream.  I 
guess the best option would be to just not load any final updates to 
3.5.

Still, I don't like the idea of 3.5 final possibly being a short 
dead-end branch, especially when it is not made clear to users that
this is the case (a newbie would have no way of knowing that loading
updates to 3.5 after the branch to 3.6 might make it impossible to 
later update to 3.6).  At the least, the rollover message could
warn that to accept further 3.5 updates voids the guarantee that
a later update to 3.5 will work fine.

> On another note, some people might ask "why do you keep important stuff
> in your image anyway?"

Because the important stuff consists of morphs.  Where else would I keep them,
and still have them handy to modify?  I haven't had perfect luck in the past
with exporting and re-importing morphs between different versions of Squeak,
and it would be a lot of extra hassle keeping track of all the exported files.

Joshua

> 
> Daniel
> 
> Joshua 'Schwa' Gargus <[email protected]> wrote:
> > 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 -----
> > _______________________________________________
> > Squeakfoundation mailing list
> > [email protected]
> > http://lists.squeakfoundation.org/listinfo/squeakfoundation
> _______________________________________________
> Squeakfoundation mailing list
> [email protected]
> http://lists.squeakfoundation.org/listinfo/squeakfoundation
From [email protected] Sat Mar 22 00:23:28 2003
Return-Path: <[email protected]>
Delivered-To: [email protected]
Received: (qmail 9966 invoked from network); 22 Mar 2003 00:23:28 -0000
Received: from mxout3.netvision.net.il (194.90.9.24)
  by mail.theinternetone.net with SMTP; 22 Mar 2003 00:23:28 -0000
Received: from [80.178.97.232] ([80.178.97.232]) by mxout3.netvision.net.il
 (iPlanet Messaging Server 5.2 HotFix 1.08 (built Dec  6 2002))
 with SMTPA id <[email protected]> for
 [email protected]; Sat,
 22 Mar 2003 02:23:25 +0200 (IST)
Date: Sat, 22 Mar 2003 01:30:46 +0300
From: Daniel Vainsencher <[email protected]>
Subject: [Squeakfoundation]re: Shrinking alpha image
To: Discussing the Squeak Foundation
 <[email protected]>
Message-id: <[email protected]>
X-Mailer: Celeste 2.0.5108
Content-transfer-encoding: 7BIT
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: Sat, 22 Mar 2003 00:23:28 -0000

As a good friend of mine once said, a contradiction implies anything you
want. If you have an operational model of how we get to where you
propose we should be, go ahead.

A few questions it should answer -
* How do we know what the community will come up with beforehand?
* How do we get everyone to actually test and document everything?
* How do we avoid being such pests that nobody actually wants to submit
anything?

I think the first is a mirage, and the second and third are reasonably
addressed by QA tags -if we stick to them and accept nothing that
doesn't have them-.

Daniel

Craig Latta <[email protected]> wrote:
> 
> 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]
> _______________________________________________
> Squeakfoundation mailing list
> [email protected]
> http://lists.squeakfoundation.org/listinfo/squeakfoundation
From [email protected] Sat Mar 22 00:23:29 2003
Return-Path: <[email protected]>
Delivered-To: [email protected]
Received: (qmail 10021 invoked from network); 22 Mar 2003 00:23:29 -0000
Received: from mxout3.netvision.net.il (194.90.9.24)
  by mail.theinternetone.net with SMTP; 22 Mar 2003 00:23:29 -0000
Received: from [80.178.97.232] ([80.178.97.232]) by mxout3.netvision.net.il
 (iPlanet Messaging Server 5.2 HotFix 1.08 (built Dec  6 2002))
 with SMTPA id <[email protected]> for
 [email protected]; Sat,
 22 Mar 2003 02:23:28 +0200 (IST)
Date: Sat, 22 Mar 2003 02:07:03 +0300
From: Daniel Vainsencher <[email protected]>
Subject: Re: [Squeakfoundation]updating to next version after declining alpha
To: Discussing the Squeak Foundation
 <[email protected]>
Message-id: <[email protected]>
X-Mailer: Celeste 2.0.5108
Content-transfer-encoding: 7BIT
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: Sat, 22 Mar 2003 00:23:30 -0000

Have you tried exporting importing when moving from a 3.5 final to a
initial 3.6alpha? it's very improbable that the final changes would
include changes that make your morphs incompatible, compared to
exporting importing across wider version gulfs.

Otherwise, I do sympathize with your claim in principle, but as long as
we don't put absolute limits on what final changes might include (no
do-its, no shape changes, just method definitions, nothing that didn't
get into version n.m+1), I don't see how the problem can be avoided.
Proposals welcome.

Daniel

Joshua 'Schwa' Gargus <[email protected]> wrote:
> On Fri, Mar 21, 2003 at 09:00:19PM +0300, Daniel Vainsencher wrote:
> > Hmm, do you have any ideas on how we can do this? it seems to me that
> > two ideas here are in conflict -
> > 1. "I should get backported fixes into 3.5 that worked in 3.6, without
> > moving into 3.6 while it's alpha"
> > 2. "When 3.6 becomes gamma, I should be able to upgrade 3.5 after all"
> 
> Right.  I don't see that there necessarily a conflict, at least 
> conceptually; for instance, Debian lets you do these kind of things.
> However, you are probably right that there is a conflict once we 
> examine things from the point of view of Squeak update streams and
> changesets.
> 
> > 
> > You can do either one of those manually now, by simply proceeding up
> > only one of the upgrade paths, but I don't have ideas on how you can
> > have both. 
> 
> Hmm, I need to introduce some terminology.  Call "base 3.5/6" the state
> of the image right after the version is advanced, but before any further
> updates are loaded.  Call "current 3.5/6" the state of the image with
> all of the updates currently available in the appropriate update stream 
> loaded.
> 
> Most of the time, when backported fixes get added to current 3.5, you'll
> be lucky and things won't break if you update with all of the changes
> up to current 3.6.  However, sometimes they will, but you should be 
> able to notice this by testing.
> 
> Backported fixes could be tested by filing in the fix to a current 3.5
> and then updating it to current 3.6.  If it breaks, then we could figure
> out why, and either fix it so that it would be smooth sailing to 3.6, or
> decided that it's not worth the effort.  New 3.6 changesets could be 
> tested to ensure that they work with a current 3.6, and a 3.5 updated
> to current 3.6.
> 
> This would admittedly be more work for those in charge of the update
> streams, probably too much  I thought about only allowing updates from 
> a final 3.5, so the 3.6 update stream only had to be tested against a 
> final 3.5 and a base 3.6, but this wouldn't work if some earlier 3.5 
> changeset caused problems that precluded later updating, since that 
> changeset couldn't retroactively be removed from the update stream.  I 
> guess the best option would be to just not load any final updates to 
> 3.5.
> 
> Still, I don't like the idea of 3.5 final possibly being a short 
> dead-end branch, especially when it is not made clear to users that
> this is the case (a newbie would have no way of knowing that loading
> updates to 3.5 after the branch to 3.6 might make it impossible to 
> later update to 3.6).  At the least, the rollover message could
> warn that to accept further 3.5 updates voids the guarantee that
> a later update to 3.5 will work fine.
> 
> > On another note, some people might ask "why do you keep important stuff
> > in your image anyway?"
> 
> Because the important stuff consists of morphs.  Where else would I keep them,
> and still have them handy to modify?  I haven't had perfect luck in the past
> with exporting and re-importing morphs between different versions of Squeak,
> and it would be a lot of extra hassle keeping track of all the exported files.
> 
> Joshua
> 
> > 
> > Daniel
> > 
> > Joshua 'Schwa' Gargus <[email protected]> wrote:
> > > 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 -----
> > > _______________________________________________
> > > Squeakfoundation mailing list
> > > [email protected]
> > > http://lists.squeakfoundation.org/listinfo/squeakfoundation
> > _______________________________________________
> > Squeakfoundation mailing list
> > [email protected]
> > http://lists.squeakfoundation.org/listinfo/squeakfoundation
> _______________________________________________
> Squeakfoundation mailing list
> [email protected]
> http://lists.squeakfoundation.org/listinfo/squeakfoundation
From [email protected] Sat Mar 22 00:54:56 2003
Return-Path: <[email protected]>
Delivered-To: [email protected]
Received: (qmail 22595 invoked from network); 22 Mar 2003 00:54:56 -0000
Received: from sark.cc.gatech.edu (130.207.7.23)
  by mail.theinternetone.net with SMTP; 22 Mar 2003 00:54:56 -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 h2M0stlF017892
	for <[email protected]>;
	Fri, 21 Mar 2003 19:54:55 -0500 (EST)
Received: (from schwa@localhost)
	by gaia.cc.gatech.edu (8.12.8/8.12.8) id h2M0ss6r019088
	for [email protected];
	Fri, 21 Mar 2003 19:54:54 -0500 (EST)
Date: Fri, 21 Mar 2003 19:54:54 -0500
From: "Joshua 'Schwa' Gargus" <[email protected]>
To: Discussing the Squeak Foundation
	<[email protected]>
Subject: Re: [Squeakfoundation]updating to next version after declining alpha
Message-ID: <[email protected]>
References: <[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 Sat, Mar 22, 2003 at 02:07:03AM +0300
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: Sat, 22 Mar 2003 00:54:57 -0000

On Sat, Mar 22, 2003 at 02:07:03AM +0300, Daniel Vainsencher wrote:
> Have you tried exporting importing when moving from a 3.5 final to a
> initial 3.6alpha? 

No, I have dozens of projects.

> it's very improbable that the final changes would
> include changes that make your morphs incompatible, compared to
> exporting importing across wider version gulfs.

Very true.  However, this doesn't help; because I am continually
working with the content, all this buys me is a checkpoint that will
rapidly become out of date.

> Otherwise, I do sympathize with your claim in principle, but as long as
> we don't put absolute limits on what final changes might include (no
> do-its, no shape changes, just method definitions, nothing that didn't
> get into version n.m+1), I don't see how the problem can be avoided.

Neither can I.  I'll just stick with an un-updated 3.5 for now for that
image.

Joshua

> Proposals welcome.
> 
> Daniel
From [email protected] Sat Mar 22 01:50:55 2003
Return-Path: <[email protected]>
Delivered-To: [email protected]
Received: (qmail 1592 invoked from network); 22 Mar 2003 01:50:55 -0000
Received: from mailhost1-sfldmi.sfldmi.ameritech.net (HELO
	mailhost.det2.ameritech.net) (206.141.193.105)
	by mail.theinternetone.net with SMTP; 22 Mar 2003 01:50:55 -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
	<20030322015053.WHWK8853.mailhost.det2.ameritech.net@riskmetrics.com>
	for <[email protected]>;
	Fri, 21 Mar 2003 20:50:53 -0500
Date: Fri, 21 Mar 2003 20:50:53 -0500
Subject: Re: [Squeakfoundation]updating to next version after declining alpha
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: Sat, 22 Mar 2003 01:50:56 -0000


On Friday, March 21, 2003, at 05:39 PM, Joshua 'Schwa' Gargus wrote:

> Still, I don't like the idea of 3.5 final possibly being a short
> dead-end branch, especially when it is not made clear to users that
> this is the case (a newbie would have no way of knowing that loading
> updates to 3.5 after the branch to 3.6 might make it impossible to
> later update to 3.6).  At the least, the rollover message could
> warn that to accept further 3.5 updates voids the guarantee that
> a later update to 3.5 will work fine.

I could improve the rollover message next time to include that.  (I 
assume you meant "a later update to 3.6 will work fine" above.)

Actually, the current message sort of implies that anyway, it says that 
you will only be allowed to receive final fixes for the 3.5 release, if 
you choose not to advance to the next alpha.  Here's the 3.5beta split 
message:

"Do you wish to advance to version 3.6alpha?
[Yes] Your system will be marked as 3.6alpha, and you will
subsequently receive ''test pilot'' updates for 3.6.
[No] Your system will be marked as 3.5beta, allowing you
to receive only final fixes for the 3.5 release."

I could add it to something like "Your system will be marked as 
3.5beta, allowing you to receive only final fixes for the 3.5 release.  
You won't have a further opportunity to update to 3.6alpha."

Or, technically it should be "You may not have a further 
opportunity..." because in some cases, if no changes go into the beta 
for whatever reason, we can add another opportunity to advance when 
going to gamma.  This happened with 3.4beta->3.4gamma/3.5alpha.

Anyway, I'm not going to spend a lot of time thinking about whether 
there's a better solution to this, because I can't imagine one right 
now that's not a lot of effort. :-)  Perhaps sometime in the future if 
we have a generic uninstall capability.

- Doug Way