[squeak-dev] A New Community Development Model

[This message is also available on the blog at
http://squeakboard.wordpress.com/2009/07/02/a-new-community-development-model/]

In the board meeting today we had a nice discussion about how to move
forward with a new community development model for Squeak. Here is an
overview of the model and what will happen next:

The goals
---------

The goal of this process is to get rid of as many hurdles as possible in
the contribution process. We are trying to enable the community at large
to improve Squeak, the core of the system and its supporting libraries.

To do this, we are adopting processes that have been shown to work in
commercial settings: The use of Monticello as the primary source code
management system, free access for the developers to the main
repositories, an incremental update process for both developers and
users of Squeak.

Repositories
------------

We will be setting up the following Monticello repositories:

* http://source.squeak.org/trunk

This will be the main repository for ongoing development. New code will
be committed here, the repository will be world-readable and writable
for the core-dev group.

* http://source.squeak.org/tests

This is the main repository for unit tests. It will be world-readable
AND world-writable. We encourage everyone to write more tests and commit
them, improve the existing tests and bring in entirely new test suites.

* http://source.squeak.org/inbox

This repository is intended as dropbox. It’s usage will depend on what
we make it out to be. The idea is to have it world-readable and
world-writable, too.

Developer access
----------------

The board will manage developer access to the repositories at
source.squeak.org. In the next days we’ll send out a few “you are
pre-approved” messages to people who have proven to be active developers
in the past in order to invite them to become a core developer.

If you can’t wait and absolutely want to be in on the action you can
register yourself at http://source.squeak.org/ and send message to the
board asking for access but most of the regular contributors (you know
who you are) will be invited anyway.

Rules of Engagement
-------------------

If you have used Monticello in projects with more than two developers in
the past you already know the drill. If not, here are some useful
guidelines:

* Merge often. In particular when you pick up work and right before you
intend to commit.

* Exercise caution. This is a running system and breaking it needlessly
is generally frowned upon.

* Restrain yourself. Getting developer access doesn’t mean you are free
to put in every pet extension you always wanted to have without discussion.

* If in doubt, ask. This is the corollary to the restrain yourself rule.
You’re not under pressure to ship a product, so you have the time to
send a note saying “hey, I’m planning to fix this old issue and it may
have some side effect here or there. Anyone having a problem with that?”

 >>> I’ll add a Squeak-dev exception here: Any response from any
non-developer can be entirely ignored in this context.

* You break it, you fix it. If you change something you are generally
expected to take care of the consequences, though there are some
exceptions. If in doubt, ask ;-)

* Do good and talk about it. When you’re done with whatever it is you’ve
been working on let people know about it. It can be as short as a note
to Squeak-dev saying “hey, some of you might care that I’ve fixed the
long standing bug with xyz. Update and enjoy”

I think that roughly covers it. Basically you will be working with a
dozen (hopefully more) other developers on Squeak and we’ll all have to
learn how to make this work successfully.

Updating
--------
We are in the process of developing an update process that can work
seamlessly with Monticello. An early experiment is described here[1]. We
are evaluating alternative approaches, in particular the use of
Installer since there are some shortcomings when using Monticello
Configurations.

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

Existing Work
-------------
It is important to note that we will be trying very hard not to lose any
work that is being done for Squeak 3.11. We will start with the package
set that was used in the 3.10 release, then we will issue package
updates to cover the missing delta up until 3.10.2. Following which we
will reissue any changes done for 3.11 into the repositories.

Hi,

this proposal is really a step towards openness. I'm glad you added
the inbox to your original proposal. Without that it wasn't really
welcoming work from others.

I still don't think that Monticello is the right way to go. It doesn't
really manage changes. I can so easily overwrite a change that was
applied before that it is hard to use. You can argue that you have to
be careful anyway and that you can merge. You are right but still it
is hard to use. Another thing is pharo. All of my contribution to the
image I did in pharo because I never saw much a chance to do this in
squeak. Now it can be doable. And doing something in pharo and not be
able to do it in squeak at the same time strikes me really. Using
always Monticello with full source compare will prevent applying fixes
from one team to the other. The sources are just more different every
day.

