Douglas Brebner wrote:
> 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, 

Then I'm not sure what you're getting at.  Nobody has denied that Bob
can be used to build images from packages (at least I haven't).

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

I'm thinking about both at the same time.  Packages are good, and Squeak
development happens in Squeak images.  I believe that when someone goes
to squeak.org, there should be an easy-to-find image that has the tools
necessary to track current development.   That image may be built by Bob
(why not?), and will have MC loaded (otherwise it couldn't track current
development).

The exact same packages as in this image (or a subset/superset/etc.) can
be used to build other images using Bob.  I'm agreeing with you that
"conveniently structured images built from packages is what Keith's
build tool is for".


>>>>> 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'm sure that it will.  I'm sorry, what is the point that you're driving
at?  I don't see how you got here in 2 steps from "Won't it also make
using MC in other smalltalks gratuitously harder".


> I haven't seen
> any mention of how releases will be done.
>   

Really?  I believe that I've read a number of times that Bob is
orthogonal to the new process, and would be a fine tool to use for
building release images.

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

Maybe.  Monticello's GUI doesn't provide a good way of visualizing
branches (even command-line SVN uses a separate directory tree for each
branch, which is better), which might encourage the sloppy use of
terminology.  Let's assume that there will be branches for releases; I
don't see why there wouldn't be.

Cheers,
Josh

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20090716/060fa66c/attachment.htm