[Cuis] Cuis

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
167 messages Options
1234 ... 9
Reply | Threaded
Open this post in threaded view
|

[Cuis] Cuis

Torsten Bergmann
Hi Keith,

BANG! (*Silence, nothing happens but Keith is thank god still alive*)

Welcome back! :)

Bye
T.

----------------------------------------------------------------
For those of you who dont understand the contents of the above
mail: according to [1] Keith suggested: "If I email to squeak-dev
again shoot me". Since he posted again there was no other option
left than trying to shoot him ;)

[1] http://lists.squeakfoundation.org/pipermail/squeak-dev/2009-December/142238.html

--
Hilfe für Haiti! Spende per SMS: Sende UI HAITI an die Nummer 81190.
Von 5 Euro je SMS (zzgl. SMS-Gebühr) gehen 4,83 Euro an UNICEF.

Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] [Cuis] Cuis

Edgar J. De Cleene



On 1/20/10 8:47 PM, "Torsten Bergmann" <[hidden email]> wrote:

> Hi Keith,
>
> BANG! (*Silence, nothing happens but Keith is thank god still alive*)
>
> Welcome back! :)
>
> Bye
> T.
>
> ----------------------------------------------------------------
> For those of you who dont understand the contents of the above
> mail: according to [1] Keith suggested: "If I email to squeak-dev
> again shoot me". Since he posted again there was no other option
> left than trying to shoot him ;)
>
> [1]
> http://lists.squeakfoundation.org/pipermail/squeak-dev/2009-December/142238.ht
> ml

Uno se cree que los mato el tiempo y la ausencia, pero su tren vendio boleto
de ida y vuelta

Edgar




Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] [Cuis] Cuis

keith1y
In reply to this post by Torsten Bergmann

> Hi Keith,
>
> BANG! (*Silence, nothing happens but Keith is thank god still alive*)
>
> Welcome back! :)
>
> Bye
> T.

Good point, can we move cuis discussions somewhere else. I don't want  
to have to interact with the board or Andreas.

Keith

Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] [Cuis] Cuis

garduino
With all respect Keith, sometimes seems that you hates all the rest of
the world, angry
with the Board, angry with Andreas, angry with the people not using
your projects.....maybe
you should change something also.

Cheers.
Germán.


2010/1/20 keith <[hidden email]>:

>
>> Hi Keith,
>>
>> BANG! (*Silence, nothing happens but Keith is thank god still alive*)
>>
>> Welcome back! :)
>>
>> Bye
>> T.
>
> Good point, can we move cuis discussions somewhere else. I don't want to
> have to interact with the board or Andreas.
>
> Keith
>
>

Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] [Cuis] Cuis

keith1y
With all respect Keith, sometimes seems that you hates all the rest of
the world, angry
with the Board, angry with Andreas, angry with the people not using
your projects.....maybe
you should change something also.

Cheers.
Germán.

I don't doubt it, and never have for a second. I don't give excuses for my behaviour.

You have all been very helpful to me, many healing experiences have poured from these recent events. However I am not fully healed yet and comments like this following one don't help.

From the board's report: 

"One of the issues regarding the release of Trunk development work is how to release an image that has had many packages removed and yet make those removals easily and obviously available for reinstallation to users who are new to Squeak. Andreas brought this issue up on the squeak-dev mailing in hopes that someone would become interested and come up with a solution"

Do you have any idea how insulting is this? 
Do you have any idea how insulting is this? 
Do you have any idea how insulting is this? 
Do you have any idea how insulting is this? 

We did this 2 years ago.

When this need was the starting point of the old 3.11 process, "That moving towards a kernel image as a goal needs tools to manage the removal and subsequent intallation of packages, and that an image with the ability to unload optional packages, is functionally equivalent to an image in which you can load optional packages", off the tools are there. The fact that Andreas hasn't thought about this before, simply points towards the idiocy of the lets hack the image for the sake of it approach. The board already recognised that this approach was not getting us anywhere when they approved my proposal, and the pharo team were proving it.

Not only that ALL the work is finished, and has been in use for more than 18 months. Installer was originally developed for this purpose in 2006, and subsequently Sake/Packages includes dependencies, and version control of package definitions. Again its not perfect, but the point remains, the "community" clamoured for a solution, and we developed it for the community, not for ourselves.

So... "someone who would become interested", I spent 3 years being interested on YOUR BEHALF, not even for my benefit, Installer scripts worked fine for me, I only build an image once a year or so, hand crafting it is just as productive, especially sine out of order loading feature of MC, means that dependencies are not that important.

So "someone who would become interested" ... you can shove it where the sun don't shine, and I will let you know when I eventually get healed.

regards

Keith


Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] [Cuis] Cuis

Igor Stasenko
2010/1/21 keith <[hidden email]>:

