Hi lex and others (I hate long emails but please read this one because 
there are a lot of important points)

> I have already been putting great effort into community organization,
> especially over the last 7-8 months.  I have brought up issues, steered
> discusisons towards workable concensus, and even posted code and 
> offered
> servers using my own resources.  Please drop these claims that you are
> noble for shouldering the burden of dirty organizational work.  You are
> not the only ones contributing on those lines, and it is rather rude to
> disregard what other people are doing.  To be painfully honest, half of
> my frustration with the "new leadership" proposal is that there are
> already a lot of people helping on these issues, and now a subset have
> declared themselves as the ones that count.


I sincerly hope that you can integrate the mysterous island guys if you 
want.
For me I think that this is more a responsibility or charge of duties 
that
something else.

> Aside from that, let me describe some specific background which makes 
> me
> especially wary of the "new leadership" proposal.
>
> First, the package universes work I have put time into, is the *only*
> working solution we have to a real problem: generating stable sets of
> packages.  I spent extensive time trying to convince powers that be to
> modify our infrastructure to use this approach.  When that failed, I
> coded it up myself and have offered the service using my own resources.
> Despite this effort, the response has consistently been that universes
> is attacking someone's turf.  On the mailing list, I get posts along 
> the
> lines of "how can you do this" and "how can you cause this
> fragmentation".  On the Swiki it is worse.  For days, every time I
> posted a mention of universes, someone in the .ch domain edited the 
> page
> to put a defamotory comment beside it.  One of the defamations went so
> far as to dismiss the project by saying "universes has not been adopted
> by SqueakMap".  This is a telling statement -- someone out there in 
> .ch,
> sincerely believes that SqueakMap approval is *already* the measure of
> legitimacy in Squeak.

Personally I was lost in all the discussions. I tried your distro and 
it works
Besides that I think that we should avoid to have fight on a given 
choice.
I would appreciate that people (external) build a requirement list of
what is not working with squeakmap or with your universe and
we fix it. (I should say that sometimes squeakmap gets in my way)
and I would like to have everything on my disc especially when I'm 
behind
a slow modem.

> Don't dismiss this as someone whining about their superior solution
> being rejected to an inferior one.  This is the *only* working solution
> that we have.  Further, the problem it solves is one that is widely
> agreed to be a to be one of the most important community issues we 
> have.
>  It's a stated goal of the "new leadership".  It's a problem so hard,
> many have claimed it can't be solved at all.  Do we want the kind of
> leadership that works hard to marginalize such an effort?

I think that you should be part of the group participate to setup the 
agenda,
I can tell you that we are waiting results from this group. Because 
there is
still a lot of stuff to do and if we all be only writing emails about 
how the new stuff we did
and how cool they were I'm sure that squeak would be already in the 
future.

For my part, I stopped harvesting and I'm waiting for 3.8 since there 
is no
point stacking changes. Then after I would like to follow the map we 
presented and
I'm waiting for feedback and help on this area. Of course a good 
package mechanism
and deployement mechanism is important.

> As further background, I have run into the same sort of problems with
> the gatekeepers of the Unix port of Squeak.  I contribute bug fixes --
> again, obvious bug fixes, like Squeak failing to start on SunRay
> machines -- but they are passed over and left to sit on a separate
> website literally for years.  This state has gone on for about 7 years
> now, and almost the only time I have seen my bugfixes go in, is when
> that group was threatened with losing status as the "official" Unix 
> port
> of Squeak.

I would like to remedy on that because if this is frustrating for you 
imagine
for the guy like my trying to install squeak on solaris and getting 
everything blocked after the
first sounds ;). But what can we do?


> In both cases, I freely accept that not everyone will like the things I
> suggest.  I think we should use Jam instead of make, but if you don't
> agree, so be it.  I think we should use registries instead of
> allSubclasses, but if everyone is set on it, let's do it and do it
> carefully.  What I don't accept, is that clear solutions to definite
> problems are getting dropped on the floor.  There's no excuse for that.

I understand.

