Smalltalk › Squeak › Squeak - Dev

[squeak-dev] Nebraska-edc.15 in trunk unloadable

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

33 messages Options

Ken Causey-3

[squeak-dev] Nebraska-edc.15 in trunk unloadable

Edgar,

I started up my trunk development image today and as usual started by
checking for updates. I had also done this yesterday. The very first
update it seems for me was your Nebraska-edc.15. Loading this resulted
in an emergency debugger with a DNU on WorldState>>remoteCanvasesDo:.

Ken

signature.asc (196 bytes) Download Attachment

Ken Causey-3

Re: [squeak-dev] Nebraska-edc.15 in trunk unloadable

More info:

It turns out that the first update I did not have was
ReleaseBuilder-edc.33 . So I merged this in manually and then moved on
to the next which was Nebraska-edc.14. It's actually on this update
that I get the error.

I'm not sure of the behavior of the updates process. Is it possible
that if I have neither .14 or .15 that in fact it doesn't merge 14 and
then 15 but simply 15? Perhaps it is in fact irrelevant.

Ken

On Fri, 2009-07-17 at 11:28 -0500, Ken Causey wrote:
> Edgar,
>
> I started up my trunk development image today and as usual started by
> checking for updates. I had also done this yesterday. The very first
> update it seems for me was your Nebraska-edc.15. Loading this resulted
> in an emergency debugger with a DNU on WorldState>>remoteCanvasesDo:.
>
> Ken

signature.asc (196 bytes) Download Attachment

Bert Freudenberg

Re: [squeak-dev] Nebraska-edc.15 in trunk unloadable

In reply to this post by Ken Causey-3

On 17.07.2009, at 18:28, Ken Causey wrote:

> Edgar,
>
> I started up my trunk development image today and as usual started by
> checking for updates. I had also done this yesterday. The very first
> update it seems for me was your Nebraska-edc.15. Loading this
> resulted
> in an emergency debugger with a DNU on WorldState>>remoteCanvasesDo:.
>
> Ken

He, maybe we need to invent methods to punish developers who break the
trunk in such a way ;)

But at least now that updating is possible again such problems will
not go unnoticed for long.

In any case a process where development slows down when nearing a
release would be in order, we might need feature freezes etc. Maybe we
simply set a release date now and then work towards it?

- Bert -

Ken Causey-3

Re: [squeak-dev] Nebraska-edc.14 (was Nebraska-edc.15) in trunk unloadable

In reply to this post by Ken Causey-3

Edgar,

In Nebraska-edc.14 you remove WorldState>>remoteCanvasesDo: without
modifying the senders including WorldState>>forceDamageToScreen:.

Ken

On Fri, 2009-07-17 at 11:47 -0500, Ken Causey wrote:

> More info:
>
> It turns out that the first update I did not have was
> ReleaseBuilder-edc.33 . So I merged this in manually and then moved on
> to the next which was Nebraska-edc.14. It's actually on this update
> that I get the error.
>
> I'm not sure of the behavior of the updates process. Is it possible
> that if I have neither .14 or .15 that in fact it doesn't merge 14 and
> then 15 but simply 15? Perhaps it is in fact irrelevant.
>
> Ken
>
> On Fri, 2009-07-17 at 11:28 -0500, Ken Causey wrote:
> > Edgar,
> >
> > I started up my trunk development image today and as usual started by
> > checking for updates. I had also done this yesterday. The very first
> > update it seems for me was your Nebraska-edc.15. Loading this resulted
> > in an emergency debugger with a DNU on WorldState>>remoteCanvasesDo:.
> >
> > Ken

signature.asc (196 bytes) Download Attachment

Ian Trudel-2

Re: [squeak-dev] Nebraska-edc.15 in trunk unloadable

In reply to this post by Bert Freudenberg

2009/7/17 Bert Freudenberg <[hidden email]>:
> He, maybe we need to invent methods to punish developers who break the trunk
> in such a way ;)

Or maybe not. In a continuous integration process, edgar could have
been notified by email that his changes broke the trunk. A carbon copy
can also be sent to the repository admit.

> In any case a process where development slows down when nearing a release
> would be in order, we might need feature freezes etc. Maybe we simply set a
> release date now and then work towards it?