For the new setup to work well there is still one thing to do IMHO.
Sooner or later the bug tracker should help in organizing and
documenting changes. But mantis is in an awful state. There are nearly
2200 tickets in the database. Coming from the outside it looks like
really nobody cares. A bug tracker with less tickets and tickets that
give an overview what is going on right now is essential. Maybe not
for the gurus and old timers but for everyone else (e.g. me). I would
like to propose a cleaning initiative of mantis. I would expect a lot
of these old bugs to be obsolete by now. So a quick check if this bug
is still valid can be done. And then if it is invalid you just need
to close it.

Norbert

On Thu, Jul 2, 2009 at 2:02 AM, Norbert Hartl<[hidden email]> wrote:

Convert the changes into a change set.  File the change set into each
system and then create a new Monticello file for each system.

Andreas said that the repository will hold MC files.  He didn't say
you couldn't use change sets on your own.  Or any other tool you want
to use.  Use whatever you want to get your work done, then post it in
a standard format.

-Ralph Johnson

Bravo!  I'm very excited about the introduction of this process... I
think that it has a great chance to leverage the enthusiasm that has
been demonstrated in the recent discussions about Squeak's vision and
future.  We have smart people who care, we have a better vision of the
modular system that we want than we did in the Squeak Central days, and
now we have a development process that supports the quick turn-around
that is a central part of why we all care about Squeak in the first place.

Thank you, Board!

Cheers,
Josh



Andreas Raab wrote:

Norbert Hartl wrote:
Do you have an alternative?  I use Monticello every day in a
heavily-developed commercial codebase, and don't run into significant
problems.

> Another thing is pharo. All of my contribution to the
> image I did in pharo because I never saw much a chance to do this in
> squeak. Now it can be doable. And doing something in pharo and not be
> able to do it in squeak at the same time strikes me really. Using
> always Monticello with full source compare will prevent applying fixes
> from one team to the other. The sources are just more different every
> day.
>
>  

Again, do you have an alternative?  I don't think that there currently
exists a technical solution to this problem (nor can one, to the extent
that the codebases really are different).  Maybe someday Squeak and
Pharo will merge, but that will be after we overcome social challenges,
not technical ones.

Good point.  I'm hopeful that the process that Andreas describes will
lower the barriers to addressing some of the bugs listed in Mantis.

Cheers,
Josh


> Norbert
>
>
>  

On Thu, 2009-07-02 at 02:16 -0500, Ralph Johnson wrote:
Ralph,

I'm aware that it is doable. But you must see that there is a difference
between having the opportunity to file in the same thing with little
tweaking to multiple targets instead of first creating the target files
in a cumbersome way. Don't take this too literally. It will work somehow
to do this with Monticello. But as there is a tension to lower barriers
I just thought making that barrier lower is also wanted. That's all what
I wanted to say.

And...perhaps I didn't here much discussion about what goran was saying.
I understand people if they don't see much sense in using a piece of
software that hasn't matured yet for the management of their stuff. But
this could still be a part of the refreshing actions.

Norbert

On Thu, 2009-07-02 at 00:33 -0700, Joshua Gargus wrote: Yes, I did this, too. In my own team the only problem was dependencies.
But in a more loose environment like this there are other things to be
aware of. Having an inbox that is world-writable is a good thing. But if
you use Monticello that does not have a notion of change but contains
the new source code than every day you don't harvest that archive it
will detoriate. If you not use the same image as the originator of the
source package than it will eventually show a lot of changes. Only some
of these are your own changes. It is much more difficult to integrate
those package and the have to danger to introduce regression very
easily.
Well, goran took his chance to speak up. There is DeltaStreams und MC2.
While there is a risk using this pieces of software the benefit could be
really big. First you would give one of these tools the chance to
become a part of the overall that they deserve. And they try to
eliminate the problems that are experienced with changesets and MC. So
there has to be a point in using it. These are good tools but they all
tend to starve because at the end nobody dares to try it and to migrate
if you not promise that it is already rock solid and matured. I don't
think this is "how it works [tm]".

