[squeak-dev] The Trunk: Monticello-cmm.575.mcz

Chris Muller asqueaker at gmail.com
Fri Nov 8 22:30:12 UTC 2013


The trunk is a huge part of the Squeak development process and
ecosystem that deserves and needs representation somewhere in the
system.  Access to it is reasonably needed by ReleaseBuilder,
Installer, source.squeak.org's SqueakSource and
MonticelloConfigurations.

Squeak has been using its own flavor of Monticello for several years
now, as does Pharo and GemStone.  So, to me, it feels fine to make it
Monticello-For-Squeak, meaning to relax restrictions imposed by
multiplatform so it can go as far as we want toward supporting the
Squeak process.

Having said that, I must admit this really does make it
Squeak-specific, no longer generic.  So, maybe an alternative should
be to model our development process elements in a new package,
SqueakDevelopmentProcess (?), which would depend on our Squeak's
generic Monticello to represent the elements of our development
process.

On Fri, Nov 8, 2013 at 3:12 PM, Nicolas Cellier
<nicolas.cellier.aka.nice at gmail.com> wrote:
> I have same feeling as Frank,
> a specific address of a specific repository for a specific usage has not
> much thing to do in MC.
> MC package should not integrate each and every possible usage of MC.
> If this does not belong to ReleaseBuilder, then we can make it a System
> thing...
> If it's only for MCM, didn't we get a MCMcmUpdater defaultUpdateURL?
>
>
> 2013/11/8 Chris Muller <asqueaker at gmail.com>
>>
>> MonticelloConfigurations has no dependency on ReleaseBuilder and I
>> don't think we should introduce one.
>>
>> If you at least acknowledge "trunk" is a real-thing in the real world,
>> then note existence of MCRepository>>#trunk.  Sure, we could make a
>> class-var or something if that helps you feel better, but my opinion
>> right now is that is not necessary because code can change if/when it
>> needs to.  Let's not let maybe-future-pie-in-the-sky-perfect be the
>> enemy of pragmatic progress in the present.
>>
>> On Fri, Nov 8, 2013 at 10:33 AM, Frank Shearar <frank.shearar at gmail.com>
>> wrote:
>> > On 8 November 2013 15:25,  <commits at source.squeak.org> wrote:
>> >> Chris Muller uploaded a new version of Monticello to project The Trunk:
>> >> http://source.squeak.org/trunk/Monticello-cmm.575.mcz
>> >>
>> >> ==================== Summary ====================
>> >>
>> >> Name: Monticello-cmm.575
>> >> Author: cmm
>> >> Time: 3 October 2013, 9:42:40.555 pm
>> >> UUID: daeb51c6-0b6f-41db-883d-e9764e61d8c5
>> >> Ancestors: Monticello-cmm.573
>> >>
>> >> - Integrate Berts suggestions.  Refactored and renamed the API for the
>> >> new history and origin browsing functions to avoid ambiguity with other MC
>> >> domain elements.  Went from "version" nomenclature to "history".
>> >> - Related to those functions, browsing a list of patch operations is
>> >> now abstracted from browsing a Patch.  MCPatch is now a MCOperationsList
>> >> and, likewise, a MCPatchBrowser inherits from a MCOperationsBrowser.
>> >> - Added well-known repository accessors for #trunk and #packageCache,
>> >> and #trunkUrlString avoids scattering the hard-coded url string literal in
>> >> so many places.
>> >
>> > I don't like this last item. MCHttpRepository has no business knowing
>> > about any particular location, nor should we commit ourselves to any
>> > particular repository implementation. For instance, it might make a
>> > whole lot of sense to build a repository backed by Cassandra.
>> >
>> > I'm not convinced that ReleaseBuilder isn't the right place for this
>> > info. Or, to avoid the double negative, I think ReleaseBuilder is the
>> > place that should know about the trunk URL, because ReleaseBuilder's
>> > the class responsible for this kind of thing. One kind of release we
>> > build is a release candidate, for instance.
>> >
>> > frank
>> >
>>
>
>
>
>


More information about the Squeak-dev mailing list