2009/7/3 Keith Hodges <keith_hodges at yahoo.co.uk>:
>
>> 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.
>
(the mail is a bit long, so i will comment as i read).
So far, we established a quite a bit new repositories at source.squeak.org
/trunk
/test
/inbox

lets say, all core packages, which is going to include into core image
will be located in trunk repo.
So far , do you see any contradiction with your model?
I may be wrong, but i don't see anything hazardous to your vision. Its
a simply a common place where people putting their code.

Later, Andreas shown how to work with it using Monticello configurations. Okay.
But you can show us the same, but done by using Sake (by writing a
config there) and Installer.
And i inviting you doing so.

> 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.
>
That's great!

> 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.
>
Instead, i think it just make things a little bit easier:
a group of contributors could use a single place to put core packages there.
They don't have to remember/know each package/changeset or source in
other forms location(s).

> 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.
>
Okay, so lets focus on making your tools more visible to community.
Not only to release list.

> 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.
>
Well, if we want some kind of 'official' image, we can build it using
your tools.
And obviously, there should be someone who oversees this process and
choosing what is going into image and what's not.
Again: i don't see how this contradicts with 'old new' model.

> 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.
>

Keith.
I think your work is relevant, and could bring us to a new level.
But i can't force people to go read about it, or start using it and
none of board members can.
I can add much more words, but the above summarises the most of it.

> regards
>
> Keith
>
>



-- 
Best regards,
Igor Stasenko AKA sig.