I just think that at this particular moment where everybody has woken up
and a little wave is making its way there could be a chance to finalize
one of the newer products.

Norbert

Norbert Hartl wrote:

On Thu, 2009-07-02 at 02:16 -0500, Ralph Johnson wrote:
  

On Thu, Jul 2, 2009 at 2:02 AM, Norbert Hartl[hidden email] wrote:

    

I still don't think that Monticello is the right way to go. It doesn't
really manage changes. I can so easily overwrite a change that was
applied before that it is hard to use. You can argue that you have to
be careful anyway and that you can merge. You are right but still it
is hard to use. Another thing is pharo. All of my contribution to the
image I did in pharo because I never saw much a chance to do this in
squeak. Now it can be doable. And doing something in pharo and not be
able to do it in squeak at the same time strikes me really. Using
always Monticello with full source compare will prevent applying fixes
from one team to the other. The sources are just more different every
day.
      

Convert the changes into a change set.  File the change set into each
system and then create a new Monticello file for each system.

Andreas said that the repository will hold MC files.  He didn't say
you couldn't use change sets on your own.  Or any other tool you want
to use.  Use whatever you want to get your work done, then post it in
a standard format.

    

Ralph,

I'm aware that it is doable. But you must see that there is a difference
between having the opportunity to file in the same thing with little 
tweaking to multiple targets instead of first creating the target files
in a cumbersome way. Don't take this too literally. It will work somehow
to do this with Monticello. But as there is a tension to lower barriers
I just thought making that barrier lower is also wanted. That's all what
I wanted to say.

And...perhaps I didn't here much discussion about what goran was saying.
I understand people if they don't see much sense in using a piece of 
software that hasn't matured yet for the management of their stuff. But
this could still be a part of the refreshing actions.
  

