Some thoughts 2/3: Preparing 3.9
Doug Way
dway at mailcan.com
Tue Sep 14 05:23:30 UTC 2004
On Sunday, September 12, 2004, at 04:11 PM, danielv at tx.technion.ac.il
wrote:
> I think that we should also include Monticello as a package in 3.8/3.9.
> I see two reasons to do this, one short term one long term.
We actually discussed this a bit earlier (although no one summarized
the reasons as well as you did here) and generally agreed that
Monticello should go in 3.8. It's actually in the plan for 3.8:
http://minnow.cc.gatech.edu/squeak/3832
(Just butting into this thread here... I will catch up with the rest of
these threads tomorrow.)
- Doug
> 1. That way users of Squeak package that are maintained using MC don't
> have extra barriers to becoming contributors. The immidiate possibility
> of being active is IMO an important value in Smalltalk.
> 2. It is key to our attempts to improve the modularity situation. TFNR
> partitioning of the image is only useful if the tools are there to
> actually manage changes to the system along package boundaries. With
> the
> current tools in the image, they are essentially inert. MC is not ready
> yet to be used for managing all of Squeak as a bunch of packages, but
> from some testing I've done during CampSmalltalk, it isn't that far
> away. Giving it more visibility and more usage will help get it there
> faster, and we should also start getting more familiarity in the
> community with this way of working.
>
> We should start the integration of the tool early, even if its not
> perfect and completely ready, so we can co-adapt to it over time.
>
> Note that its mere inclusion doesn't force any changes in the way
> people
> do anything.
>
> Daniel Vainsencher
>
> =?ISO-8859-1?Q?st=E9phane_ducasse?= <ducasse at iam.unibe.ch> wrote:
>> hi,
>>
>> for 3.9 we (marcus and me at least) would like to see the following
>> tools integrated into the image:
>> - RB engine
>> - services
>> - shout
>> - OmniBrowser
>>
>> Now what is important is to identify the changes that are done over
>> 3.7
>> basic and minimise then by:
>> - checking if they are really worth
>> - analysing the extensions or patches and introducing them separately
>> into the basic image.
>> If there are missing hooks then they should be separated and
>> harvested
>> into the basic image
>> so that other tools can use them.
>>
>> So what I would like to know if the interested parties are ok with
>> this
>> plan?
>>
>> Stef
>
More information about the Squeak-dev
mailing list
|