[Election] ...is soon upon us! Last day info

> You're simply wrong on this.  I, with help from others, managed to  
> get the closure compiler into several dialects quite recently and I  
> can assure you that changing the compiler under one's feet is  
> tricky.  There is nothing inherent in the trunk model that hinders  
> difficult change.

When the change is finished.

You made the changes off-line using your own processes. Therefore the  
development "process" is not trunk, it is whatever you used at home  
because trunk wasn't appropriate for the task. Trunk is only the  
publication mechanism, and I will bet the trunk process didn't help  
you by making the development process easier in any way.

>  A coordinated series of package updates is just as powerful as  
> changesets.

How do you go backwards, if you are always going forwards?

> One simply has to try and try again

where? I don't have any control to un-commit stuff from trunk.

> because one will make mistakes and the system will break and one  
> will be able to discover why and compensate.  Don't confuse the  
> medium with the message. Change sets

Are simple flexible and powerful, and file in can be implemented in  
one class.

> and MC packages are

are very rigid and complex and require a specific version of MC, which  
happens not to be the version I use.

> media but they can convey many messages.  Eventually one gets to a  
> depth at which these media fail to do the whole job (for example  
> changing the object format, bytecode set etc).  But Smalltalk's  
> reflective nature is what makes both of these media equally powerful  
> and equally unsafe.  If you want to make deep changes you simply  
> have to be prepared to fail, to be confused, to be persistent

Sure, you can do that in your own process at home. but you cant do it  
with trunk. Being confused, and failing is my default state. So  
therefore trunk is of no use to me.

Keith

On Fri, 12 Mar 2010, keith wrote:

Parts of the "kernel" can be common, but common patches above that level
will hardly exist.

> c) moving targets are the worst possible scenario.

You just can't accept that the mcms are actually mini-releases.

> d) it uses tools that are too high level.

Hah.

> e) it is release a year rather then release a month

Erm no.

> f) it relies on an elite to manage it

Combine this with a) and you'll find that Squeak is being developed by
a group of elite hackers. Sounds impressive. ;)

> g) it closes out people who cant change things without breaking it.

>From one point of view:
This is the best feature. It allowed us to deploy several Trunk images. We
ported all but two of our apps to Trunk images and we can easily update
them - even on-the-fly - to have the lastest fixes and features.

>From another:
You're wrong. If you can't integrate your changes, you can add it to the
Inbox, or just send the changesets and someone will do the integration if
it turns out to be useful.

>
> You keep using trunk, and you close me out.

No, you're closing yourself out, because you don't want to use it.

>
> So far there has been one useful contributor to trunk, and that was when
> Torsten posted a changeset to this list, and I used it.

You could create changesets from the mczs based on the mcms, but I think
you simply don't want to do that.


Levente

>
> The fact that I can knock up a brand new process in less than a week which is
> better than trunk, simply shows how bad it is.
>
> regards
>
> Keith
>

On 3/13/10 12:40 AM, "Levente Uzonyi" <[hidden email]> wrote:

> Combine this with a) and you'll find that Squeak is being developed by
> a group of elite hackers. Sounds impressive. ;)

Not only by elite hackers.
By elite hackers with own agenda and none coordination.

> or just send the changesets and someone will do the integration if
> it turns out to be useful.

My memory is worst each day...
In which part of any of mails about trunk said such thing?
My agenda is just this, bring back old plain .cs and continue using current
trunk procedure.

> create changesets from the mczs
I have such mechanisms working in SL3dot11, the updates folder in
Experiments contains and as soon some repair the add server and the added
named server could be used I put a updated version of below code into the
image.

!Utilities class methodsFor: 'fetching updates' stamp: 'edc 6/10/2009
07:51'!
slUpdates
    "Utilities slUpdates"
    | previousHighest server dir count sourceFile fileName pos x |
    previousHighest := SystemVersion current highestUpdate.
    server := ServerDirectory serverNamed: 'SL'.
    dir := server directoryNamed: 'SLupdates'.
    count := 0.
    dir entries
        select: [:c |
            x := c name initialIntegerOrNil.
            x
                ifNil: [x := 0].
            x > previousHighest]
        thenCollect: [:any |
            (any name endsWith: '.sqz')
                ifTrue: [fileName := any name.
                    pos := fileName findString: '.sqz'.
                    fileName := fileName copyFrom: 1 to: pos - 1.
                    sourceFile := HTTPLoader default retrieveContentsFor:
'ftp.squeak.org/various_images/SqueakLight//SLupdates/' , any name.
                    sourceFile := RWBinaryOrTextStream with: sourceFile
content unzipped]
                ifFalse: [sourceFile := RWBinaryOrTextStream with: (dir
getFileNamed: any name) contents.
                    sourceFile reset.
                    self saveUpdate: sourceFile onFile: any name].
            ChangeSorter newChangesFromStream: sourceFile named: any name.
            count := count + 1].
    PopUpMenu inform: count asString , ' new update file(s) processed.'.
    SystemVersion current registerUpdate: ChangeSorter
