On 07.12.2008, at 14:29, Keith Hodges wrote:

> Edgar,
>
> The whole ethos behind 3.11 is to provide a framework for people to
> contribute.
>
> If we get that right progress is assured. I admit I myself have had  
> some
> hiccups, I have had domestic problems, and lots of deadlines in my day
> job. BUT, in a framework where people are encouraged and enabled to
> contribute that shouldn't matter.
>
> PROGRESS HAS CONTINUALLY BEEN MADE by someone somewhere, its just a
> matter of harnessing it.
>
> I am left with a huge sense of irony, given that the whole ethos  
> behind
> 3.11 is to provide a framework for people to contribute:
>
> Irony no. 1, the entire Pharo team create a fork. Benefit, Pharo guys
> get to do R&D for us to "acquire" later, iff we can persuade them to  
> be
> co-operative (i.e. use similar tools and apis)
>
> Irony no. 2 -
>
> I have tried and tried and tried, to encourage you, ask you persuade
> you, to bring your expertise and contribute, but you will not. You
> absolutely refuse.
>
> You have expertise in unloading bits of squeak into separate  
> packages. I
> hate grovelling around looking for obsolete references. You have  
> already
> done the work. All that needs to happen is to package your work into
> discrete #unload tasks, and Sake/Packages &/ Universes load tasks
>
> If a project whose goal is to encourage people to contribute cannot  
> get
> people to contribute then it is doomed from the start.
>> Andreas, you should take the challenge now.
>> Nobody could say you don't know Squeak in deep as they could say to  
>> me.
>>
>> I tired of no progress,
> I am fed up with you saying there is no progress. I do paid work in
> squeak, and from that perspective there has been LOTS of progress. In
> some ways Squeak was painful to use for commercial work.  I used to
> dread building up an image from scratch for a new client project,  
> and it
> was impossible to code several client projects simultaneously in one
> image (due to MC bugs).
> I am approaching the point where I can code all of my client  
> projects in
> one image, and automatically deploy to separate images for each  
> client.
>
> Things are getting much better than they were a year ago and as soon  
> as
> "Bob the Builder" is ready there will be a whole lot more progress.
>
> LevelPlayingField - is a huge bonus
> Monticello - 100's of fixes, huge speed improvements, Files support (I
> announced yesterday)
> Sake/Packages - Actually does work
> Sake - Simple but ultimately very powerful.
> Tasks - Framework for organising 3.11
> Pharo - R&D for Squeak 3.1x
> FunSqueak - R&D for Sake/Packages
> SqueakLightII - R&D for Squeak3.1x
>> only read about ideas but no evidence of going in
>> the good direction.
>>
> But Edgar you have decided in advance not to be interested. You take  
> one
> look at the fact I embed small scripts in Mantis bug reports and you
> refuse to contribute even there. You have never contributed one  
> script.
> Have you ever loaded a fix using Installer mantis ensureFix: 474 ?  
> It is
> actually very useful.
>
> You tell me that all these guru people should be listened to, at the
> same time you tell me I am not worth listening to. I have been coding
> for 32 years, you never know I might know something after all, you  
> might
> learn something.  Sorry I am not a professor in an academic ivory  
> tower,
> I am a pragmatic programmer, and for me perfectionism gives way to
> pragmatism.
>
> This means that I appreciate the need for TEAM, I cannot do it on my
> own. Matthew has been a huge help to me, dotting i's and crossing  
> t's. I
> wrote the code for atomic loading in Monticello 1.6  in December 2007.
> Colin wrote the code for SystemEditor long before that. It is Matthew
> who has had the patience to get SystemEditor to work as required  
> through
> painstakingly careful testing. So the irony no.1 is that many  
> potential
> team members have gone off to pharo, the irony number 2 is that other
> potential team members are hankering after the same old way of doing
> things and have dug their heals in.
>
> Sure I might be wrong, and if I am, I would be happy to be shown a
> better way. For 3 years the community has talked about a better way
> would be led by improved tools, and greater modularity. Meanwhile
> release teams have soldiered on declaring that "We are not going to
> develop anything, just integrate what the community gives us". The
> community has lacked the tools to give the release teams what they  
> were
> asking for. The lead time for a new bit of code to get into the  
> image is
> probably on average 3 years in a good year.
>
> 3.11 might look a bit slow of the mark, and I have my fair share of
> excuses. BUT we are actually coding stuff, and coding stuff takes a  
> bit
> more time than cherry picking code that is already out there.
>
> To be honest, all of my code works in 3.7, so from the pragmatic
> perspective, the huge efforts put in by 3.8 3.9 and 3.10 teams to give
> us incremental changes has not really been that radical, or even  
> useful.
> So from a pragmatic sense if 3.11 follows the same... "One person  
> load a
> few fixes and release an image" ethos, it is valueless to me.
>
> At one point the Board/Oversight Team/Leaders(?) recognized this, and
> felt that the effort was better spent on something radically new (i.e.
> Spoon). I campaigned for 3.11 to go ahead because I knew we had a  
> lot to
> harness that would be really useful, and would be potentially be  
> lost if
> we didn't do it,  not because I wanted 50 more random fixes in my  
> image.
>
> In contrast the ... "harness lots of creativity from lots of people,  
> and
> enable as much stuff to work as possible for everyone" ethos behind  
> 3.11
> will give me benefits, it will, and already has given me lots more
> things to play with.
>
> It is well known that technical projects never fail due to technical
> reasons. Politics is always the make or break of any software, and I
> dont do politics, I cant see much point in tact or diplomacy. If we  
> fail
> to make progress, I will blame the politicians.
>
> Now you are on the board Edgar, that makes you a politician.
>> The last good Squeak release with wide consensus was 3.8
>>
> Which is a fact of life
>> Then come people who for his own (maybe good) purposes introduce  
>> Traits.
>> You always said and I support still no evidence Traits give us some  
>> we don't
>> could made with good Smalltalk.
>> And introduce the troubles.
>> Almost all major forks is no Traits (3.8) based.
>>
> And Matthew has done the work to make this a non-issue.
>> But if nobody take the trouble to see how to go from existent  
>> Monticello and
>> current image to smaller and modular, never we could reach any of it.
>>
> Perhaps I should change my name to "Nobody"
>> I do my best, sometimes good and sometimes bad.
>> Scripting people always could script it if they wish.
>>
> and Image tweaking people can always Image tweak if they wish. But  
> their
> work is more difficult to harness and cross fertilize between forks  
> and
> different sectors of the community. They have no ethos of desiring  
> it to
> be possible, and no means to transact it.

