<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Douglas Brebner wrote:
<blockquote cite="mid:4A5F7FE2.5050905@fang.demon.co.uk" type="cite">
<pre wrap="">Joshua Gargus wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Douglas Brebner wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Joshua Gargus wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Douglas Brebner wrote:
</pre>
<blockquote type="cite">
<pre wrap="">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?
</pre>
</blockquote>
<pre wrap="">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).
</pre>
</blockquote>
<pre wrap="">Conveniently structured images build from packages is what Kieths build
tool is for.
</pre>
</blockquote>
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap=""><!---->No, </pre>
</blockquote>
<br>
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). <br>
<br>
<blockquote cite="mid:4A5F7FE2.5050905@fang.demon.co.uk" type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<br>
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). <br>
<br>
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".<br>
<br>
<br>
<blockquote cite="mid:4A5F7FE2.5050905@fang.demon.co.uk" type="cite">
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">Won't it
also make using MC in other smalltalks gratituously harder?
</pre>
</blockquote>
<pre wrap="">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".
</pre>
</blockquote>
<pre wrap="">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?
</pre>
</blockquote>
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap=""><!---->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, </pre>
</blockquote>
<br>
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".<br>
<br>
<br>
<blockquote cite="mid:4A5F7FE2.5050905@fang.demon.co.uk" type="cite">
<pre wrap="">I haven't seen
any mention of how releases will be done.
</pre>
</blockquote>
<br>
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.<br>
<br>
<blockquote cite="mid:4A5F7FE2.5050905@fang.demon.co.uk" type="cite">
<pre wrap="">
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.
</pre>
</blockquote>
<br>
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.<br>
<br>
Cheers,<br>
Josh<br>
<br>
</body>
</html>