A few comments

[Göran Krampe]

Hi!

A few comments:

1. I said earlier (IIRC) that the Simple Thing is to always use the
latest published image from the release team as the baseline, in other
words - don't try to update it further (except for possibly loading any
latest MCs we have ourselves in our Network repo (or do we have an IO
repo now? :) ) that has been *merged together* - but AFAIK we don't have
any such bundle yet). What this means is that we all push separate fixes
based on the latest *image* into our Team repo and then a single
individual (Cees?) merges those together into a single bundle and that
is typically also what we then push up to the release team inbox with a
corresponding email. Any such bundle also typically includes other MCs
outside of our domain with fixes - and the MC version note *clearly*
explains what those are. So a "bundle" is actually a group of MCs where
the version note of "our" MC naming the others (or else the release team
will not understand what is included in the bundle).

2. If you are talking about bringing in an external Http package - then
please make sure that the authors/maintainers of that package are
interested in that too. That is pretty important.

3. The very first thing we should do *before* moving forward with
*anything* is actually to merge together what we already have in the
network repo, possibly clean it up, look it over and push that to the
release team. I intended to do that the other night but got lost in
other things. Please, please - do this someone and beat me to it. ;)

regards, Göran
_______________________________________________
Io mailing list
Io@...
http://lists.squeakfoundation.org/mailman/listinfo/io

[Ken Causey]

Regarding 1: Have you been following the 'Picking up where we left it'
thread?  As far as I understand Cees' recommendation and your
recommendation here, you don't seem to be in agreement.  Care to hash
this out?

Ken

On Thu, 2006-03-16 at 10:20 +0200, goran@... wrote:

> Hi!
>
> A few comments:
>
> 1. I said earlier (IIRC) that the Simple Thing is to always use the
> latest published image from the release team as the baseline, in other
> words - don't try to update it further (except for possibly loading any
> latest MCs we have ourselves in our Network repo (or do we have an IO
> repo now? :) ) that has been *merged together* - but AFAIK we don't have
> any such bundle yet). What this means is that we all push separate fixes
> based on the latest *image* into our Team repo and then a single
> individual (Cees?) merges those together into a single bundle and that
> is typically also what we then push up to the release team inbox with a
> corresponding email. Any such bundle also typically includes other MCs
> outside of our domain with fixes - and the MC version note *clearly*
> explains what those are. So a "bundle" is actually a group of MCs where
> the version note of "our" MC naming the others (or else the release team
> will not understand what is included in the bundle).
>
> 2. If you are talking about bringing in an external Http package - then
> please make sure that the authors/maintainers of that package are
> interested in that too. That is pretty important.
>
> 3. The very first thing we should do *before* moving forward with
> *anything* is actually to merge together what we already have in the
> network repo, possibly clean it up, look it over and push that to the
> release team. I intended to do that the other night but got lost in
> other things. Please, please - do this someone and beat me to it. ;)
>
> regards, Gran
> _______________________________________________
> Io mailing list
> Io@...
> http://lists.squeakfoundation.org/mailman/listinfo/io
>

_______________________________________________
Io mailing list
Io@...
http://lists.squeakfoundation.org/mailman/listinfo/io

[Ken Causey]

On Thu, 2006-03-16 at 10:20 +0200, goran@... wrote:
> 3. The very first thing we should do *before* moving forward with
> *anything* is actually to merge together what we already have in the
> network repo, possibly clean it up, look it over and push that to the
> release team. I intended to do that the other night but got lost in
> other things. Please, please - do this someone and beat me to it. ;)
>
> regards, Gran

I started on this but quickly got mired in a plethora of changes.  I
started with a newly download 3.9a-7010.  I decided it made sense to
look at the versions in the Network project on
source.squeakfoundation.org from old to new, so I started with
System-gk.45.mcz.

Before loading it I decide to examine the changes to see if it makes
sense to simply load it.  It quickly becomes obvious that it doesn't as
compared to 7010 it involves _872_ changes.  I've looked and looked but
I'm at a loss as to how I'm supposed to pick out the desired changes
from those that are simply a result of 5 months of changes in the image.

Ken


_______________________________________________
Io mailing list
Io@...
http://lists.squeakfoundation.org/mailman/listinfo/io

[Cees De Groot]

On 3/16/06, Ken Causey <ken@...> wrote:
> System-gk.45.mcz.

I don't know what that's doing there. The Team's work should only
concern the Network and Files packages...
_______________________________________________
Io mailing list
Io@...
http://lists.squeakfoundation.org/mailman/listinfo/io

[Ken Causey]

On Thu, 2006-03-16 at 22:34 +0100, Cees De Groot wrote:
> On 3/16/06, Ken Causey <ken@...> wrote:
> > System-gk.45.mcz.
>
> I don't know what that's doing there. The Team's work should only
> concern the Network and Files packages...

Because classes interact.  The procedure is that if a method in another
category is affected by a change to a class within a categery for which
you are responsible, then go ahead and make the change (since you should
know best how to make it) then forward the changes to the appropriate
team for there verification.  There is no System Stewards team right
now.  So what we do is send it on to the Release team to verify and
incorporate.  In either case, we are going to inevitably be handling
changes to classes outside of our categories, we simply shouldn't be
pushing them through all the way ourselves.