> With all respect Keith, sometimes seems that you hates all the rest of
> the world, angry
> with the Board, angry with Andreas, angry with the people not using
> your projects.....maybe
> you should change something also.
>
> Cheers.
> Germán.
>
> I don't doubt it, and never have for a second. I don't give excuses for my
> behaviour.
> You have all been very helpful to me, many healing experiences have poured
> from these recent events. However I am not fully healed yet and comments
> like this following one don't help.
> From the board's report:
> "One of the issues regarding the release of Trunk development work is how to
> release an image that has had many packages removed and yet make those
> removals easily and obviously available for reinstallation to users who are
> new to Squeak. Andreas brought this issue up on the squeak-dev mailing in
> hopes that someone would become interested and come up with a solution"
> Do you have any idea how insulting is this?
> Do you have any idea how insulting is this?
> Do you have any idea how insulting is this?
> Do you have any idea how insulting is this?
> We did this 2 years ago.
> When this need was the starting point of the old 3.11 process, "That moving
> towards a kernel image as a goal needs tools to manage the removal and
> subsequent intallation of packages, and that an image with the ability to
> unload optional packages, is functionally equivalent to an image in which
> you can load optional packages", off the tools are there. The fact that
> Andreas hasn't thought about this before, simply points towards the idiocy
> of the lets hack the image for the sake of it approach. The board already
> recognised that this approach was not getting us anywhere when they approved
> my proposal, and the pharo team were proving it.
> Not only that ALL the work is finished, and has been in use for more than 18
> months. Installer was originally developed for this purpose in 2006, and
> subsequently Sake/Packages includes dependencies, and version control of
> package definitions. Again its not perfect, but the point remains, the
> "community" clamoured for a solution, and we developed it for the community,
> not for ourselves.

Once you stop taking this as an insult, or personal attack, and
instead ask Andreas
why he thinks that none of available solutions is viable for us, and
then disscuss it in detail and
come to the potential solution, we'll not move ahead.
But you seems prefer walking in circles.


> So... "someone who would become interested", I spent 3 years being
> interested on YOUR BEHALF, not even for my benefit, Installer scripts worked
> fine for me, I only build an image once a year or so, hand crafting it is
> just as productive, especially sine out of order loading feature of MC,
> means that dependencies are not that important.


> So "someone who would become interested" ... you can shove it where the sun
> don't shine, and I will let you know when I eventually get healed.

I'll be waiting for this moment.

> regards
> Keith
>
>
>



--
Best regards,
Igor Stasenko AKA sig.

Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] [Cuis] Cuis

keith1y
Igor,

first let us define some terms.

The Squeak Community
===================
You and the board appear to define community as "anyone who pipes up on squeak-dev".

Now this definition has caused all manner of problems in the past especially with 3.9, and it resulted in the Pharo split, because the 3.9 team were constantly beaten up by people on squeak-dev. (One of those persons doing the beating happened to be Andreas). This definition of community also includes the average "lurker", who may download the image every now and then to see if it is interesting enough for them to not have to do java any more. 

The "team model" adopted and endorsed by the board for many years, whereby the teams had their discussions on a separate mailing list, specifically afforded a layer of protection from the wide ranging opinions of "lurkers". The flagrant violation of this simple social/political essential layer (which protected Ralph for more than 6 months), is what caused our problems in the first place, when Andreas went to squeak-dev with "this is the new process, I am a board member I can do what I like and I haven't even spoken to the release-team for two months". Andreas was elected on a mandate of helping along a release, and by implication to help along the release-team doing the release. That mandate did not include, using his position on the board to promote his own interests, and that of his company, over that of the communities interests, which I shall outline below.

My definition of "community" is, the body of individuals who have significant code bases built on squeak or squeak like base images, who are tasked with the problem of maintaining packages, for users who are using an ever increasing variety of tools and forks of squeak. My definition of "community" includes all pharo developers, pharo users, cuis developers, and cuis users, cobalt, croquet, etoys, gjallar the lot. For example, I consider Göran, who is tasked with the maintenance of Gjallar, to be the archetypal, community member, whose needs bear understanding and supporting.

So the "lurkers" who download an image occasionally, they pop up on squeak-dev and see "nothing appears to have changed in 4 years". These are the ones that panicked the board, people I had never heard of, and as far as I know had no commits to any current projects i.e. they aren't really part of the community.

The "community" who have actual code running, have seen that the range of tools they can use to make their job easier to move their code about, to test it and to deploy their code for different clients has steadily increased and improved over the past 4 years. Now we have package management systems, improved testing tools (TestReporter), improved MC, Logging, Rio, Sake, Bob, AtomicLoading, Installer, and LPF *** running in all base images.

The Vision
=========
The "lurkers" just want to see a new flashy image, that they might try a little project in one day.

The "community" want to see the board provide vision and to promote harmony both philosophically/ideologically, and with technical facilities; harmony among all squeak forks, even those who don't want to be harmonised (i.e. Pharo). The community members want to be able to publish a package (e.g. Magma) and have it be tested to work for everyone, whether they be pharo users or squeak users. The community wants to be able keep its large published, even deployed code bases up to date and bug free.

This means that "the community" don't want yet another fork to support, the communities enthusiasm for "yet more of the same" waned when pharo forked, and no one wanted to volunteer for 3.11 after 3.10. To be honest we were all too busy just keeping our own code bases running, to have to worry about another fork of squeak.