highestNumberedChangeSet.
    SmalltalkImage current aboutThisSystem.! !

Edgar
 

On 3/13/10 12:42 AM, "Josh Gargus" <[hidden email]> wrote:

>>  1) the board has no constitution,
 Back to racing cars example
 The Œrules for next season car Œ have FIA .
 We have Board, but until this election no simple word about which rules was
 in effect for ³2010 season²
 And no word about which car we must build..
A Formula one car ? A Le Mans car ? Or a Dakar Truck ?
 
 http://www.youtube.com/watch?v=vZpAvFyAo5c
>> 2) trunk is the worst possible process

No is not.
It's good as is fast and have many talented Squeakers working hard.
But need improve, coordination and be sure image do not break .
Some of us like use more as Workspace ,Transcript and Monticello Browser :=)

Edgar

2010/3/12 keith <[hidden email]>:
Keith
What pathetic selfish statements.
Not used by Keith = not usefull, hey we get the equation of your
internal algorithm.
Plus you're insulting everyone making an effort to contribute, that's
definitely not your best arguments.
Your process will be better than trunk when there will be at least two
developpers.
As it was said before, it's a matter of social organization, and from
that POV your process was not proved better so far.

Nicolas

Edgar J. De Cleene wrote:
>
>
> On 3/13/10 12:40 AM, "Levente Uzonyi" <[hidden email]> wrote:
>
>> Combine this with a) and you'll find that Squeak is being developed by
>> a group of elite hackers. Sounds impressive. ;)
>
> Not only by elite hackers.
> By elite hackers with own agenda and none coordination.

(1) EVERYONE has an agenda. It's called "What I want Squeak to do."

(2) Let's suppose for just a moment that Evil Andreas was up to No Good
and wanted to Hijack The Image. And, well, so what? He and the other
trunk hackers are spending their time and effort improving squeak so
that WE ALL can have a better Squeak. What's he going to do? Climb into
your computer and take away your copy of trunk? Are ALL the trunk
hackers in on this conspiracy? Just the Teleplace people? Just Andreas?

So can we all please just let this argument DIE already? We did actually
have a while where we all managed to work together. Let's please try to
find that common ground again.

frank

On 3/13/10 7:29 AM, "Frank Shearar" <[hidden email]> wrote:

> Just the Teleplace people? Just Andreas?
No see conspiracy when I do not see.

If Teleplace have 42 engineers each with his own agenda, soon is out of
business.

I was who say Andreas should become Squeak CEO, so how I could think my CEO
wish sink Squeak Inc ?.

Good workers need coordination.

Tell me if know any sports team of soccer or rugby whose players do not play
together.

Edgar

On 3/13/2010 1:06 AM, Edgar J. De Cleene wrote:
> Good workers need coordination.
>
> Tell me if know any sports team of soccer or rugby whose players do not play
> together.

But we *do* play together, do we not? We discuss changes here, we commit
them to the trunk repository. I don't get why you're saying there is no
coordination and no teamplay.

Cheers,
   - Andreas

On 3/13/10 8:04 AM, "Andreas Raab" <[hidden email]> wrote:

>
> But we *do* play together, do we not? We discuss changes here, we commit
> them to the trunk repository. I don't get why you're saying there is no
> coordination and no teamplay.
>
> Cheers,
>    - Andreas

If you think so, I drop the subject.

Cheers

Edgar

On 13 March 2010 11:24, Edgar J. De Cleene <[hidden email]> wrote:
Edgar, if you think there are something which prevents you from
participation, say it.

Your last couple messages indicating that you are not quite satisfied
with current processes.
So, please tell us, what you think can be changed to make it better.

> Cheers
>
> Edgar
>


--
Best regards,
Igor Stasenko AKA sig.

On 3/13/10 8:26 AM, "Igor Stasenko" <[hidden email]> wrote:

> Edgar, if you think there are something which prevents you from
> participation, say it.

I do not say such thing.
And I was working.
 
> Your last couple messages indicating that you are not quite satisfied
> with current processes.
> So, please tell us, what you think can be changed to make it better.

Well , maybe is just me.
>From the South you see everything upside down.
If all say all works and all was happy...


Bahrain Grand Prix Qualifying start now, go to see TV.

Good week end and the Monday I deliver fourth week FunSqueak and first week
SL3dot11 reports.

Edgar