I think maybe I missed some of your context in my last message.  Perhaps DeltaStreams (or something) can help lower the barriers to contribute simultaneously to Squeak and Pharo.  However, I don't think that there's any sense waiting an indefinite period for that technical solution to mature while we have a pretty-good tool to use right now (and I see more clearly that you're not suggesting that either). 

I think that after some more experience with a Monticello-based process, whatever shortcomings that need to be addressed by future tools will naturally become more clear.  It's good to keep the issues that you raise in mind; they will be addressed in time.

Cheers,
Josh

 

Norbert


  

Norbert Hartl wrote:

On Thu, 2009-07-02 at 00:33 -0700, Joshua Gargus wrote:
  

Norbert Hartl wrote:
    

Hi,

this proposal is really a step towards openness. I'm glad you added
the inbox to your original proposal. Without that it wasn't really
welcoming work from others. 

I still don't think that Monticello is the right way to go. It doesn't
really manage changes. I can so easily overwrite a change that was
applied before that it is hard to use. You can argue that you have to
be careful anyway and that you can merge. You are right but still it
is hard to use. 
      

Do you have an alternative?  I use Monticello every day in a
heavily-developed commercial codebase, and don't run into significant
problems.

    

Yes, I did this, too. In my own team the only problem was dependencies.
But in a more loose environment like this there are other things to be
aware of. Having an inbox that is world-writable is a good thing. But if
you use Monticello that does not have a notion of change but contains
the new source code than every day you don't harvest that archive it 
will detoriate. If you not use the same image as the originator of the
source package than it will eventually show a lot of changes. Only some
of these are your own changes. It is much more difficult to integrate 
those package and the have to danger to introduce regression very
easily.
  

That's a good point.  It's difficult to predict how well it will work in practice.  But, it's even more difficult to design better tools when we don't see where the current ones fail.

Another thing is pharo. All of my contribution to the
image I did in pharo because I never saw much a chance to do this in
squeak. Now it can be doable. And doing something in pharo and not be
able to do it in squeak at the same time strikes me really. Using 
always Monticello with full source compare will prevent applying fixes
from one team to the other. The sources are just more different every
day.

  
      

Again, do you have an alternative?  I don't think that there currently
exists a technical solution to this problem (nor can one, to the extent
that the codebases really are different).  Maybe someday Squeak and
Pharo will merge, but that will be after we overcome social challenges,
not technical ones.

    

Well, goran took his chance to speak up. There is DeltaStreams und MC2.
While there is a risk using this pieces of software the benefit could be
really big. First you would give one of these tools the chance to 
become a part of the overall that they deserve. And they try to
eliminate the problems that are experienced with changesets and MC. So 
there has to be a point in using it. These are good tools but they all
tend to starve because at the end nobody dares to try it and to migrate
if you not promise that it is already rock solid and matured. I don't
think this is "how it works [tm]".

I just think that at this particular moment where everybody has woken up
and a little wave is making its way there could be a chance to finalize
one of the newer products. 
  

Personally, I have a tendency to over-engineer and build "The Right Thing" the first time.  Following the example of my excellent colleagues, I have learned to resist this impulse to a certain extent.

In this case, I don't see any danger in using the currently-available tools.  In particular, I don't see anything in the process that makes it difficult to experiment with or adopt better tools as they become available.  On the other hand, I perceive some risk to the current momentum if we make the process contingent on tools that may not yet be ready for the task.

Cheers,
Josh

Norbert
  

For the new setup to work well there is still one thing to do IMHO. 
Sooner or later the bug tracker should help in organizing and 
documenting changes. But mantis is in an awful state. There are nearly
2200 tickets in the database. Coming from the outside it looks like
really nobody cares. A bug tracker with less tickets and tickets that
give an overview what is going on right now is essential. Maybe not
for the gurus and old timers but for everyone else (e.g. me). I would
like to propose a cleaning initiative of mantis. I would expect a lot
of these old bugs to be obsolete by now. So a quick check if this bug
is still valid can be done. And then if it is invalid you just need
to close it. 

  
      

Good point.  I'm hopeful that the process that Andreas describes will
lower the barriers to addressing some of the bugs listed in Mantis.

Cheers,
Josh


    

Norbert


  
      

On Thu, 02 Jul 2009 09:02:20 +0200, Norbert Hartl wrote:

...
> For the new setup to work well there is still one thing to do IMHO.
> Sooner or later the bug tracker should help in organizing and
> documenting changes. But mantis is in an awful state.

Are you a Mantis user? I checked reporter id's but didn't find one  
matching your name.

> There are nearly
> 2200 tickets in the database. Coming from the outside it looks like
> really nobody cares.

Except to those people who use it. For example, Ken has recently closed  
bugs which have fixes in 3.10.x ...

/Klaus

Hi,

> Norbert Hartl wrote:
>> On Thu, 2009-07-02 at 00:33 -0700, Joshua Gargus wrote:
>>
>>> Norbert Hartl wrote:
>>>
>>>> Hi,
>>>>
>>>> this proposal is really a step towards openness. I'm glad you added
the inbox to your original proposal. Without that it wasn't really
welcoming work from others.
>>>>
>>>> I still don't think that Monticello is the right way to go. It
doesn't really manage changes. I can so easily overwrite a change
that was applied before that it is hard to use. You can argue that
you have to be careful anyway and that you can merge. You are right
but still it is hard to use.
>>>>
>>> Do you have an alternative?  I use Monticello every day in a
>>> heavily-developed commercial codebase, and don't run into significant
problems.
>>>
>>>
>> Yes, I did this, too. In my own team the only problem was dependencies.
But in a more loose environment like this there are other things to be
aware of. Having an inbox that is world-writable is a good thing. But
if you use Monticello that does not have a notion of change but
contains the new source code than every day you don't harvest that
archive it will detoriate. If you not use the same image as the
originator of the source package than it will eventually show a lot of
changes. Only some of these are your own changes. It is much more
difficult to integrate those package and the have to danger to
introduce regression very easily.
>>
>
> That's a good point.  It's difficult to predict how well it will work in
practice.  But, it's even more difficult to design better tools when we
don't see where the current ones fail.
>>
>>>> Another thing is pharo. All of my contribution to the
>>>> image I did in pharo because I never saw much a chance to do this in
squeak. Now it can be doable. And doing something in pharo and not be
able to do it in squeak at the same time strikes me really. Using
always Monticello with full source compare will prevent applying
fixes from one team to the other. The sources are just more different
every day.
>>>>
>>>>
>>>>
>>> Again, do you have an alternative?  I don't think that there currently
exists a technical solution to this problem (nor can one, to the
extent that the codebases really are different).  Maybe someday Squeak
and Pharo will merge, but that will be after we overcome social
challenges, not technical ones.
>>>
>>>
>> Well, goran took his chance to speak up. There is DeltaStreams und MC2.
While there is a risk using this pieces of software the benefit could
be really big. First you would give one of these tools the chance to
become a part of the overall that they deserve. And they try to
eliminate the problems that are experienced with changesets and MC. So
there has to be a point in using it. These are good tools but they all
tend to starve because at the end nobody dares to try it and to migrate
if you not promise that it is already rock solid and matured. I don't
think this is "how it works [tm]".
>>
>> I just think that at this particular moment where everybody has woken
up and a little wave is making its way there could be a chance to
finalize one of the newer products.
>>
>
> Personally, I have a tendency to over-engineer and build "The Right
Thing" the first time.  Following the example of my excellent
> colleagues, I have learned to resist this impulse to a certain extent.
>
> In this case, I don't see any danger in using the currently-available
tools.  In particular, I don't see anything in the process that makes it
difficult to experiment with or adopt better tools as they become
available.  On the other hand, I perceive some risk to the current
momentum if we make the process contingent on tools that may not yet be
ready for the task.
>
>
I would think the same if I would ignore the discussion about these topics
in the last months/years about this topic. DeltaStreams and MC2 are there
because there are experiencable shortcomings they want to solve. As far as
I can tell both are in a usable state but not fully matured, yet. But they
have state where there might be used for such a project. And this is a
work this community can survive for the first weeks.

Norbert

>>>> For the new setup to work well there is still one thing to do IMHO.
Sooner or later the bug tracker should help in organizing and
documenting changes. But mantis is in an awful state. There are
nearly 2200 tickets in the database. Coming from the outside it looks
like really nobody cares. A bug tracker with less tickets and tickets
that give an overview what is going on right now is essential. Maybe
not for the gurus and old timers but for everyone else (e.g. me). I
would like to propose a cleaning initiative of mantis. I would expect
a lot of these old bugs to be obsolete by now. So a quick check if
this bug is still valid can be done. And then if it is invalid you
just need to close it.
>>>>
>>>>
>>>>
>>> Good point.  I'm hopeful that the process that Andreas describes will
lower the barriers to addressing some of the bugs listed in Mantis.

Hi Klaus,

as these are the times to deal with community and feelings your answer is
a perfect sample what drives people like me away. I really don't like to
be offensive so please don't take it too literally. As an introduction I
think I am making a good point that is close to obvious. Neither is
bugs.squeak.org a closed tool where I have to register first nor must I
have been working for years with it to judge about its state. I can just
look at it. All I wrote is just my impression how I encounter squeak. And
I'm writing this even if I always have to think twice before posting to
squeak-dev.

> On Thu, 02 Jul 2009 09:02:20 +0200, Norbert Hartl wrote:
>
> ...
>> For the new setup to work well there is still one thing to do IMHO.
Sooner or later the bug tracker should help in organizing and
>> documenting changes. But mantis is in an awful state.
>
> Are you a Mantis user? I checked reporter id's but didn't find one
matching your name.
>
Why are you asking this? For me it has nothing to do with what I wrote.
But for me as a squeak user it sounds like

"Who are you to speak up against our work? What have you done to dare?"

Maybe I'm sensible for this but it sounds like to put others first in a
defensive state. From this on in my imagination you are already wearing a
grey beard. To me it doesn't sound welcoming at all.

For your information. I'm a mantis user? yes. You could find me in the bug
database? yes. I did ground breaking work for squeak? no.

>> There are nearly
>> 2200 tickets in the database. Coming from the outside it looks like
really nobody cares.
>
> Except to those people who use it. For example, Ken has recently closed
bugs which have fixes in 3.10.x ...
>
That is what I said! I never said that mantis is not used or obsolete. I
was referring to the amount and the age of the tickets. But if you want to
frustrate people than just say "Works for me". IMHO every other is
confused by a ticket system that contains tickets that are 5 years old and
have a rather massive amount. But the biggest problem is that I can easily
assume nobody of you has an overview over the open issues. So beside being
confusing what are these tickets helpful for? If they are obsolete close
them. If they are real bugs nobody cared the last 5 years so they can't be
that important.

Norbert

> /Klaus
>
>> A bug tracker with less tickets and tickets that
>> give an overview what is going on right now is essential. Maybe not for
the gurus and old timers but for everyone else (e.g. me). I would like
to propose a cleaning initiative of mantis. I would expect a lot of
these old bugs to be obsolete by now. So a quick check if this bug is
still valid can be done. And then if it is invalid you just need to
close it.
>>
>> Norbert
>>
>
>
>

On Thu, 02 Jul 2009 12:26:39 +0200, Norbert Hartl wrote:

> Hi Klaus,
>
> as these are the times to deal with community and feelings your answer is
> a perfect sample what drives people like me away. I really don't like to
> be offensive so please don't take it too literally.

Okay, not taken. But what you wrote was against the active users of the  
bug report system, and I do not like you treat them this way. They are  
very valuable, have been very active in their spare time, reported and  
fixed things.

In particular I don't like you saying "it looks like really nobody cares".  
Many things have been done to+with bugs.squeak.org in recent time, so it  
seems you are rather uninformed?

This cannot be unanswered, you know what I mean.

If you are not satisfied with the contents of Mantis, then why don't you  
do something against it? You could come back in a year from now and could  
tell "we've hunted them all down and closed all the unanswered cases", etc.

/Klaus

P.S. taking my message as a reason of your driving away would be a joke ;)