In anticipation of spoon aka squeak 5.0, those of us with big code bases are already anticipating a significant porting effort in the future, we don't want to have another one foisted on us every 6 months.

Where are we now
==============
The board has responsibility to the community, the whole community, and I don't just limit that to squeak users.

This means that the board needs to set and understand its terms of engagement, that it is here to provide an "older and wiser supervisory" service different branches of the community, to foster an inclusive "culture" around which interesting innovations and solutions can happen.

It is not here to promote the interests of Andreas, and his company in the following:

1. Producing yet another fork for its own sake, "fork de andreas", and calling it squeak  - is not in the interests of the community.
2. Undermining the existing common tools and the progress made, in the past 3 years by the community*** 
3. Orphaning existing code bases, not providing any fixes to us, or a migration path.
4. Ignoring users of other forks, and users trapped by inertia in past squeak releases.

My Personal Situation
=================
I was funded in part to work on squeak, because my vision aimed to provide tools as a means to harness the creativity of the whole community. This was considered a benefit to both myself and my clients, and my paying clients considered it a bonus to be able to contribute back to the OSS community, from which we also derive great benefits. The vision provided a suite of tools we could use to build and test our production images, and our code base would be able to track the latest developments from whatever source.

The board scuppered all of the above, and the reputation of squeak as a viable solution that is worth contributing back to (i.e and funding!!!!) has been irreparably damaged. So thanks the incompetent fly by the seat of their pants flailings of the board, I loose a small but significant income stream that took several years to build up.

We also believed that modelling an extreme programming approach to testing and releasing, with a goal of bi-monthly releases, would be of value to the community and our own projects. (we would be on squeak 3.14-alpha by now, if Andreas had put his considerable skills to contributing to the release team's work, rather than replacing it)

The fact that the actions of the board, have allowed an individual to take over, without due process, for his own benefit, following the agenda of his company, while at the same time, causing problems for others, is an issue of serious concern that the board should take seriously, and is not. It is the board that is going around in circles, refusing to take the "terms of engagement" request seriously.

I have no use for Multimedia tools in squeak or half of Andreas' ideas, I don't even know or care what they are, and I doubt if Göran gjallar (a project management tool using seaside and magma) has much use for them either. These are loadable things, that should be provided in external packages (again for all base images), Andreas should go off and become a contributing member of the community first before presuming to run it. How many loadable packages are on squeaksource provided and maintained by Andreas, if the answer is none, then he is not really a contributing member of the community, he is merely an informed user, aka lurker. Why would his opinion on a package management solution for the community to use be relevant, if he doesn't have any packages? Andreas develops using a "monolithic image under his control", so effectively do the Pharo team members, yet we, the community had a professed goal of moving towards a kernel image with load-able packages.

I myself made a specific decision NOT to run for the board (though I was asked), because I didn't see any purpose for a board member to be both on the board and on the release team, after all the board had endorsed the release team and therefore had a DUTY to uphold it as a decision making entity in its own right. The release-team has the authority to decide what is in the release, not the board, since that is what the board appointed the release team to do.

Andreas however joined the board specifically as a ploy to mussel through his own agenda which is to release a new image. No mention of the cultural context in which we are all operating, and those of us who are "the community" of package developers, are offered nothing from this new deal.

The core image, as a practical artefact, is the least important part of providing a service to clients, having it change underneath you however, is a big problem. The important part is the code you develop, maintaining it and testing it.

Although "Fork de Andreas", has not adopted LPF, Sake/Packages, Installer, this is not a problem as long as it doesn't break them. However Andreas has actually undermined and broken the use of MANTIS as THE tool for documenting bugs, and providing fixes for us legacy users. Because trunk is a moving target, people are fixing bugs against the moving target, not against releases. This is a change of policy which is not in the interests of the community, and hasn't even been discussed. Bug fixes are not maintained for existing users any more, nor can you provide them to existing users any more. Sake/Packages can include a bug fix with a package if it is needed. BUT that bug fix has to be published relative to a fixed point, i.e. a release. Throwing fixes willy-nilly into trunk, doesn't help anyone. We had a golden age in which you could load any bug fix you needed direct form Mantis, well now no one is providing fixes there any more. You are forced to use trunk to avail yourself of important fixes, but trunk is a moving target and is pre-release.

The Boards Job
============
The board's job is to consider the following points, and to provide a visionary direction as a solution to the community: 

1) My own code base is now orphaned and there is no suitable base image upon which to build, beyond 3.10. I was going to use Pharo, but I find OmniBrowser unusable, and the image is hugely bloated. 
The trunk based 3.11 will not come tested, it will not come with package management, I will have to port all my own tools, and my own code, I will have to manually regression test seaside, magritte, pier, Rio, Beach etc, and some 60 packages, against the release. Andreas will not do that for me (whereas Bob would have done). The Bob/LPF process enabled me to apply API fixes to legacy images, and so enables a smooth migration path to any new releases.

2) The pain of maintaining my existing 14 or so packages for all forks is getting progressively harder not easier, to the extent that the inability of getting anyone to work together at all is making continued community based development prohibitive.

