[squeak-dev] Re: Cross fork development model

Joshua Gargus schwa at fastmail.us
Thu Jul 16 17:09:18 UTC 2009


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.

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

There's much more detail in the other emails I'm writing in a different
sub-thread of this conversation.

Cheers,
Josh




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


More information about the Squeak-dev mailing list