Joshua Gargus wrote:
> Keith Hodges wrote:
>   
>> You will not be able to replace the need for actual vision, actual
>> leadership, actual management, and actual testing with a bunch of random
>> undocumented commits to "trunk".
>>   
>>     
>
> I find it difficult to give your arguments my full consideration when
> you mix what may be good points with obvious fallacies. 
>
> For instance, you consistently speak of "undocumented commits". 
> However, each commit has a comment associated with it, so it is clearly
> not "undocumented".
Commit comments do not really constitute documentation, these are small
incremental changes and a set of changes are not even managed as a
coherent unit, as they would be in ChangeSets or DeltaStreams for
example. More importantly this documentation is not subject to revision
or improvement over time.

Lets say you have an initiative to replace the .changes file with a
better mechanism, you might write a proposal, document file formats,
recruit a couple of folks to code and test. Then you would have a
documented innovation. However in integrating this change the
documentation and lessons learned would continue to grow and contribute
to the knowledge base for that topic.

DeltaStreams and Rio are examples of this, they come as a package to
load and a number of changesets/deltastreams that are required to
integrate it into each image. These are made available via Installer
LevelPlayingField in a manner that can cope with the differences between
target images. Then if cobalt wants to integrate Rio, they can pick up
all that they need in one place and they can contribute to the knowledge
base as well.
>  However, this is clearly no
> different from commenting on an issue on Mantis; the comment may be
> enlightening or useless, and nothing in the technology can force it to
> be one or the other.
>   
But the comment on mantis can be refined over time after the decision to
include it in the release has been made. A review can be made and people
can look at the 10 worst documented fixes on mantis which apply to
squeak 3.10, and they can improve the documentation, improve the testing
and test the fix more widely and add further information.

The result being that the final release will have the full improved
documentation.

Having a real process involves being able to plan the release, craft the
release, and craft the release documentation, in a regularly repeated
cycle perhaps monthly or bimonthy.
>   How
> much of this is intended as a constructive criticism (because it isn't),
> and how much is an emotional response to your (understandably, to a
> certain extent) hurt feelings?
>   
The real problem in moving squeak forward is a people problem. For 3.11
we worked using the release team list and we worked using irc with real
"face to face" discussions on a relatively frequent basis. We had a
small group of contributors but Andreas overwhelmed everything with one
email to squeak-dev.

If Andreas had gone to squeak dev and said we want to move things
forward , anyone volunteering? Then assessed where different initiatives
had got to, looked at what needed help and what needed looking at,
considered who is good at what, and asked people what they wanted to do
and got everyone together for a virtual beer, none of this would have
happened. In case I am not mistaken that's called management and release
team motivation and liason.

However instead we got "trunk", a technical hammer to throw at the
problem, and in one foul swoop Andreas disassembled all of management,
planning, and thought that had occurred up to that point.

Keith