Ken


_______________________________________________
Io mailing list
Io@...
http://lists.squeakfoundation.org/mailman/listinfo/io

[Ken Causey]

On Thu, 2006-03-16 at 15:26 -0600, Ken Causey wrote:

> On Thu, 2006-03-16 at 10:20 +0200, goran@... wrote:
> > 3. The very first thing we should do *before* moving forward with
> > *anything* is actually to merge together what we already have in the
> > network repo, possibly clean it up, look it over and push that to the
> > release team. I intended to do that the other night but got lost in
> > other things. Please, please - do this someone and beat me to it. ;)
> >
> > regards, Gran
>
> I started on this but quickly got mired in a plethora of changes.  I
> started with a newly download 3.9a-7010.  I decided it made sense to
> look at the versions in the Network project on
> source.squeakfoundation.org from old to new, so I started with
> System-gk.45.mcz.
>
> Before loading it I decide to examine the changes to see if it makes
> sense to simply load it.  It quickly becomes obvious that it doesn't as
> compared to 7010 it involves _872_ changes.  I've looked and looked but
> I'm at a loss as to how I'm supposed to pick out the desired changes
> from those that are simply a result of 5 months of changes in the image.
>
> Ken

OK, I think (with Göran's help) I've working out a methodology.

OK, you've got a MC from the past.

Select it from the Repository window (for our project) and hit the
'History' button, we will refer to this as the 'project' MC.  Also in
the Monticello Browser window select the matching MC in the left pane
that represents the current version in the image, we will refer this as
the 'official' MC.  Comparing those find the latest version in the
history of the official MC that is also in the history of the project
MC.

In the history list for the project MC select that common ancestor.
Right click and choose to 'view changes' from the selected version to
the project version.  That should show you the intended changes which
should be a small list and you can install these individually.

At that point you can save the MC producing a MC relative to the current
image with the appropriate changes.  Then you can go on to the next one,
and so on.

Ken


_______________________________________________
Io mailing list
Io@...
http://lists.squeakfoundation.org/mailman/listinfo/io

[Göran Krampe]

Howdy dudes!

Ken Causey <ken@...> wrote:

> On Thu, 2006-03-16 at 22:34 +0100, Cees De Groot wrote:
> > On 3/16/06, Ken Causey <ken@...> wrote:
> > > System-gk.45.mcz.
> > I don't know what that's doing there. The Team's work should only
> > concern the Network and Files packages...
>
> Because classes interact.  The procedure is that if a method in another
> category is affected by a change to a class within a categery for which
> you are responsible, then go ahead and make the change (since you should
> know best how to make it) then forward the changes to the appropriate
> team for there verification.  There is no System Stewards team right
> now.  So what we do is send it on to the Release team to verify and
> incorporate.  In either case, we are going to inevitably be handling
> changes to classes outside of our categories, we simply shouldn't be
> pushing them through all the way ourselves.
>
> Ken

Exactly - and if Cees had read :) my original post in this thread he
would have read this:

> Any such bundle also typically includes other MCs
> outside of our domain with fixes - and the MC version note *clearly*
> explains what those are. So a "bundle" is actually a group of MCs where
> the version note of "our" MC naming the others (or else the release team
> will not understand what is included in the bundle).

regards, Göran
_______________________________________________
Io mailing list
Io@...
http://lists.squeakfoundation.org/mailman/listinfo/io

[Cees De Groot]

On 3/17/06, Ken Causey <ken@...> wrote:
> [...] That should show you the intended changes which
> should be a small list and you can install these individually.
>
Forgive me if I ask a dumb question (it is early and the morning
coffee hasn't suck in yet), but isn't the procedure you describe
exactly what the merge button does?
_______________________________________________
Io mailing list
Io@...
http://lists.squeakfoundation.org/mailman/listinfo/io

[Cees De Groot]

On 3/17/06, goran@... <goran@...> wrote:
> Exactly - and if Cees had read :) my original post in this thread he
> would have read this:
>
Sorry - still busy finishing off my house, so mails typically get a
timeframe that's way shorter than they deserve.
_______________________________________________
Io mailing list
Io@...
http://lists.squeakfoundation.org/mailman/listinfo/io

[Ken Causey]

On Fri, 2006-03-17 at 09:24 +0100, Cees De Groot wrote:
> On 3/17/06, Ken Causey <ken@...> wrote:
> > [...] That should show you the intended changes which
> > should be a small list and you can install these individually.
> >
> Forgive me if I ask a dumb question (it is early and the morning
> coffee hasn't suck in yet), but isn't the procedure you describe
> exactly what the merge button does?

Not a dumb question at all (and we all know what you usually say about
'dumb questions' :) ) as I'm also struggling to come to understand.

And now I feel dumb. :)

It does indeed do that.  I thought I saw something different before.
And I'm not at all sure I'm not somehow making a mistake now, but
hitting Merge for System-gk.45 does indeed show me only 2 changes.

Short version: Ignore this section of this thread and just use the Merge
button.  Sorry for the confusion.

Ken


_______________________________________________
Io mailing list
Io@...
http://lists.squeakfoundation.org/mailman/listinfo/io