> We should try to remove gate keepers, not add more of them.  In my
> experience, they kick out good things way too often.  The community is
> hurt, when gate keepers reject the only solution to a real problem, or
> when we have buggy VM downloads even though the fixes have been posted?
> The reason for these things are that the gatekeepers, despite their 
> good
> intentions, are not accountable and are not chosen by the community.

How?
First be exigent with the group that formed.
I really suggest you to participate and if something gets wrong 
reported publicly. I think that their
mailing-list will be public. And again, we are all waiting for results 
and concrete ones.

> It's just human nature that people in power will deal with their own
> problems, if they do not have any kind of reminder about the effects on
> the general population they are serving.  I dislike this rush to create
> even more gate keepers.  we should instead work on setting up proper
> processes so that they have feedback and are accountable.


Yes this is what I'm waiting from this group.
As you know the SqF is going slowly and this may be goran got impatient 
and messed up
a bit his communication. I'm sure that around a beer things would have 
been better.
I know the impatience and I practice a lot "french communication"

> So far, I see no problems with deciding things on squeak-dev.  When
> there is a clear organizational need, and when there actually are
> proposals, we do reach concensus over time.  I do not see what a
> leadership body can do to improve this situation.  What we need are 
> more
> good ideas.  Once people post good ideas to group problems, they tend 
> to
> get adopted just fine.

But I think that we need a process and a beat. So that on regular basis 
we got news.
Look at 3.8 (I have nothing against the guys doing the release because 
we went this path too),
but they complained that 3.6 or 3.7 was taking long time to get out and 
now we are WAITING
and we do not really know what is happening. I would love to get every 
week a small email saying:
We know we messed up our deadline but last week we did that and that.
Would not it be nice?
So for 3.9 I hope that you will remind me to do the same, if I'm fool 
enough to take that responsibility.



> If I am wrong, then please point out specific examples of where the
> mailing list has stalemated.  Don't be flippant -- I want to see a case
> where we actually have a problem and multiple proposals, but that the
> list could still not agree on a way to move forward.  Harvesting, for
> example, is a problem where there aren't any good proposals at all.

No harvesting is falling apart. Then after you get people like andreas 
complaining that changes
x broke z....Now we need to have a better process for non trivial fixes.
We should also have task forces. For example, let us debug/improve the 
new compiler during
two months. This can be as simple as that, using the new compiler and 
reporting bugs.

> Packaging technical details, are a problem where progress has been made
> and where, in my analysis, the discussions seem to be progressing just
> fine.  With namespaces, I think tabling the issue has been a good idea.
>
> Let me reemphasize that I am sure everyone is trying to help.
> Additionally, I recognize the frustration some people are feeling, even
> if I do not share in it.  All I object to is the way this is being 
> done.
>  I don't think we should hand pick this group as our "new leaders".
>
> Could you consider redefining yourselves less abbrasively?  If you 
> acted
> as an "advisory steering committee", then I am sure most of your
> proposals will still sail through because you are such insightful
> people.  Some will not -- but come on, criticism is a good thing.

Agree. I do not give them the keys and will judge them on their acts
and the pressure will be strong since another group can be pissed of
and simply leave the boat. So I would appreciate if you join the group.


> Yes, having the burden of convincing the crowd that your ideas are
> sound, will slow things down.  However, it will make the group a much
> more pleasant place if there is a little less "i am your leader, here 
> is
> the way".

Agree. But now this is done so let us them the time to see what they 
can do.

> Eventually we would like to have things move faster, but the way to do
> it is to form an election process like in Debian.  That should be 
> doable
> in 6-12 months I would think, should enough people put in the energy to
> work out the details and sell it to the general community.  We need 
> this
> structure anyway, just so that we have a voice to speak with.  But what
> is the rush?  I don't understand this feeling of crisis, that we cannot
> put in 6-12 months and do it in a non-abbrasive way.

I agree. The urge seemed too much but my french and impulsive exploding 
nature
encompasses and understands. But now let us focus on the results.
And for example, continue with Universes if you believe that this is 
good
and your clients like that. As I said I would like to hear about 
problems with them
and packages. But not now.....

Like I can tell you that I will not read anymore email about namespaces 
for now and not
before we have a way to build a distro from a set of packages and that 
the image evolution
works with packages.


Stef