3) The board's ability to make any decisions whatsoever has been undermined, since it cannot be trusted to support its own decisions, or even to use due-process for anything it does. Thus the board has become THE loose cannon, that it was created to stabilise through the application of diverse elected wisdom. The process of election, which was intended to enable the board to be a source of wisdom, and to be representative of the communities interests, has become the potential source of unpredictable insensitive and partisan disruption.

4) If the board did not exist, or remained as a low key background entity looking after servers, then the community would have a chance to work things out in a process of mutual collaboration. The heavy handed actions of the board, now ensure that for groups sharing common interests, forking, in order to get away form the potential disruption that the board may cause, is the only viable option. This is the opposite of what the community wants.

5) The facilities of the community, can be removed, or re-assigned without due process. Thus scuppering all work done by users of those facilities. I spent a lot of effort building tools for mantis, that would enable mantis to be used as part of the process, effectively. But now Mantis and mantis harvesters have been reassigned to a different purpose. For example, I cant deliver my 3.11 even if I wanted to, because it was bound to and intended to showcase a process and that process included the way mantis was used to collate, query, and manage bugs, in a professional manner for the foreseeable future. Andreas replaced the process with his "New process for contributing to squeak", in ONE email, with NO discussion.

6) Does the board even have a constitution? This email includes the announcement that my teddy bear Cyril is running for the board, in the upcoming elections.

So in conclusion, until the Board, defines what it means by the community, and what it means to be itself, I don't think the community is really able to function. 

I have repeatedly asked the board to produce a simple little thing such as a "Terms of Reference", 6 months of complete in-action on this topic, leads me to feel that I would be within my rights to call for resignations.

I am not going in circles Igor, I stated my position clearly at the beginning and I haven't changed. "I will not contribute any further to squeak, until the board has some form of terms of reference, which protects anyone from going through what I went through in the future."

regards

Keith


 











Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] [Cuis] Cuis

Igor Stasenko
2010/1/21 keith <[hidden email]>:

> Igor,
> first let us define some terms.
> The Squeak Community
> ===================
> You and the board appear to define community as "anyone who pipes up on
> squeak-dev".
> Now this definition has caused all manner of problems in the past especially
> with 3.9, and it resulted in the Pharo split, because the 3.9 team were
> constantly beaten up by people on squeak-dev. (One of those persons doing
> the beating happened to be Andreas). This definition of community also
> includes the average "lurker", who may download the image every now and then
> to see if it is interesting enough for them to not have to do java any
> more.

And if there's nothing new to download, in , say over a year, he
decides to keep doing java.


> The "team model" adopted and endorsed by the board for many years, whereby
> the teams had their discussions on a separate mailing list, specifically
> afforded a layer of protection from the wide ranging opinions of "lurkers".
> The flagrant violation of this simple social/political essential layer
> (which protected Ralph for more than 6 months), is what caused our problems
> in the first place, when Andreas went to squeak-dev with "this is the new
> process, I am a board member I can do what I like and I haven't even spoken
> to the release-team for two months". Andreas was elected on a mandate of
> helping along a release, and by implication to help along the release-team
> doing the release. That mandate did not include, using his position on the
> board to promote his own interests, and that of his company, over that of
> the communities interests, which I shall outline below.

I don't even want to comment your allusions concerning Andreas
'conspiracy' and his 'company'.
Star Wars and Emperor Palpatine is a fiction, not reality, keep
reminding this to yourself.
I just want to say: we're all having agendas, which crossing each
other, and which is a basement
of our common interest - use, develop and promote squeak & techs based on it.

The development of Hydra VM, inclusion of full closure support into
Squeak and Pharo made possible because
of this company good will to share these artifacts with OSS community.
And now you trying to sell us that these facts is indication of far
reaching plans to conquer the world?
Beware Luke, dark side of power is strong!


> My definition of "community" is, the body of individuals who have
> significant code bases built on squeak or squeak like base images, who are
> tasked with the problem of maintaining packages, for users who are using an
> ever increasing variety of tools and forks of squeak. My definition of
> "community" includes all pharo developers, pharo users, cuis developers, and
> cuis users, cobalt, croquet, etoys, gjallar the lot. For example, I consider
> Göran, who is tasked with the maintenance of Gjallar, to be the archetypal,
> community member, whose needs bear understanding and supporting.
> So the "lurkers" who download an image occasionally, they pop up on
> squeak-dev and see "nothing appears to have changed in 4 years". These are
> the ones that panicked the board, people I had never heard of, and as far as
> I know had no commits to any current projects i.e. they aren't really part
> of the community.
> The "community" who have actual code running, have seen that the range of
> tools they can use to make their job easier to move their code about, to
> test it and to deploy their code for different clients has steadily
> increased and improved over the past 4 years. Now we have package management
> systems, improved testing tools (TestReporter), improved MC, Logging, Rio,
> Sake, Bob, AtomicLoading, Installer, and LPF *** running in all base images.
> The Vision
> =========
> The "lurkers" just want to see a new flashy image, that they might try a
> little project in one day.

All 'grand' projects growing out from small ones. Which makes little
ones as much as valuable
as any of your 'grand' project. I'd prefer seeing 10 little projects
popping out each month, than
1 grand project popping out once in 2 years.