That would make sense. The trunk should be frozen at some point in the
perspective of a release and then enter in a release phase. And the
release phase can be something along 3.11 proposal. My idea of both
development process is that they are not mutually exclusive.

Are we going to have continuous integration on the trunk? Publishing
results on a web page or something would be great.

Ian.

--
http://mecenia.blogspot.com/

Douglas Brebner

Re: [squeak-dev] Nebraska-edc.15 in trunk unloadable

Ian Trudel wrote:

> 2009/7/17 Bert Freudenberg <[hidden email]>:
>
>> In any case a process where development slows down when nearing a release
>> would be in order, we might need feature freezes etc. Maybe we simply set a
>> release date now and then work towards it?
>>
>
> That would make sense. The trunk should be frozen at some point in the
> perspective of a release and then enter in a release phase. And the
> release phase can be something along 3.11 proposal. My idea of both
> development process is that they are not mutually exclusive.
>
>

Why not make a branch rather than freezing the trunk? That way it should
be easier to determine what goes into a release, especially if it's
built from spec rather than hand crafted.

Ken Causey-3

Re: [squeak-dev] Nebraska-edc.15 in trunk unloadable

In reply to this post by Bert Freudenberg

On Fri, 2009-07-17 at 19:01 +0200, Bert Freudenberg wrote:
> In any case a process where development slows down when nearing a
> release would be in order, we might need feature freezes etc. Maybe we
> simply set a release date now and then work towards it?
>
> - Bert -

I would suggest an alternate model. Rather than forcing developers as a
group to follow some sort of schedule why not consider a release a
snapshot of the development trunk minus some questionable or problematic
updates plus some additional cleanups relevant to a release.

Let's say I wanted to create a release today and let's posit that there
are a number of known good updates after Nebraska 14 and 15. I could
update to the update just before Nebraska 14, then manually merge in the
updates afterward. Then do whatever clean up I want to do. Then
release.

Ken

P.S. One thing the new update stream does appear to lack compared to the
old update stream is the ability to easily update only up to a certain
update number. Is there some way that could be implemented? Clearly
the trunk is not the simplistic linear thing the old update stream was.

signature.asc (196 bytes) Download Attachment

Ian Trudel-2

Re: [squeak-dev] Nebraska-edc.15 in trunk unloadable

In reply to this post by Douglas Brebner

2009/7/17 Douglas Brebner <[hidden email]>:
> Why not make a branch rather than freezing the trunk? That way it should
> be easier to determine what goes into a release, especially if it's
> built from spec rather than hand crafted.

That could be an option as far as I am concerned. It would probably
better fit with a release process, as in 3.11 proposal.

Ian.
--
http://mecenia.blogspot.com/

Bert Freudenberg

[squeak-dev] Release engineering

In reply to this post by Douglas Brebner

On 17.07.2009, at 19:38, Douglas Brebner wrote:

> Ian Trudel wrote:
>> 2009/7/17 Bert Freudenberg <[hidden email]>:
>>
>>> In any case a process where development slows down when nearing a
>>> release
>>> would be in order, we might need feature freezes etc. Maybe we
>>> simply set a
>>> release date now and then work towards it?
>>>
>>
>> That would make sense. The trunk should be frozen at some point in
>> the
>> perspective of a release and then enter in a release phase. And the
>> release phase can be something along 3.11 proposal. My idea of both
>> development process is that they are not mutually exclusive.
>>
>>
> Why not make a branch rather than freezing the trunk? That way it
> should
> be easier to determine what goes into a release, especially if it's
> built from spec rather than hand crafted.

Given our rather small active developer community I do not find it
advisable to split the work force. Everyone should work together
towards a release and not just the few poor souls who work on the
release branch. This way everyone uses the release candidate, it gets
much wider testing etc.

I recently saw a presentation on the OpenBSD release process and found
Theo's argument in favor of this convincing:
http://www.youtube.com/watch?v=i7pkyDUX5uM

- Bert -

Ian Trudel-2

Re: [squeak-dev] Release engineering

2009/7/17 Bert Freudenberg <[hidden email]>:
> Given our rather small active developer community I do not find it advisable
> to split the work force. Everyone should work together towards a release and
> not just the few poor souls who work on the release branch. This way
> everyone uses the release candidate, it gets much wider testing etc.
>
> I recently saw a presentation on the OpenBSD release process and found
> Theo's argument in favor of this convincing:
> http://www.youtube.com/watch?v=i7pkyDUX5uM
>

