3.9 feature voting round

I still have that old "voting" software I once wrote as a
proof-of-concept of what we could do with SqP's web of trust. I
thought it'd be neat to do a round of voting about what should land in
v3.9, now that the 3.9a team is considering going to beta.

The team also thought it'd be need to get some structured input, so I
cleaned up the database and it's now available for voting.

The idea is simple:
- Go to http://de-1.tric.nl/seaside/sqp/list
- Login with your Squeak People account
- Create an issue or vote on issues.
You will see the number of votes you have constantly updated. Note: I
haven't yet added the possibility to delete issues, and if you add an
issue, you have to allocate at least one vote to it. So think before
creating issues! In fact, you can't even edit an issue - which is
logical, otherwise you could rig the voting (editing an issue should
logically imply losing all votes that were on it before the issue).

The SqP angle is that the higher your ranking, the more votes you get
- Observers get none, Apprentice gets 5, Journeyer 10, Master 15. This
is an entirely unfounded distribution and I'm not going to debate it
here ;-).

Note: this voting round serves two purposes:
- Advise, I repeat: advise, the 3.9a team. They're entirely free to
completely ignore the outcome of this stuff, although if many many
many people vote for something and they don't do it, it'd be nice if
they'd give a reason;
- Check whether this sort of utility is useful.

The software can be found in the SqueakPeople repository on SqueakSource.

Have fun!

Cees

Cees De Groot wrote:
....

> - Advise, I repeat: advise, the 3.9a team. They're entirely free to
> completely ignore the outcome of this stuff, although if many many
> many people vote for something and they don't do it, it'd be nice if
> they'd give a reason;

A few people play leaders and they feel free to completely ignore the
complete community. You described exactly the sad state of Squeak today.

Regards,
Martin

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

>> - Advise, I repeat: advise, the 3.9a team. They're entirely free to
>> completely ignore the outcome of this stuff, although if many many
>> many people vote for something and they don't do it, it'd be nice if
>> they'd give a reason;

> A few people play leaders and they feel free to completely ignore the
> complete community. You described exactly the sad state of Squeak today.

What are you talking about ? The developers take great care of
correcting issues in mantis, put each new images to ftp so that
everybody can test and command ; They also communicate on what they do
and on what they focus on. Everybody can post new things, patches... and
they will always have a look at it.

So what do you want ? If you do not agree with the process, just be
clear and describe your point of view. They read this list.

- --
Damien Cassou
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDzpjq3hhx1vOEX5sRAklQAJ4tun1e8pvvSnArJx+CoD76RuKKsgCePMH3
M583PIBZ2FLUbt4d+NeDmM4=
=q4jf
-----END PGP SIGNATURE-----

Internal Error

Error: Failed to obtain a free session


SqpConnectionPool(ConnectionPool)>>getSession
SqpSeasideSession(KilaueaSeasideSession)>>magmaSession
[] in SqpSeasideSession(KilaueaSeasideSession)
 >>withEscapeContinuation: {[self connectionPoolClass currentSession:  
self magmaSession. ^ self magmaSe...]}
BlockContext>>on:do:
BlockContext>>valueWithBindingsContext:
BlockContext>>valueWithBindings:
BindingsAccessor>>clamp:
SqpSeasideSession(KilaueaSeasideSession)>>withEscapeContinuation:
SqpSeasideSession(WASession)>>responseForRequest:
[] in SqpSeasideSession(WASession)>>incomingRequest: {[self  
responseForRequest: aRequest]}
BlockContext>>on:do:
[] in WAProcessMonitor>>critical:ifError: {[value := aBlock on: Error  
do: errorBlock]}
BlockContext>>ensure:
[] in WAProcessMonitor>>critical:ifError: {[[value := aBlock on:  
Error do: errorBlock] ensure: [responseSem signal]]}
[] in BlockContext>>newProcess {[self value. Processor terminateActive]}
BlockContext>>on:do:
BlockContext>>valueWithBindingsContext:
BlockContext>>valueWithBindings:

Alexandre