> The "community" want to see the board provide vision and to promote harmony
> both philosophically/ideologically, and with technical facilities; harmony
> among all squeak forks, even those who don't want to be harmonised (i.e.
> Pharo). The community members want to be able to publish a package (e.g.
> Magma) and have it be tested to work for everyone, whether they be pharo
> users or squeak users. The community wants to be able keep its large
> published, even deployed code bases up to date and bug free.
> This means that "the community" don't want yet another fork to support, the
> communities enthusiasm for "yet more of the same" waned when pharo forked,
> and no one wanted to volunteer for 3.11 after 3.10. To be honest we were all
> too busy just keeping our own code bases running, to have to worry about
> another fork of squeak.
> In anticipation of spoon aka squeak 5.0, those of us with big code bases are
> already anticipating a significant porting effort in the future, we don't
> want to have another one foisted on us every 6 months.
> Where are we now
> ==============
> The board has responsibility to the community, the whole community, and I
> don't just limit that to squeak users.
> This means that the board needs to set and understand its terms of
> engagement, that it is here to provide an "older and wiser supervisory"
> service different branches of the community, to foster an inclusive
> "culture" around which interesting innovations and solutions can happen.
> It is not here to promote the interests of Andreas, and his company in the
> following:
> 1. Producing yet another fork for its own sake, "fork de andreas", and
> calling it squeak  - is not in the interests of the community.
> 2. Undermining the existing common tools and the progress made, in the past
> 3 years by the community***
> 3. Orphaning existing code bases, not providing any fixes to us, or a
> migration path.
> 4. Ignoring users of other forks, and users trapped by inertia in past
> squeak releases.

Star Wars, Episode V.

[snip]

> We had
> a golden age in which you could load any bug fix you needed direct form
> Mantis, well now no one is providing fixes there any more. You are forced to
> use trunk to avail yourself of important fixes, but trunk is a moving target
> and is pre-release.

Write tool to leverage the trunk activity then. Stop whining about
losing control (via Mantis).
People like a new and easy way to contribute, otherwise nobody would
put any commits in trunk.
Is this something that hard to understand?

> The Boards Job
> ============
-----
"I will not contribute any further to
> squeak, until the board has some form of terms of reference, which protects
> anyone from going through what I went through in the future."

Feel free to raise this topic again , before eyes of newly elected board.
I will not run for the next year anyways.

> regards
> Keith
>
>



--
Best regards,
Igor Stasenko AKA sig.

Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] [Cuis] Cuis

Michael Haupt-3
In reply to this post by keith1y
Hi Keith,

wrapping up:

You have a definition of "community" (package maintainers on  
SqueakSource) that is as controversial as the one you criticise.

You have some very concrete ideas (visions) about Squeak, the way the  
board and other entities should work.

In my opinion, you even have a point or two.

And in spite of all the above, you refuse to run for the board;  
instead you insist on continuing to blame people from a safe distance  
without showing the decency of being ready to take responsibility.

