> Hi Eliot,
>
> Bob & things are discussed and reported on the release-team list, see
> for example
>
> -
> http://lists.squeakfoundation.org/pipermail/release/2009-February/000072.html
>
>
> /Klaus
>
The objective of the existing 3.11 effort was to produce "a new
community development model" based around the idea of planning new
releases ahead as a coded task. This task does things like so...

0. Start with fixed starting point.
1. load latest Installer/Monticello tools
2. load the latest versions of important packages that are managed
externally e.g. SUnit / SqueakMap
3. (optionally) Major architectural integrations (i.e. closures) pre-fixes
4. load image fixes that have been approved for 3.11 in mantis
5. (optionally) load image fixes that are marked as testing for 3.11 in
mantis
6. reorganise the image into tidier categories and better packages as
supported by new features in PackageInfo
    e.g. Monticello1.5 is now split into Monticello.impl and
Monticello.test
7. (optionally) Other major architectural integrations (i.e. closures)
post-fixes
8. export the result as MC packages
9. (optionally) load a bunch of packages to make a full/dev image
9a release 3.11-dev 3.11-fun 3.11-web 3.11-magmaserver
10. (optionally) Run all tests
11. (optionally) remove some packages
12. (optionally) remove externally managed packages
10. (optionally) remove all tests
12a release 3.11-minimum
13. (optionally) remove all tools - mc/installer etc.
13a. release 3.11-kernel
14 repeat back to 0 until satisfied.

This coded task, allows someone to be working on SUnit for example in
parallel with someone working on Mantis Fixes. It is not sequential it
is an iterative build process, which results in a sequential progression
in the MC repositories (step 6)

An outline plan for 3.11 the image [step 5 above] has been present in
code form for over a year, we were simply continuing to make the tools
to make the rest of the process happen i.e. (steps 4,5,10,13 etc) on a
frequent (i.e daily basis). Once in place this will free us up to make
releases on a far more continuous basis, say every 2/3 months.

Since Andreas has summarily announced a "new new community development
model", as far as I can see, and I am willing to be corrected, this has
rendered the "old new community development model" outlined above
irrelevant.

I apologise for listening to the board when Randal said relax on 3.11
because we want to put relicencing on the critical path. Andreas took
the inaction that followed as a queue to interfere, while I was simply
trying to pay the bills for a month or so, and we are experiencing a
welcome heat wave (whoever said global warming was a bad thing!)

At present I cant see what Andreas' model is good for, ok so you
contribute for a few MC packages in a kind of undocumented free for
all.  I don't see how Andreas' new model presents any new philosophy or
way forward for the different forks of squeak, so apparently we are
being forced back to the old way of doing things. Again as far as I can
see Andreas' new development model has no place in it for planning a
re-organisation of the image improving the package structure, moving
packages out to be loadable, supporting derived smaller and larger images.

To demonstrate my point, who is doing the work in Andreas' new model.
Yes, that's right it's Andreas, as far as I can see we are back to there
being one bottleneck in the contribution process.

The old new model (above), defines an integration process that a number
of contributors may contribute to at different stages. If for example
you choose to adopt the project of improving SUnit, then you know that
your work will be included in the release because your latest code is
loaded on each build iteration, and fully included in the integration
testing that everyone sees, and can give you feedback from.

The old old (i.e. 3.10) way, relies upon the release team deciding
whether or not to use your work when they have time to get around to
checking it (which is invariably never) This resulted in the 3.10 team
refusing for no good reason to include the latest version of Installer,
thus wasting the effort that was put into making the latest installer,
leaving 3.10 users with an inferior installer that couldn't even upgrade
itself. The use of a relentlessly moving forward update model resulted
in 3.10 having a broken DateAndTime now which had to be fixed in 3.10.2

The old new 3.11 way (above) automatically includes your work, if it is
included in the coded build task, and gives everyone the tools to
integrate, and test the fully integrated result, and all derived images.
The bulk of the effort that has gone into making 3.11 better than 3.10
is in packages that are loaded externally, aiming to make radical
improvements to the code loading tools, the handling of packages, and
the running and categorisation of tests (I had the misfortune to try and
install something using the python package manager, believe me we are
not the worst in this regard). If you want to help, then please
volunteer on release at lists.squeakfoundation.com there are lots of small
projects that could be helpful.

When you submit a fix to mantis you are a contributor automatically to
the "apply fixes" steps 4,5 in the build process. The Andreas model is
returning to relentless moving forward in the control of one person
deciding what is in and what is out without the ability to craft the
build process.  We threw out the idea of a continuous updates mechanism
because this only tends to facilitate incremental additions, it is a
nightmare to carefully surgically reorganise or remove a chunk of code
if you have to keep the image working all the time, and have to maintain
the same package structure.

I do not have the energy or the will to compete, either you the public
want a new way of doing things or you don't. So unless Andreas
voluntarily seeks to understand and co-operate with the present but now
apparently obsoleted vision, I have no alternative but to wish you all
luck in the good ship Andreas, the new release team doing it the same
old fashioned way.

Lets take the suggestion for submitting tests as indicated in a previous
email. Has Andreas even looked at the already coded task step for
organising tests as loadable sub-packages according to a much tidier and
more logical design? He certainly hasn't commented on it to me. Has
Andreas even loaded the improved SUnit and looked at the new ways for
tagging and categorising tests?

If Andreas wants to actually contribute to the existing vision, then he
needs to propose an additional step in the coded build task, and show us
how his repositories and update process fits with the rest of the
process. For example if he was to say ... I have a vision... that of
making "Network" a subsystem that I will go off and make really good
streamlined version of that package. Great... you can go off and work on
Network to your hearts content, but it might not fit into the plan for
3.11 it could be scheduled into the code integration task for 3.12 when
we are ready and able to load the new revolutionary streamlined chunk
with atomic loading in one go. (atomic loading is on the roadmap for 3.11)

So like I said if you want to volunteer to help, I will see you on
release at lists.squeakfoundation.org  We have a vision, and we have lots
to do... but as I said, I cant yet see what relevance Andreas's new new
model is to it. He has proposed a technical idea or two but that in
itself does not a vision make.

The current 3.11 vision includes

- Bob building and integration server
- Crafting images through pre-coded build integration and testing tasks
according to a planned design (not just the whims of the person
integrating the next update)
- Code loading and management tools for all squeak images promoting
cross fertilisation (i.e. Level Playing Field)
- Package management including dependencies for all packages (again for
all squeak forks and kernel images) (Sake/Packages)
- SUnit/SSPec testing with categorisation of tests for different images
- Atomic (un)loading
- More granular package structure
- Split Tests out into paired MC packages that can be loaded/unloaded
- Automated collection of fixes tagged as ready on mantis.

So as in time honoured tradition, the board has demonstrated that it is
irrelevant to squeakers, since it doesn't seek to discuss its decisions
with squeakers before taking catastrophic actions. Heck it didn't even
think of mentioning this to the release team before it was presented to
you all. This approach to dealing with people is the antithesis of what
the "old new community development model" was intended to be all about,
that of inclusion, and valuing people's contributions.

This is the second time that the board has inadvertently cancelled the
3.11 vision as described above, and it probably wont be the last. So I
throw this one back to the board to decide what it really does want. In
the meantime I shall work on my tan.

regards

Keith