If you mean the Etoys image with that comment - we simply chose the  
most efficient way for us to deliver. We were 5 people, most of them  
not even working full-time on Etoys. We have an installed user base of  
at least 500,000. We have to be careful about backwards compatibility.  
Doing this while trying to keep in sync through 3.9, 3.10, etc., would  
frankly have put the whole project in jeopardy. OTOH we tried to break  
out the separable functionality so it can be used in other projects -  
e.g., the DBus support, GStreamer support, which are maintained as  
Monticello packages.

I for one would love to see Etoys being maintained in sync with (or  
even inside) the squeak.org version, and now that the pace of  
development has slowed down on the Etoys side this might even be  
feasible. However, since Etoys never was a community-driven scratch- 
your-own-itch project, somebody would have to come forward declaring  
it his own itch (like Marcus and Michael did in 3.8). Recently I've  
only seen Edgar express interest in that direction.

> In contrast the scripting side of arguement goes like this:
>
> 3.11 is generated by a series of scripted tasks, but that script is
> modular in such a way as to be useful to another fork, say Sophie.  
> i.e.
> we actively view other forks as part of the same moving forward  
> process.
> We support them, we don't leave them out on their own.
>
> They can take a copy or a specialised subclass of the 3.11 set of  
> tasks,
> and apply them to their next release.
>
> If all the forks, apply their core improvements via a common set of
> tasks, and packages. And if all the forks use a common set of tools to
> organise their work. Then they will naturally converge where it is  
> most
> important, where there is the most overlap.
>
> There is a vision for the politicians to think about
>
> best regards
>
> Keith


I like your vision, and the progress you are making :)

- Bert -