In one (final, as far as I'm concerned) word: pathetic.

Sorry.

Best,

Michael :-(

Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] [Cuis] Cuis

Josh Gargus
In reply to this post by keith1y

On Jan 21, 2010, at 10:00 AM, keith wrote:

The Vision
=========
The "lurkers" just want to see a new flashy image, that they might try a little project in one day.

The "community" want to see the board provide vision and to promote harmony both philosophically/ideologically, and with technical facilities; harmony among all squeak forks, even those who don't want to be harmonised (i.e. Pharo). The community members want to be able to publish a package (e.g. Magma) and have it be tested to work for everyone, whether they be pharo users or squeak users. The community wants to be able keep its large published, even deployed code bases up to date and bug free.



The "community" doesn't want only one thing, and different people in it want different things to different degrees.  I don't dispute that what you have described above is desirable, in principle, to the vast majority of community members.  However, it is fundamentally at odds with other goals that various community members hold dear.  A balance must be struck.

Here's a very specific example.  I would like to see more integrated support for concurrent programming in the Squeak kernel.  Toward that end, I've added a trivial implementation of "promises" to the trunk (hopefully, I'll take it further relatively soon... one of the things I've done in the interim was to re-read Mark Miller's dissertation).  The current changes are intentionally non-invasive.  However, it is possible to envision widespread adoption of such programming constructs throughout the image.  Any packages that use such constructs would rely on the support in the Kernel package.  

How do you propose to support new programming paradigms that push us beyond Smalltalk-80, and yet have every package be loadable into every release of every fork?  It's fine if your answer is that this conflicts fundamentally with your vision: compatibility is king.  Just be aware that your vision is no more synonymous with the "community's" than mine or Andreas's.

It is impossible to deny that since the inception of the new development process, there has been a steady flow of high-quality contributions integrated into the trunk image.  Most of these haven't been from Andreas, although he's probably the most productive single member (that's just how he is).  It is unfortunate that this progress has been at the cost of some cross-fork compatibility.  However, you have to admit that there is something about the new process that is enabling Nicholas, Levente and many others to contribute in a way that they weren't before.  Even if it wasn't a problem with Sake/Bob per se (i.e. there were other external factors at play, like uncertainty about the 3.10/3.11/4.0 roadmaps), what's done is done; things are moving again, and that's good.  

In text trimmed below, you refer to a "golden age" of Squeak development under your guidance.  However, my impression is that the community has been greatly enthused by the progress that has been made since the switch.  Personally, I wouldn't go so far as to say we have a golden age today, but it's certainly better than a year ago.  As long as you propose that we stop using a process that is clearly "working" (for some definition of "working" compatible with what I've written above) and switch to one that is at best unproven, then it is natural and proper that your proposal will meet with resistance.

I wholeheartedly wish for the rapid healing of your hurts; your position within the community as the "extreme" advocate of cross-fork compatibility is potentially very valuable if we can achieve some of your goals without sacrificing the benefits of the new process (and, of course, I wish it simply for your own sake).  It's a new decade!  Let's see if we can find some common ground.  I do believe that it exists.

Cheers,
Josh





Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] [Cuis] Cuis

CdAB63
Let's not feed trolls.

Cuis should be discussed in cuis lists.
Pharo should be discussed in pharo lists.
Personal troubles for dealing with lost (financial) support should be
discussed somewhere else.
Personal troubles with individuals should be set up using private e-mail
addresses.
Certain level of language shouldn't be used in tech lists.

Since cuis & pharo parted ways with squeak-trunk, ethics require that
anything not involving shared things should be discussed at proper lists.

Also, not being civilized (eg. not using proper language & adequate
levels of civility) won't help employability & funding raising.




signature.asc (269 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] [Cuis] Cuis

keith1y
In reply to this post by Igor Stasenko

> All 'grand' projects growing out from small ones. Which makes little
> ones as much as valuable
> as any of your 'grand' project. I'd prefer seeing 10 little projects
> popping out each month, than
> 1 grand project popping out once in 2 years.

Igor,

I think you need to think about what you are saying more carefully,  
you are arguing against yourself here.

The trunk process is a "grand project" which hasn't produced anything  
of any use for 6 months. It signs up the community for an ongoing wait  
of 12-18 months per release. It ties you in to the "grand project"  
ethos which we all said we didn't want.

My process produced a stream of useful projects popping up along the  
way at regular intervals, that is what you are saying you want isnt it?

We set the goal "We don't want an image, we want a kernel, that you  
can build distributions from." So what do you and the board do? Yep  
the opposite! You build a monolithic image using a process that can  
only build a monolithic image.

Furthermore the process I produced (and finished) with Bob, was  
designed to produce monthly or bi-monthly releases, with all fixes  
auto documented. Which is also what we wanted. The goal is to "release  
early and often", so what does the board do, yep exactly the opposite.  
A new process that will take a year to produce anything, and nothing  
will be auto-documented.

So you say you want something every month or so, but defend to the  
hilt the process which will NOT deliver it.

You had a release of Bob, in an image, loaded for you to play with in  
February (did you download it?), you had a release of Sake/Packages 18  
months ago (you told me you didn't use that either). The problem is  
that you all seem to say you want small projects popping up regularly,  
but when they pop up you dont use them. Furthermore you seem to be  
working arduously to make those small projects, which apparently you  
desperately want, irrelevant, and obsolete, when they are still  
useful, and in use today.

We want squeak to go forwards not backwards.

There was no grand project, to produce the 3.11, there was a process.  
In case you don't know, a process is a way of thinking about the  
problem, and applying yourself to achieve a defined goal. The board  
approved this goal to provide this process. The process was being  
used, and was working. It had not quite produced a result yet, but I  
was making videos showing THE PROCESS which was the deliverable of the  
3.11 effort was not an image, but the process that would enable to  
community to build future images, and that is what I was documenting  
and making videos of.

The actual deliverable of 3.11 could have been produced any time, the  
script was written 18 months ago. 60% of it was in LPF already, and we  
had plenty of users, and a downloadable image. All you had to do was  
run the script manually. Ken Brown had a go, he was convinced. But the  
deliverable was not the image it was the process, that is what the  
board approved, so having a go at me for not producing an image, is  
moving the goal posts.

The purpose of this process was to support extreme programming  
practices for all users of squeak, but showcased in the release of  
3.11. Now we are locked in to a "wait 18 months for a release process  
all over again".

I never advocated a grand release process, that's what I am  
complaining about, the dog returning to its vomit. We already decided  
that this wasn't the way forward.

Your choice to mock me, master Yoda, is hardly commensurate for a  
positive way forward.

My point I still don't think you are getting, is that while squeak is  
running on an 18 month release cycle producing a monolithic image,  
which only serves the vision of the person who built it, and processes  
are locked in to that way of thinking, it is already irrelevant, hence  
my search for something else.

Within the Smalltalk community which invented extreme programming, we  
are basically a bit of a laughing stock, since we cannot produce a  
release in 20 minutes.

Keith

Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] [Cuis] Cuis

Eliot Miranda-2


On Thu, Jan 21, 2010 at 12:21 PM, keith <[hidden email]> wrote:

All 'grand' projects growing out from small ones. Which makes little
ones as much as valuable
as any of your 'grand' project. I'd prefer seeing 10 little projects
popping out each month, than
1 grand project popping out once in 2 years.

Igor,

I think you need to think about what you are saying more carefully, you are arguing against yourself here.

The trunk process is a "grand project" which hasn't produced anything of any use for 6 months. It signs up the community for an ongoing wait of 12-18 months per release. It ties you in to the "grand project" ethos which we all said we didn't want.

Nonsense.  In the past 6 months, just to take three that come to mind, we have closures, native fonts and unloadable smaller traits.  There are lots of other things also; go look at the recent changes list.  Trunk is actually progressing very nicely.

You might try contributing code rather than whining at length.  It's more fun for everyone.  Better for the community.


My process produced a stream of useful projects popping up along the way at regular intervals, that is what you are saying you want isnt it?

We set the goal "We don't want an image, we want a kernel, that you can build distributions from." So what do you and the board do? Yep the opposite! You build a monolithic image using a process that can only build a monolithic image.

Furthermore the process I produced (and finished) with Bob, was designed to produce monthly or bi-monthly releases, with all fixes auto documented. Which is also what we wanted. The goal is to "release early and often", so what does the board do, yep exactly the opposite. A new process that will take a year to produce anything, and nothing will be auto-documented.

So you say you want something every month or so, but defend to the hilt the process which will NOT deliver it.

You had a release of Bob, in an image, loaded for you to play with in February (did you download it?), you had a release of Sake/Packages 18 months ago (you told me you didn't use that either). The problem is that you all seem to say you want small projects popping up regularly, but when they pop up you dont use them. Furthermore you seem to be working arduously to make those small projects, which apparently you desperately want, irrelevant, and obsolete, when they are still useful, and in use today.

We want squeak to go forwards not backwards.

There was no grand project, to produce the 3.11, there was a process. In case you don't know, a process is a way of thinking about the problem, and applying yourself to achieve a defined goal. The board approved this goal to provide this process. The process was being used, and was working. It had not quite produced a result yet, but I was making videos showing THE PROCESS which was the deliverable of the 3.11 effort was not an image, but the process that would enable to community to build future images, and that is what I was documenting and making videos of.

The actual deliverable of 3.11 could have been produced any time, the script was written 18 months ago. 60% of it was in LPF already, and we had plenty of users, and a downloadable image. All you had to do was run the script manually. Ken Brown had a go, he was convinced. But the deliverable was not the image it was the process, that is what the board approved, so having a go at me for not producing an image, is moving the goal posts.

The purpose of this process was to support extreme programming practices for all users of squeak, but showcased in the release of 3.11. Now we are locked in to a "wait 18 months for a release process all over again".

I never advocated a grand release process, that's what I am complaining about, the dog returning to its vomit. We already decided that this wasn't the way forward.

Your choice to mock me, master Yoda, is hardly commensurate for a positive way forward.

My point I still don't think you are getting, is that while squeak is running on an 18 month release cycle producing a monolithic image, which only serves the vision of the person who built it, and processes are locked in to that way of thinking, it is already irrelevant, hence my search for something else.

Within the Smalltalk community which invented extreme programming, we are basically a bit of a laughing stock, since we cannot produce a release in 20 minutes.

Keith




Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] [Cuis] Cuis

keith1y
In reply to this post by Michael Haupt-3
Hi Keith,

wrapping up:

You have a definition of "community" (package maintainers on SqueakSource) that is as controversial as the one you criticise.

You have some very concrete ideas (visions) about Squeak, the way the board and other entities should work.

In my opinion, you even have a point or two.

And in spite of all the above, you refuse to run for the board; instead you insist on continuing to blame people from a safe distance without showing the decency of being ready to take responsibility.

In one (final, as far as I'm concerned) word: pathetic.

Sorry.

Best,

Michael :-(

Michael,

what purpose would running for the board do? And secondly you don't know what you are talking about.

Firstly, there have been no elections since this incident occurred, so your point is moot.

Secondly I would simply be accused of the same conflict of interest that I am accusing Andreas of. Release teams are supposed to work on the release not on the board.  

Thirdly, the board is a political entity, it always has been, and it basically shouldn't do anything, it never has done anything in the past. I would only run for the board in order to stop the board form hassling people and causing trouble.

Fourthly, as a result of the actions of the board, and other things, I don't have time.

And Fifthly, you don't ask disabled people to climb stairs. In fact it is illegal, not to put processes in place that do not enable disabled people to fully participate in the work place etc. I am not planning to run for the board because I am not emotionally up to it.

Of course if you are the kind of person, that forces people with phobias to touch tarantulas, I would call you pathetic to have that kind of expectation.

Keith



Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] [Cuis] Cuis

keith1y
In reply to this post by Eliot Miranda-2
>
>
> Nonsense.  In the past 6 months, just to take three that come to  
> mind, we have closures, native fonts and unloadable smaller traits.  
> There are lots of other things also; go look at the recent changes  
> list.  Trunk is actually progressing very nicely.
>
> You might try contributing code rather than whining at length.  It's  
> more fun for everyone.  Better for the community

Where are these things, are they in a released image?

If you had used the bob process they would have been in 3.11, 3.12,  
and 3.13 released and tested against all 700 loadable packages.

Keith

Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] [Cuis] Cuis

keith1y
 Nonsense.  In the past 6 months, just to take three that come to mind, we have closures, native fonts and unloadable smaller traits.  There are lots of other things also; go look at the recent changes list.  Trunk is actually progressing very nicely.

You might try contributing code rather than whining at length.  It's more fun for everyone.  Better for the community

Where are these things, are they in a released image?

If you had used the bob process they would have been in 3.11, 3.12, and 3.13 released and tested against all 700 loadable packages.

There would also be a minimal, seaside, pier, seaside-magma-pier-beach, developer and "fun" one click images amongst others.

Keith



Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] [Cuis] Cuis

Igor Stasenko
2010/1/21 keith <[hidden email]>:

>  Nonsense.  In the past 6 months, just to take three that come to mind, we
> have closures, native fonts and unloadable smaller traits.  There are lots
> of other things also; go look at the recent changes list.  Trunk is actually
> progressing very nicely.
>
> You might try contributing code rather than whining at length.  It's more
> fun for everyone.  Better for the community
>
> Where are these things, are they in a released image?
>
> If you had used the bob process they would have been in 3.11, 3.12, and 3.13
> released and tested against all 700 loadable packages.
>
> There would also be a minimal, seaside, pier, seaside-magma-pier-beach,
> developer and "fun" one click images amongst others.

The key word here is 'would'.
Get back, when you can say 'is', otherwise don't expect someone
_would_ buy this.

> Keith
>
>
>
>



--
Best regards,
Igor Stasenko AKA sig.

Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] [Cuis] Cuis

Josh Gargus
In reply to this post by keith1y

On Jan 21, 2010, at 12:21 PM, keith wrote:

>
> We set the goal "We don't want an image, we want a kernel, that you can build distributions from." So what do you and the board do? Yep the opposite! You build a monolithic image using a process that can only build a monolithic image.

Off the top of my head, what about the fact that Traits are now unloadable/reloadable?

Josh
Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] [Cuis] Cuis