I haven't checked the video yet. Your comment puts things back into
perspective. Limited work force should taken into consideration and
whatever the solutions are, it shouldn't give more work to those who
actively participate.

This reminds me that we are perhaps trying to run before we can walk (again).

The community repositories is an experiment as far as I have
understood, which should allow to reenact community commitment to
Squeak and, ultimately, figure out a development model that will be
fit to the community.

3.11 proposal is all about planning. Community development model is
all about action. We need to get dirty and see how it turns out. Then,
we can bring real solutions rather than solutions to problems that we
haven't encountered yet. We cannot continuously step ahead problems.

Bert, I agree with you.

Ian.

--
http://mecenia.blogspot.com/

Bert Freudenberg

Re: [squeak-dev] Release engineering

In reply to this post by Bert Freudenberg

On 17.07.2009, at 19:41, Ken Causey wrote:

> On Fri, 2009-07-17 at 19:01 +0200, Bert Freudenberg wrote:
>> In any case a process where development slows down when nearing a
>> release would be in order, we might need feature freezes etc. Maybe
>> we
>> simply set a release date now and then work towards it?
>>
>> - Bert -
>
> I would suggest an alternate model. Rather than forcing developers
> as a
> group to follow some sort of schedule why not consider a release a
> snapshot of the development trunk minus some questionable or
> problematic
> updates plus some additional cleanups relevant to a release.
>
> Let's say I wanted to create a release today and let's posit that
> there
> are a number of known good updates after Nebraska 14 and 15. I could
> update to the update just before Nebraska 14, then manually merge in
> the
> updates afterward. Then do whatever clean up I want to do. Then
> release.

IMHO that would prolong the problem that the release is not a real
community effort. For many years now, the release team consisted of
very few people who had to do all the integration work themselves. I
feel that this is simply too much of a burden for those individuals
(even though they volunteered to do it) and at the same time a much
greater sense of a shared product could be created in the community by
actually working on that product together.

I think extending the number of committers is one of the most valuable
aspects of the trunk model. It comes along with greater responsibility
for all of course, but that can only be good I'd say.

- Bert -

Bert Freudenberg

Re: [squeak-dev] Nebraska-edc.15 in trunk unloadable

In reply to this post by Ian Trudel-2

On 17.07.2009, at 19:29, Ian Trudel wrote:

> 2009/7/17 Bert Freudenberg <[hidden email]>:
>> He, maybe we need to invent methods to punish developers who break
>> the trunk
>> in such a way ;)
>
> Or maybe not. In a continuous integration process, edgar could have
> been notified by email that his changes broke the trunk. A carbon copy
> can also be sent to the repository admit.

... and a Bad Developer Of The Week Award on the Squeak home page ;)

Just kidding.

>> In any case a process where development slows down when nearing a
>> release
>> would be in order, we might need feature freezes etc. Maybe we
>> simply set a
>> release date now and then work towards it?
>
> That would make sense. The trunk should be frozen at some point in the
> perspective of a release and then enter in a release phase. And the
> release phase can be something along 3.11 proposal. My idea of both
> development process is that they are not mutually exclusive.
>
> Are we going to have continuous integration on the trunk? Publishing
> results on a web page or something would be great.

Yes, that would be awesome to have.

- Bert -

Ken Causey-3

Re: [squeak-dev] Release engineering

In reply to this post by Bert Freudenberg

On Fri, 2009-07-17 at 19:55 +0200, Bert Freudenberg wrote:

> On 17.07.2009, at 19:41, Ken Causey wrote:
> > On Fri, 2009-07-17 at 19:01 +0200, Bert Freudenberg wrote:
> >> In any case a process where development slows down when nearing a
> >> release would be in order, we might need feature freezes etc. Maybe
> >> we
> >> simply set a release date now and then work towards it?
> >>
> >> - Bert -
> >
> > I would suggest an alternate model. Rather than forcing developers
> > as a
> > group to follow some sort of schedule why not consider a release a
> > snapshot of the development trunk minus some questionable or
> > problematic
> > updates plus some additional cleanups relevant to a release.
> >
> > Let's say I wanted to create a release today and let's posit that
> > there
> > are a number of known good updates after Nebraska 14 and 15. I could
> > update to the update just before Nebraska 14, then manually merge in
> > the
> > updates afterward. Then do whatever clean up I want to do. Then
> > release.
>
> IMHO that would prolong the problem that the release is not a real
> community effort. For many years now, the release team consisted of
> very few people who had to do all the integration work themselves. I
> feel that this is simply too much of a burden for those individuals
> (even though they volunteered to do it) and at the same time a much
> greater sense of a shared product could be created in the community by
> actually working on that product together.
>
> I think extending the number of committers is one of the most valuable
> aspects of the trunk model. It comes along with greater responsibility
> for all of course, but that can only be good I'd say.
>
> - Bert -

I don't see why the process of deciding what to remove and what to add
in can't be done as a group. While my description is clearly a manual
one I don't see that it can't be largely automated and that the
description of what is done could be a joint one among those interested.

Personally I suspect that not all core developers find the details of
individual releases to be all that interesting and are in fact willing
to rely on others with more interest to define them. I don't wish to
exclude anyone, but at the same time I see no reason why any particular
individual must participate in this part of the process.

Ken

signature.asc (196 bytes) Download Attachment

Edgar J. De Cleene

Re: [squeak-dev] Nebraska-edc.15 in trunk unloadable

In reply to this post by Ken Causey-3

On 7/17/09 1:47 PM, "Ken Causey" <[hidden email]> wrote:

You need wait until Andreas and me have perfect understanding.
Take all I do for SqueakLightII is not easy.
I suggest to Andeas return to updates folder policy , so we could have a
proper

7161AdvanceToThreeDotElevenAlpha.cs
7162ConvertTo3dot11.cs
or some like that

Actually my video

http://www.morphle.com/~edgar/Don%27t%20try%20this%20at%20home.mov

Shows how I convert 3.10 to 3.11 and you see before ReleaseBuilder run and
do his magic I need fileIn a .cs

The proper number is 15 , but all have sense in a new image, not in a older
one.

We have two years of nothing and miss understanding so be patient.
In the end all works.

Edgar

bpi

Re: [squeak-dev] Release engineering

In reply to this post by Bert Freudenberg

Am 17.07.2009 um 19:55 schrieb Bert Freudenberg:

> IMHO that would prolong the problem that the release is not a real
> community effort. For many years now, the release team consisted of
> very few people who had to do all the integration work themselves. I
> feel that this is simply too much of a burden for those individuals
> (even though they volunteered to do it) and at the same time a much
> greater sense of a shared product could be created in the community
> by actually working on that product together.
>
> I think extending the number of committers is one of the most
> valuable aspects of the trunk model. It comes along with greater
> responsibility for all of course, but that can only be good I'd say.

+10!

Cheers,
Bernhard

keith1y

Re: [squeak-dev] Nebraska-edc.15 in trunk unloadable

In reply to this post by Ken Causey-3

Ken Causey wrote:
> Edgar,
>
> I started up my trunk development image today and as usual started by
> checking for updates. I had also done this yesterday. The very first
> update it seems for me was your Nebraska-edc.15. Loading this resulted
> in an emergency debugger with a DNU on WorldState>>remoteCanvasesDo:.
>
> Ken
>
Now if you look at the existing loadable Nebraska in Sake/Packages the
definition for 3.10.2 is as follows

Nebraska

self name: 'Nebraska'.
info category: 'Morphic'.
info description:
'Nebraska load/unload'.
info maintainer: 'kph'.

self version: '14'.

self load: [
(WorldState includesSelector: #remoteCanvasesDo:) ifTrue: [
WorldState organization classify: #remoteCanvasesDo: under:
'*morphicextras-nebraska compatible'.
].
Installer squeaksource project: '311' ; install: 'Nebraska-kph.14'.
].

Do we really have to do everything 3 times?

Keith

keith1y

Re: [squeak-dev] Nebraska-edc.15 in trunk unloadable

In MC1.5 each package remembers in PackageInfo properties dictionary,
where it was loaded from, so it is possible to get an update of the
latest from the correct repository

Keith

Edgar J. De Cleene