Am Jan 18, 2006 um 6:19 PM schrieb Cees De Groot:

--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.iam.unibe.ch/~bergel
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> - Go to http://de-1.tric.nl/seaside/sqp/list

This website doesn't work :

"Internal Error
Error: Failed to obtain a free session"

- --
Damien Cassou
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDzpmA3hhx1vOEX5sRAoqaAKCZ+8TsSLjeIECjnh1QdJBd/sL5+wCgjRcl
VwxY1KNGrL79kzS2nItcpJ4=
=4Ak1
-----END PGP SIGNATURE-----

On Jan 18, 2006, at 1:26 PM, Martin Wirblat wrote:

Do you have specific instances where the community has been ignored?  
My feeling is that concerns raised on the list are seriously  
considered.  Of course, not all of them can be addressed; the people  
driving the 3.9 effort are very busy.  At least progress is being  
made in some direction, even if it is not exactly the direction that  
some factions within the community would like.  Overall, I have the  
feeling that 3.9 is moving in a direction that reflects the will of  
the community.

Josh

> Regards,
> Martin
>

Hmm... apparently I need to check on that new session pool handling I added :-)

On 1/18/06, Damien Cassou <[hidden email]> wrote:

Ok, I upped the pool size to 250. Hopefully that's enough for the time being :)

(I release sessions in a finalizer for WASession, but WASession's
aren't aggresively released, so 25 sessions was probably not enough
for that strategy...)

 Internal Error
MagmaUserError: Must connect before you can commit.

MagmaSession>>commit
MagmaSession>>commit:
[] in SqpSeasideSession(KilaueaSeasideSession)>>withEscapeContinuation:
{[self connectionPoolClass currentSession: self magmaSession. ^ self
magmaSe...]}
BlockContext>>on:do:
BlockContext>>valueWithBindingsContext:
BlockContext>>valueWithBindings:
BindingsAccessor>>clamp:
SqpSeasideSession(KilaueaSeasideSession)>>withEscapeContinuation:
SqpSeasideSession(WASession)>>responseForRequest:
[] in SqpSeasideSession(WASession)>>incomingRequest: {[self
responseForRequest: aRequest]}
BlockContext>>on:do:
[] in WAProcessMonitor>>critical:ifError: {[value := aBlock on: Error
do: errorBlock]}
BlockContext>>ensure:
[] in WAProcessMonitor>>critical:ifError: {[[value := aBlock on: Error
do: errorBlock] ensure: [responseSem signal]]}
[] in BlockContext>>newProcess {[self value. Processor terminateActive]}
BlockContext>>on:do:
BlockContext>>valueWithBindingsContext:
BlockContext>>valueWithBindings:
2006/1/18, Cees De Groot <[hidden email]>:
> Ok, I upped the pool size to 250. Hopefully that's enough for the time being :)
>
> (I release sessions in a finalizer for WASession, but WASession's
> aren't aggresively released, so 25 sessions was probably not enough
> for that strategy...)
>
>


--
Vaidotas Didžbalis

Gosh... sorry for exercising everyone's patience so much - I just
changed this code from OmniBase to Magma, but did testing before
unleashing it onto the world...  I'll check what's wrong.

On 1/18/06, Vaidotas Didžbalis <[hidden email]> wrote:
>  Internal Error
> MagmaUserError: Must connect before you can commit.
>
> MagmaSession>>commit
> MagmaSession>>commit:
> [] in SqpSeasideSession(KilaueaSeasideSession)>>withEscapeContinuation:
> {[self connectionPoolClass currentSession: self magmaSession. ^ self
> magmaSe...]}

I guess some fluff was left in the connection pool - it growed without
bounds because I had the wrong target for finalization.. Reset the
pool, hope this isn't putting too many people off...

On 1/18/06, Cees De Groot <[hidden email]> wrote:

On Wed, Jan 18, 2006 at 08:26:26PM +0100, Martin Wirblat wrote:
That's not fair. Cees is going to a good deal of trouble to *get*
our input, and he is setting clear expectations so that we know it
will be treated is *input*. He is also making it clear that he is
not arbitrarily changing the rules or the process; he's just trying
to make it work well by getting more input and advice from all of us.
This is a good thing.