keith1y
In reply to this post by keith1y
 Nonsense.  In the past 6 months, just to take three that come to mind, we have closures, native fonts and unloadable smaller traits.  There are lots of other things also; go look at the recent changes list.  Trunk is actually progressing very nicely.

You might try contributing code rather than whining at length.  It's more fun for everyone.  Better for the community

I don't think I can contribute code.

For example, my contributions to Monticello. In case you don't realise it. Monticello cannot load Monticello, so contributing it to trunk will not work, that is why we developed LPF loading process in the first place. But of course, trunk didn't build on 3.10-build did it, so the process chosen for trunk prevents me contributing towards MC or PackageInfo, two areas that have massive changes (now in the bin)

My contributions for a Package manager are loadable, [ Installer install: 'Packages'. ] So they don't have any place in the trunk scheme either.

The trunk process is allowing people that would normally contribute via a changeset to contribute, (well just give me the changesets, then I can use them) and it is enabling people who would normally write a loadable package to contribute, (so just publish the loadable package).

However, fundamental changes to Monticello, and PackageInfo, you can forget it. Goodness knows how you change compiler stuff.

Watch this space, I will submit code for Cuis, because that does have a process I can contribute to, i.e. Juan has not defined process for contributions that prevents contributions.

I always regarded your points as respectable and sensible, so I hope you understand my opinion that the trunk process closed me out. The very ethos of the previous model was to harness all possible contributions, not to prevent people from making them. However I am sure I can rely on you to correct me if I am wrong.