Hi guys!

In another post (about DeltaStreams) I expressed my support for this.
And in general I still do. BUT...

...shouldn't we discuss this a bit first? I agree with Keith that some
discussion would have been nice.

I have often asked the SOB to be more "active" - but I would like to see
it "hashed out" on the list a bit before being clubbed.

regards, Göran

The existing community development model works fine enough.

1. Submit changes as change sets to mantis.

2. Bob builds and tests the changes in a basic image, a dev image and a
full image

While you need your changes, and await the release with your fixes
integrated into it, you can load them manually from Mantis.

3. When Bob builds the new release he automatically loads changesets
from mantis, and fills in the MC repositories together with commit messages.

The result is an image that looks as though it has been managed with MC,
but the work is submitted in changesets that we all prefer.

This is an open process, and you can see what is due for inclusion or
not by querying mantis.

Now if certain members of the board would volunteer to contribute to the
process, rather than replacing it without discussion, we would all be a
lot better of.

best regards

Keith

Using MC repository as an inbox doesnt work because at the end of the
day it is a list of files.

One big weakness of MC repositories is that there is no feedback forum.
There is nowhere for the discussion of the contents in context.  There
is no means to mark a release as good bad of indifferent, or  to give
feedack to others as to what a particular package is good for.

Mantis does all of these things, it may not do them perfectly, but it is
a start.