On 13 March 2010 11:57, Edgar J. De Cleene <[hidden email]> wrote:
Hi, antipode :)

> If all say all works and all was happy...
>
so, you taking your words back? Not very good move, as for a potential
board member. Fight. :)

>
> Bahrain Grand Prix Qualifying start now, go to see TV.
>
i never understood what is so exciting in watching how cars on
steroids circling over stadium.
I like a football, where tactics and teamplay decides who will win.
In car racing - a racer is alone, and wins one, who has better
reflexes. Also there are no tactics - just push the gas pedal :)

> Good week end and the Monday I deliver fourth week FunSqueak and first week
> SL3dot11 reports.
>
> Edgar



--
Best regards,
Igor Stasenko AKA sig.

On 3/13/10 9:06 AM, "Igor Stasenko" <[hidden email]> wrote:
>so, you taking your words back? Not very good move, as for a potential
>board member. Fight. :)

No point.  If the majority thinks we no need changes , I follow .
If / When I have a seat vote against and lose 6 to 1

> Also there are no tactics
Ja. Why you think Mercedes hired Ross Braun?

Red Bull car wins qualify, Vettel is very good driver.
Ferrari is in good shape and Schummy start the comeback rusty but in next
races sure improves.

Edgar

Keith

On 13 Mar 2010, at 08:32, Nicolas Cellier wrote:

Its a philosophical debate, nothing to do with selfishness.

Trunk is making an image in which innovations get absorbed and  
manually integrated into the blob.

Therefore if anyone else wants that innovation to use it in another  
context they have to reverse engineer what happened in trunk,  
therefore trunk is making work for people in other forks, which they  
will not do lightly.

For example, trunk cannot even manage to use an Installer version that  
is managed in an external repository. Now trunk development is  
apparently making work for me, to integrate things back out to  
installer's repo.

If trunk used an integration step, which loaded things from external  
repositories periodically, rather than "selfishly" keeping control of  
everything in trunk, then we might be ok.

> As it was said before, it's a matter of social organization, and from
> that POV your process was not proved better so far.



Keith

Levente Uzonyi wrote on Thu, 11 Mar 2010 01:03:49 +0100 (CET)
[yes, I am having problems keeping up with the current squeak-dev
traffic]
> On Wed, 10 Mar 2010, keith wrote:
> > Having a kernel image is essential if the forking problem is to be turned
> > into an opportunity, rather than a pain.
>
> I don't think anyone would like to make new forks in the near future
> (except for Jecel). It's easier to cooperate than to do everything
> on your own.

Hmmm, it seems I gave the wrong impression. First of all, we should
define "fork". Normally we think of development as a tree with a "trunk"
of a sequence of official versions and some sideways branches that we
consider to be forks. I am a bit more radical and say that a newer
version in the trunk can also be considered a fork. If some application
works in Squeak 3.7 but breaks when loaded into Squeak 3.8, then I
consider the latter to be a fork even if there are no sideways branches
(though now there is - Cuis is from Squeak 3.7, right?).

There are two ways to deal with this situation: 1) you can keep working
in 3.7 and sometimes harvest compatible bug fixes from newer versions or
2) you can change the application so that it does run in 3.8 (should be
easy enough - mostly changing some class names and eliminating a
"squeakToIso" and similar here and there). Option 2 results in an
application that will now break when loaded into Squeak 3.7, so a fork
in the environment forces a fork in the applications.

Now the transition from Squeak 3.7 to 3.8 won't feel at all like a fork
if everybody moves nearly at once and you can update from within a
running image. If enough people stay behind or if you need the
SystemTracer to get from the old image to the new then it will easier to
see that it is a fork.

Things get really annoying if you have one application that runs only in
3.7 and another that only works in 3.8 and you need to use both.
Obviously, you can just open up two Squeak windows on your machine. You
can even copy/paste between the two for some very limited and crude
collaboration between the two. A more sophisticated solution would be to
install in each image some distributed system package, like rST. If the
two images could reference each other's objects and send messages to
them, then you could do almost anything that you could do with both
applications inside a single image. At some point the differences would
leak between the two systems and things would break, but I think you
would be able to get enough extra things done in this system to be worth
doing this.

We could avoid having two or more native windows if one of the images
had some system of combining the GUIs from others (like
http://swikis.ddo.jp/SeeThroughTalk).

So if we have multiple communicating images, we will be able to handle
forks to some extent. A VM could even handle both images with the
current image format and with the very different ObjectMemory I talked
about at the same time (or a pair of VMs could do the job). This would
allow new code to take advantage of old stuff, which is something I am
very interested in. Would the new code be a fork? That depends on how
many people adopt it or not.

-- Jecel