regards

Keith

 


Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] [Cuis] Cuis

Michael Haupt-3
In reply to this post by keith1y
Keith,

I know I wrote 'final', so here's me being inconsequent. I've got  
company.

Am 21.01.2010 um 21:35 schrieb keith <[hidden email]>:
> And secondly you don't know what you are talking about.

Ach, gerroff. Simpleton argument. You can do better.

> Firstly, there have been no elections since this incident occurred,  
> so your point is moot.

There's an upcoming election. Go for it if you really want things to  
change.

> Secondly I would simply be accused of the same conflict of interest  
> that I am accusing Andreas of. ...

Just give it a try.

> ... I would only run for the board in order to stop the board form  
> hassling people and causing trouble.

Just give it a try.

> Fourthly, as a result of the actions of the board, and other things,  
> I don't have time.

Man, you have the time to write all those long laments. So what about  
doing something sensible instead?

> ... Of course if you are the kind of person, that forces people with  
> phobias to touch tarantulas, I would call you pathetic to have that  
> kind of expectation.

Rest assured, I am not.

And now this is, for real, my final word. Whining does really not make  
much of an impression. I have repeatedly told you that I agree with  
some of your points. I'm not all negative, you see. It is highly  
unfortunate that you keep accusing and blaming people without showing  
an ever so slight glimpse of reason or common sense. It's all tunnel  
vision, and that's a darn pity, if you ask me. Of course, you don't.

I will let you have the last word; you seem to be in dire need of that.

Out,

Michael :-(

1234 ... 9