Dave

On Wed, 18 Jan 2006 17:44:38 -0800, David T. Lewis <[hidden email]>  
wrote:

>> A few people play leaders and they feel free to completely ignore the
>> complete community. You described exactly the sad state of Squeak today.
>
> That's not fair.

No, not in the least. The guys who are doing the work are WAY more  
receptive to feedback than they have to be. And if someone doesn't like  
it, they're free to go their own way.

Thanks
Because we really try our best.
But as usual talking is easy.

And this is always fun to see that we do not see enh or fix of the  
same people been always negative.

>> - Advise, I repeat: advise, the 3.9a team. They're entirely free to
>> completely ignore the outcome of this stuff, although if many many
>> many people vote for something and they don't do it, it'd be nice if
>> they'd give a reason;
>
> A few people play leaders and they feel free to completely ignore  
> the complete community. You described exactly the sad state of  
> Squeak today.

I know that lot of people are reading this mailing-list and I do not  
want that you
succeed in your systematic approach to demolish what we are doing.  
Because we are
making progress, even you can systematically deny it.

We are paying a lot of attention to the community:
        We are communicating with the teams
                - web team, Morphic teams, File team...
        We will do an announce to know if other team (graphics...) have new  
changes for 3.9.
        We are taking care that lot of speed fixes and tools enh get harvested.
        We are talking care to let the people vote and participate in the  
foundation.

Now you can be negative this is your right and kick our asses (I'm  
much more
exigent than you on the weaknesses of what we are doing) and even if  
Andreas is often harsh, he acts
as a good sting to kick us. I appreciate his comments.

Our goal is still to make Squeak an environment where people can  
invent their or our future
in education software (have a look http://documentation.ofset.org/ 
drgeo/videos/drgeo2-center.mpeg),
webdev, and any developments. We are always cautious that changes is  
difficult and may break other code.

Come on martin stop to be frustrated and participate (review fixes,  
join a team, have fun
life is too short to get frustrated all the time). At one point  
people will start to put your address in their
spam filter and you will have lost and us too, since if you comment  
would be constructiv and you would participate
we would have all gain something at the end of the day. But again  
this is your choice.

Stef

David T. Lewis wrote:
...
>
> That's not fair. Cees is going to a good deal of trouble to *get*
> our input, and he is setting clear expectations so that we know it
> will be treated is *input*. He is also making it clear that he is
> not arbitrarily changing the rules or the process; he's just trying
> to make it work well by getting more input and advice from all of us.
> This is a good thing.
>

He is arbitrarily cementing the rule that there is a release team that
is free to completely ignore any opinions about what becomes the next
Squeak release. This rule in itself is nonsense. Can this whole thing be
called community with such a rule?

In this special case of 3.9 Stephane tries to change the language
according to his personal views. Does it make sense to shield him
against any criticism by defining that he is free to completely ignore
what others think?

And there have been skeptical opinions from important persons of this
community which is on the brink to break into two parts right now. One
idea to solve this problem was to have a *small* core Squeak and
building on that special distributions or "flavors". This way a
contradiction between Traits and Tweak, which apparently exists - be it
temporarily, practically or whatsoever, could be circumvented. We could
have Squeak-Core and on top of that Squeak-Traits and Squeak-Tweak,
which of course does not exclude a merge or redistribution at a later time.

Anyway, a little common sense should tell everyone that it is sensible
to try a language change over a longer period of time than just a few
month. This prolonged trial period and of course the freedom of choice
would be served nicely by this release model.

Well, my strong impression is, that Stephane tries to prohibit exactly
this and Cees seems to support him.

Regards,
Martin

On Thu, 19 Jan 2006 03:12:26 -0800, Martin Wirblat <[hidden email]>  
wrote:

> He is arbitrarily cementing the rule that

Congratulations on using the word "cement" in the context of Squeak  
without cracking a smile.<s>