Those fixes marked "testing" in mantis, are being considered for the
next release. This should help people to feel that their contributions
are being valued and used.

best regards

Keith

Keith Hodges wrote: Not only that they are automatically included in test builds
> best regards
>
> Keith
>
>
>  

On 7/2/09 8:20 AM, "Keith Hodges" <[hidden email]> wrote:


I was a disbeliever of automatic procedures and wish a return to 3.8 good
practice until some better tools  comes.

I trust Colin and Goran, but MC2 and DS seems not ready yet, so all we have
is old good (or evil) Change Sets.

As user, I wish hit the button on Squeak flap and see updates load nicely,
my image don't blow and I end in a number greater as 7159, what was the last
Ralph and me cook using a very ugly MC and Change Sets combo, but works
except on two situations.

Ralph set up a high bar for quality , any change should be test for no new
red test

I copy from http://wiki.squeak.org/squeak/5934

    * Prove the changes work as intended.
          o This often means:
         1. Loading bug tests before fixes.
         2. Run the bug test. (It should fail)
         3. Install the fix.
         4. Run the bug test. (Now it should pass.)

   1. Then prove all standard quick tests work.
   2. Then prove all standard long tests work.
   3. And as icing on the cake prove all tests work together

All this seems a must, we throw away this ?

So , before we run in a civil war with no winners, all should calm down.
Sorry I can't go to Brest and drink a beer with some Squeakers.

