Joshua Gargus wrote:
> Douglas Brebner wrote:
>> Joshua Gargus wrote:
>>   
>>> Douglas Brebner wrote:
>>>     
>>>> Joshua Gargus wrote:
>>>>   
>>>> Isn't keeping MC in the trunk directly contradictory to the whole point
>>>> of seperating the image into packages and splitting them out? 
>>>>       
>>> No.  It will still be loadable/unloadable; it will be included for
>>> convenience.  You could create a Squeak image without a compiler too,
>>> but this would be inconvenient for the "default" Squeak image (the one
>>> you first find when looking on squeak.org).
>>>
>>>     
>> Conveniently structured images build from packages is what Kieths build
>> tool is for.
>>   
>
> Are you saying that development will happen just as quickly when all
> code submissions must be scraped off of Mantis by Bob, compared to
> committing directly to a respository?  If so, that's absurd. 
> Otherwise, I'm completely missing your point.
>
No, the numbered release images will be build from a set of specific
package releases and mantis submissions. (Think of these as branches
that should only receive fixes)
The latest mainline image will be built from the latest mainline
packages. (Fixes can be pulled and tested, then folded in but won't be
the main method of development).
Your own custom images can be built from whatever packages you like.
(can be a mix of specific release or latest)

They'd all be built automatically from a build config for Kieths tool.

Normal development would be done on a package basis, not a whole image
basis. The only exception would be for restructuring where the package
boundaries change.

I think part of the problem is that some people are thinking in terms of
package development and others in terms of randomly messing with the
whole image.
>>>> Won't it
>>>> also make using MC in other smalltalks gratituously harder?
>>>>
>>>>   
>>>>       
>>> I don't see why.  All that it means for a package to be "in the trunk"
>>> is to be in a particular Monticello repository.  In order for a
>>> package to be compatible across Squeak versions (and even with other
>>> Smalltalks), somebody has to put in effort.  The effort required is
>>> not reduced by simply storing the package in a repository "outside the
>>> trunk".
>>>
>>>     
>> I think there's some confusion here about what "in the trunk" means.
>> Some people think it means to be kept in the mainline image.
>> Others think it means to be in the Squeak.org repository.
>>
>> Exactly which is it?
>>
>>   
>
> It is both.  The term "trunk" has a well-understood meaning in the
> context of version control, and nothing in the new process is
> contradictory to the accepted meaning.  At the same time, there is
> less friction if the most obvious image to download from squeak.org
> contains all of the tools necessary to participate in the process. 
> None of this implies that MC will become entwined with the latest
> version of Squeak.
>
I'm well aware of what a trunk is. But the repository will also include
branches for releases. Or at least, I'd hope it would, I haven't seen
any mention of how releases will be done.

I think part of the confusion is that people are referring to the repo
itself as trunk which implies that everything in it is in constant flux.