> there is a release team that is free to completely ignore any opinions  
> about what becomes the next Squeak release. This rule in itself is  
> nonsense.

Welcome to Open Source. This is the de facto state of affairs for any open  
source project.

People can debate or they can work. They can't do both. To the extent that  
they try, the work will suffer. No work = no product = no community.  
Half-implementations are useless to everyone.

> Can this whole thing be called community with such a rule?

Ultimately, someone has to make a decision. This means being "free to  
completely ignore any opinions" in opposition to that decision. Of course,  
a community accretes or attrits based on whether those decisions are  
useful or interesting.

> In this special case of 3.9 Stephane tries to change the language  
> according to his personal views. Does it make sense to shield him  
> against any criticism by defining that he is free to completely ignore  
> what others think?

You are using the word "others" imprecisely. When you say "free to  
completely ignore what others thing", you make it sound as if Stephane  
were some rogue coder, heeding no one in his reckless charge to make  
Squeak his personal mad-scientist laboratory. But, of course, Stephane has  
a lot of support from "others". If he didn't, traits would have to be so  
perfectly transparent no work would need to be done by anyone other than  
Stephane to implement them, and he'd then have to force them into the  
official Squeak release, which no one has the authority to do autonomously.

What you really mean, however, is that he is free to ignore =some= others.  
In particular, you, and those who agree with you.

> And there have been skeptical opinions from important persons of this  
> community which is on the brink to break into two parts right now.

I don't understand the source of the illusion that there is a single  
Squeak community, or that breaking into parts is necessarily undesirable.

> One idea to solve this problem was to have a *small* core Squeak and  
> building on that special distributions or "flavors".

But that in itself is a major project. More than one, actually. Nothing  
prevents you from doing this or joining one of the many teams that are  
working on this.

> This way a contradiction between Traits and Tweak, which apparently  
> exists - be it temporarily, practically or whatsoever, could be  
> circumvented.

A contradiction seems unlikely. A conflict--many conflicts--seem  
inevitable.

> We could have Squeak-Core and on top of that Squeak-Traits and  
> Squeak-Tweak, which of course does not exclude a merge or redistribution  
> at a later time.

Sounds great! When will it be ready? Tongue-in-cheek, of course, but if  
"the community" supports your vision, and that community contains people  
who are actually willing to work, then implementing your vision should be  
no problem, right?

> Anyway, a little common sense should tell everyone that it is sensible  
> to try a language change over a longer period of time than just a few  
> month.

Traits have been a prototype since--I don't know how long. Over a year,  
for sure.

I disagree with your "common sense", though. Gradual language changes (I'm  
not even sure how that would work with traits, frankly) tend to result in  
kludges, fragile code, and code that rots quickly. I'm only going by  
practical examples, here, like the introduction of objects to 3GLs, which  
started with a bunch of function tables (in some cases). Or some languages  
that adopted exception handling slowly. Or some of the weird morphings of  
the database-based languages. Basically, situations where expedience and  
not scaring people were the #1 priorities.

It's often best to make a clean, brutal break (and calling "traits" a  
brutal change is a stretch).

> This prolonged trial period and of course the freedom of choice would be  
> served nicely by this release model.

I dunno. It seems like you've stepped out the concrete to offer a solution  
which sounds perfectly reasonable, but lacks detail, implementors, and  
requires people to divert their energies in the name of your freedom of  
choice (which, it should be pointed out, is already absolute).

> Well, my strong impression is, that Stephane tries to prohibit exactly  
> this and Cees seems to support him.

I've never sensed any serious quashing of debate on this list (which is  
why we're so free to have the same discussions over and over again>s?).  
The only thing that comes close--and it doesn't come close at all,  
really--is when someone who's itching to make some actual progress (rather  
than hash out a 100% consensus) says, "Let's stop talking and get down to  
work."

Ultimately, all we have is theory until the work is done. I'd rather see a  
release of Tweak and Traits that conflicted than not to see either due to  
fear, uncertainty and doubt. Conflicts can be resolved. Hypotheticals  
cannot.