Re: [squeak-dev] Nebraska-edc.15 in trunk unloadable

On 7/17/09 4:41 PM, "Keith Hodges" <[hidden email]> wrote:

> In MC1.5 each package remembers in PackageInfo properties dictionary,
> where it was loaded from, so it is possible to get an update of the
> latest from the correct repository
>
> Keith

SqueakLighII don't use Bob, MC 1.5 , Sake , Installer or nothing with kph in
it.

I have it working to my own satisfaction and try to get some of it to main
3.11.

But I can stop at any moment, as fork builders more wise as me do.

I quit of Release team before as you never get the word TEAM

I disagree with some Andreas say, but I choose he as Squeak CEO and do my
best to learn and move Squeak to higher number as 7159 , which is same from
two years ago...

Edgar

Bert Freudenberg

Re: [squeak-dev] Nebraska-edc.15 in trunk unloadable

In reply to this post by Edgar J. De Cleene

On 17.07.2009, at 20:38, Edgar J. De Cleene wrote:

> On 7/17/09 1:47 PM, "Ken Causey" <[hidden email]> wrote:
>
>> More info:
>>
>> It turns out that the first update I did not have was
>> ReleaseBuilder-edc.33 . So I merged this in manually and then
>> moved on
>> to the next which was Nebraska-edc.14. It's actually on this update
>> that I get the error.
>>
>> I'm not sure of the behavior of the updates process. Is it possible
>> that if I have neither .14 or .15 that in fact it doesn't merge 14
>> and
>> then 15 but simply 15? Perhaps it is in fact irrelevant.
>>
>> Ken
> You need wait until Andreas and me have perfect understanding.

No, you need to upload your new MorphicExtras package too, since you
moved the method from Nebraska to this package.

Besides, in my image loading the latest Kernel package removes
Semaphore>>wait, which is fatal. Anyone else seeing this?

- Bert -

keith1y

Re: [squeak-dev] Nebraska-edc.15 in trunk unloadable

Bert Freudenberg wrote:

> On 17.07.2009, at 20:38, Edgar J. De Cleene wrote:
>
>> On 7/17/09 1:47 PM, "Ken Causey" <[hidden email]> wrote:
>>
>>> More info:
>>>
>>> It turns out that the first update I did not have was
>>> ReleaseBuilder-edc.33 . So I merged this in manually and then moved on
>>> to the next which was Nebraska-edc.14. It's actually on this update
>>> that I get the error.
>>>
>>> I'm not sure of the behavior of the updates process. Is it possible
>>> that if I have neither .14 or .15 that in fact it doesn't merge 14 and
>>> then 15 but simply 15? Perhaps it is in fact irrelevant.
>>>
>>> Ken
>> You need wait until Andreas and me have perfect understanding.
>
>
> No, you need to upload your new MorphicExtras package too, since you
> moved the method from Nebraska to this package.
>
> Besides, in my image loading the latest Kernel package removes
> Semaphore>>wait, which is fatal. Anyone else seeing this?
>
> - Bert -

Sorry but I have to laugh...

The result of this will be, more rules and controls as to whom can
contribute to trunk. As a result yet more people will get upset and
their contributions will not be valued or accepted.

In a team different people have different strengths, some are ideas
people and break things, some are a pain and ask the relevant questions,
some are finishers and dot i's and cross t's... I venture to suggest
that this "experimental" trunk process cannot support them all.

It can only really support those who are gifted like Andreas who can be
a whole team in one person, and most of us are used to trying to do
that, otherwise we would get nothing done ourselves.

So what you really need to do is put people in groups of people that
complement each others skills, and each group takes on a specific task.

Some will try and tell you that there has not been much progress in the
past two years, but the truth is that several major problem areas have
been tackled in this manner. In my team-let I have been the ideas person
(that breaks things in fits of inspiration), and Matthew has been the
sensible one that makes sure things work, it has worked quite well.

The problem of MC not working has been worked upon ad infinitum.
The problem of FileDirectory has been worked upon. Rio has been
rewritten 3 times in the past 2 years.
The problem of Packaging and dependants has been tackled, Sake/Packages
has had several iterations, and is now a bit simpler and more functional
than before.
Logging has had a few times around the block, etc etc.

So how about some ideas for some team initiatives that we can road map in.

Keith