Edgar

> I was a disbeliever of automatic procedures and wish a return to 3.8 good
> practice until some better tools  comes.
>  
It's not an automatic procedure, its an automated procedure.

The "testing" image is built as people "decide" what is ready to be tested.

The "release" image is built as the release team "chooses" what is ready
to be released from the "testing" image.

The people doing the choosing are the ones that specify the quality or
lack thereof. The more is tested and the more feedback that is available
to those who submit the fixes the better.

If we had an automatic procedure, squeak could write itself... a few
years into the future, but we would need to include Asimov's 3 laws of
robotics by that point.
> I trust Colin and Goran, but MC2 and DS seems not ready yet, so all we have
> is old good (or evil) Change Sets.
>
> As user, I wish hit the button on Squeak flap and see updates load nicely,
>  
As developer, I built an image carefully from scratch with a set of
packages that I have chosen. I don't want my user loading a bunch of
fixes from somewhere that I have no control over.

Given that we expect each version of squeak to be available in different
release flavors, minimal, dev, web,  fun etc. The idea of an updates
stream covering all derived images without breaking them is not really
tenable.

Keith

Oooh, I didn't mean anything like that. Maybe it is problem with my
english but I wouldn't understand it that way. I wasn't critizing any of
the guys that do the work. Most of them I admire because after some years
here I know what they can and I know what they do. So if anyone took it
the way you understood it I like to apologize. I just meant the state of
the tickets. This things grow without anyone being responsible. Just the
state is not satisfactory.

> In particular I don't like you saying "it looks like really nobody cares".
> Many things have been done to+with bugs.squeak.org in recent time, so it
> seems you are rather uninformed?
>
> This cannot be unanswered, you know what I mean.
>
I said it looks like really nobody cares. Is the sentence different if I
write "it appears"?? Sorry, but it does appear that way if you like at it
the first time. Still no offense meant.

> If you are not satisfied with the contents of Mantis, then why don't you
> do something against it? You could come back in a year from now and could
> tell "we've hunted them all down and closed all the unanswered cases",
> etc.
>
Yes, you are right. Everyone that is telling this all the time is right. I
do this myself occasionally. I could even state that projects like squeak
are suffering by people like me that only talk and do nothing. Everything
is right.

But it is exactly what I mean. There are bright people here and the topic
is interesting. But a lot of discussions end like the one we are having
right now. And that is the reason I don't have the feeling I can _grow_
inside this community because of this. It so hard to participate without
being a master already. I rarely post anything because of this and now I
remember why. And still no offense meant! I just let it go. I will first
see that I can do a lot of work in order to earn my next post...

... in the meantime I spent my time somewhere else.

>
> P.S. taking my message as a reason of your driving away would be a joke ;)
>
Klaus, it is not about driving _me_ away. And declaring it to be a joke
does not make it more harmless. I can just imagine that people that have
even less experience with squeak might get a even worse feeling about
this.

anyway, thanks for taking your time!

Norbert