Well, this turned out to be more of a rant than I planned, but it seems  
like your complaint is ill-timed, considering the team reports, the  
voting, etc. It seems to me that work is getting done, which is a good  
thing, and not a given.

Mistakes will be made. Not a good thing, and unfortunately, a given.

> He is arbitrarily cementing the rule that there is a release team  
> that is free to completely ignore any opinions about what becomes  
> the next Squeak release. This rule in itself is nonsense. Can this  
> whole thing be called community with such a rule?
>
> In this special case of 3.9 Stephane tries to change the language  
> according to his personal views. Does it make sense to shield him  
> against any criticism by defining that he is free to completely  
> ignore what others think?

Do you really think that if lot of people would not have been  
enthousiastic about traits we would have ***work*** to integrate them
seamlessly and transparently?

> And there have been skeptical opinions from important persons of  
> this community which is on the brink to break into two parts right  
> now. One idea to solve this problem was to have a *small* core  
> Squeak and building on that special distributions or "flavors".  
> This way a contradiction between Traits and Tweak, which apparently  
> exists - be it temporarily, practically or whatsoever, could be  
> circumvented.

I do not understand why you want to oppose traits and tweak.
There is no such an opposition, after this is clear that there will  
be some work (but the problem is not with traits)
to remove Morphic and use Tweak but we already said to andreas long  
time ago that we are ready to help.

Apparently as usual you are talking but without knowing.


> We could have Squeak-Core and on top of that Squeak-Traits and  
> Squeak-Tweak, which of course does not exclude a merge or  
> redistribution at a later time.

Sure but not because of your contribution.

> Anyway, a little common sense should tell everyone that it is  
> sensible to try a language change over a longer period of time than  
> just a few month. This prolonged trial period and of course the  
> freedom of choice would be served nicely by this release model.
>
> Well, my strong impression is, that Stephane tries to prohibit  
> exactly this and Cees seems to support him.

The traits implementation has been available since lot of time. There  
is an open mailing-list. You can check it.
We asked for beta tester. But as usual you are talking, talking  
talking.....

I will not reply to you anymore because I'm busy and prefer to spend  
my time on positive things.

Stef

stéphane ducasse wrote:
....
>
> I do not understand why you want to oppose traits and tweak.
> There is no such an opposition, after this is clear that there will  be
> some work (but the problem is not with traits)
> to remove Morphic and use Tweak but we already said to andreas long  
> time ago that we are ready to help.
>
> Apparently as usual you are talking but without knowing.
>

Stephane,

the last thing Andreas said regarding 3.9 with Traits in relation to
Tweak was, that because of a series of errors he ran into caused by the
class/metaclass changes by Traits and given the pain he experienced
while porting Tweak to 3.8 he didn't want to investigate these errors
further, and he didn't even mention making another port of Tweak to 3.9.

Moreover he gave an interesting and *skeptical or cautious* overview
about what Traits is and what it is not in his opinion.

lists.squeakfoundation.org/pipermail/squeak-dev/2006-January/099311.html

You responded to this post but as usual you ignored its implications. In
fact you keep on ignoring Andreas' complaints about what you stuff into
the update stream since a long time. Moreover, you try to turn down
every skeptical opinion about Traits. At least you ignore it.

But, you could proof me wrong, here and now, and I will withdraw my
assertion that you behave ignorantly. Just agree to the idea that Squeak
makes from now on a minimalistic release Squeak-Core, with Squeak-Traits
and Squeak-Tweak (and perhaps others) on top of it.

Regards,
Martin

>Martin Wirblat wrote:
> Sent: Thursday, January 19, 2006 10:39 AM
>
> the last thing Andreas said ...


I know Andreas is shy, and doesn't really speak his mind ... but I think he
can speak for himself.  I seem to remember Andreas saying he'd give traits a
workout.

(I couldn't help it, I got sucked in  :^)

Happy programming!

Ron

All mankind is divided into three classes: those that are immovable, those
that are movable, and those that move. - Benjamin Franklin