<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Keith Hodges wrote:
<blockquote cite="mid:4A5E5B0F.2010906@yahoo.co.uk" type="cite">
<pre wrap="">A good set of reasonable questions.
</pre>
<blockquote type="cite">
<pre wrap="">Can you explain why?
</pre>
</blockquote>
<pre wrap=""><!---->I can try.
</pre>
</blockquote>
<br>
:-) Thanks, I think that some ideas may have penetrated my skull.<br>
<br>
At the very least, your mention of Squeak 3.7 highlighted that when we
talk about "compatibility across forks", we're talking as much about
backward-compatibility as we are about with forks like Pharo and
Croquet. I've been assuming that your focus was on the latter. In
your mind, are you more concerned with one than the other?<br>
<br>
<blockquote cite="mid:4A5E5B0F.2010906@yahoo.co.uk" type="cite">
<blockquote type="cite">
<pre wrap="">Consider the following (please grant me the first point, in the
interest of a meaningful discussion):
1) the community apparently supports the new contribution process,
which is based on Monticello
</pre>
</blockquote>
<pre wrap=""><!---->All significant development happens in Monticello. However the
difference between most projects and this process is that most projects
have a title, and a defined scope, they have a plan, goals and they are
delivered in a loadable form.
If you were to propose "We are going to develop a better X" where X is
HTTPClient, then fantastic, go ahead. I am quite happy for someone to
take on a subsection and go and make a better one.
But this isnt that. This is... we are going to develop a better X,Y, Z,
A, B, C, all overlapping, incremental, don't break anything way, come on
in, its all in one repository, do what you like, oh and btw This is now
a new branch of squeak, so we can do whatever we like without thinking
in advance about it. If you improve something its for us in our branch
that's what we want, after all we are moving forward and that is the
most important thing right?
</pre>
</blockquote>
<br>
Right! So we're in agreement... what's the problem?<br>
<br>
Just kidding... a few remarks:<br>
<br>
Moving forward is not the only important thing, but it probably is the
most important (if it's not, what is?). We shouldn't lose sight of
that.<br>
<br>
Throughout this thread, you have repeatedly stated that we will thrash
about the repository "without thinking in advance about it". Could you
clarify what you mean by "it"? Clearly, you don't mean "anything",
because you don't think that we're all complete idiots. Does "it" mean
"backward/cross-compatibility"? Some other software-engineering
concern? <br>
<br>
(BTW, I think that many people find this condescending... you are quite
literally saying that only those who agree with you are doing any
thinking; only by reading between the lines can we infer that "it" must
refer to something more specific. Not exactly conducive to a
constructive dialogue).<br>
<br>
I only somewhat agree with your characterization of the differences
between developing X vs. X,Y,Z,A,B,C. I'll come back to the topic
below.<br>
<br>
<blockquote cite="mid:4A5E5B0F.2010906@yahoo.co.uk" type="cite">
<blockquote type="cite">
<pre wrap="">2) the old process provided significant barriers to contribution (in
the form of confusion, extra hassles, etc.)
</pre>
</blockquote>
<pre wrap=""><!---->The old old process had a significant barrier to contribution. That
barrier was "the release team". This process has a barrier too, its call
the "release team a la Andreas". Conceptually nothing has changed.
</pre>
</blockquote>
<br>
I don't buy that. Either it's a chaotic free-for-all, or we're
substituting one bottleneck for another; it can't be both.<br>
<br>
Forgive my presumption, but for the rest of my response I'm going to
assume that you'll pick "chaotic free-for-all", because that seems more
like the gist of what you've been writing.<br>
<br>
<blockquote cite="mid:4A5E5B0F.2010906@yahoo.co.uk" type="cite">
<pre wrap="">
Those currently dwelling in other forks are getting nothing out of the
process, thus the audience for this process is the minimum part of the
existing community.
</pre>
<blockquote type="cite">
<pre wrap="">3) having an "update" button built into the default Squeak image is
more convenient than having to first load Monticello
</pre>
</blockquote>
<pre wrap=""><!---->The "update" model is a push model. The update button pushes whatever
someone else thinks you need into your image. That new something has to
be incremental, it cant be revolutionary, </pre>
</blockquote>
<br>
Mostly agree, but this isn't a problem (see below)...<br>
<br>
<blockquote cite="mid:4A5E5B0F.2010906@yahoo.co.uk" type="cite">
<pre wrap="">it cant be refined over time,
</pre>
</blockquote>
<br>
What?!? Isn't "incremental" synonymous with "refined over time"?<br>
<br>
<blockquote cite="mid:4A5E5B0F.2010906@yahoo.co.uk" type="cite">
<pre wrap="">it has to work.
</pre>
</blockquote>
<br>
Hopefully most of the time, yes.<br>
<br>
<blockquote cite="mid:4A5E5B0F.2010906@yahoo.co.uk" type="cite">
<pre wrap="">
My model is a pull model. You pull what you want, bob pulls what some
think would make a great release, those in forks can pull what they feel
would best contribute to their goals, </pre>
</blockquote>
<br>
OK so far...<br>
<br>
<blockquote cite="mid:4A5E5B0F.2010906@yahoo.co.uk" type="cite">
<pre wrap="">and those things get planned,
implemented and refined over time. Those things can be small fixes or
revolutionary things like new gui's.
</pre>
</blockquote>
<br>
... but now I disagree. You seem to be arguing against a strawman.<br>
<br>
Revolutionary things like GUIs are actually easier to develop when you
are continually integrating changes during development. Of course I
don't inflict the horrible brokenness upon people while I develop it; I
do it in my private Monticello repository. So, there's no disadvantage
compared to your approach. On the other hand, there are significant
advantages (please correct any misconceptions about your approach). By
continually merging as I develop, I am able to take advantage of the
latest features and bug-fixes, and avoid having to do it all at once
just before posting it on Mantis (or wherever). I could approximate
this incremental development pattern with Bob by repeatedly generating
new images, and porting my work-in-progress to the new image. However,
this is inconvenient because I build up a lot of working context in my
images (workspaces full of code snippets, to-do lists, long-lived
inspectors on objects, etc.), and it is inconvenient to recreate this
context.<br>
<br>
I don't see how one process supports things that "get planned,
implemented and refined over time", but the other doesn't. Can you
explain to me why it is impossible to do this in the new process?<br>
<br>
<br>
<blockquote cite="mid:4A5E5B0F.2010906@yahoo.co.uk" type="cite">
<blockquote type="cite">
<pre wrap="">4) if there is a demand for lean, Monticello-less images, then Bob can
easily build them
You seem to take it as a philosophical necessity (axiomatic) that MC
must be external, when in reality the question is one of pragmatics.
</pre>
</blockquote>
<pre wrap=""><!---->Your "pragmatics" leads to every version of squeak having different
tools, and no way of updating them to what is current. Your pragmatics
leads to 4 different diverging forks of the MC tool set. Your pragmatics
leads to versions of squeak being released with significant parts of MC
tools not even working correctly (3.10 Monticello Configurations)
</pre>
</blockquote>
<br>
No, it does not. Not if we care about backward-compatibility.<br>
<br>
Say that the community has been progressing the trunk for 9 months,
starting at 3.10.2. Now, it has been decided (somehow) that it's about
time to make the next stable release X.x.x (the version numbers aren't
important). Bob will try out the latest versions of various packages
(let's say Monticello) in 3.7/8/9-lpf, and may find out that stuff is
broken. If so, it probably won't be hard to fix, either by extending
LPF on the older platforms, or by rewriting some of the changes in a
less disruptive fashion. The process can even happen earlier, if
someone notices changes that will cause problems, or if the developer
solicits opinions. Why do you think that this can't work? <br>
<br>
Granted, this assumes that people care to make the effort. But if they
don't care, then your process can't magically fix that.<br>
<br>
BTW, I think that we should try not to break compatibility
gratuitously. My (least) favorite example is typing "SmalltalkImage
current blah" instead of "Smalltalk blah". Why? There is only one
SmalltalkImage (Hydra was not conceived until years later). So, for no
benefit other than some ill-defined notion of "cleanliness", we have
more to type and less compatibility. The good news it that I think
that we've grown past that (or at least, we can wage Wikipedia-style
undo/redo battles against such inanities :-) ). But I digress...<br>
<br>
<blockquote cite="mid:4A5E5B0F.2010906@yahoo.co.uk" type="cite">
<pre wrap="">My pragmatics results in 3.7-lpf 3.8-lpf 3.9-lpf croquet-lpf Pharo-lpf
3.1.2-lpf and 3.11 all having the latest MC tools all of the time.
</pre>
</blockquote>
<br>
Yes, as a result of the hard work of one prima donna, the latest MC is
available across multiple Squeak versions. Sorry, I couldn't resist.
But, there is an element of truth in the jest... how does that
constitute evidence that your process works, when similar efforts by
Andreas constitute evidence that his doesn't?<br>
<br>
<blockquote cite="mid:4A5E5B0F.2010906@yahoo.co.uk" type="cite">
<blockquote type="cite">
<pre wrap="">Borrowing Edgar's "Devil's Advocate" hat for a second... why does
Squeak-3.10 come with the Network package installed? Surely this can
be loaded manually by anybody that wants it, right?
</pre>
</blockquote>
<pre wrap=""><!---->Yes, why indeed, and this has been done with the Kernel Image.
</pre>
</blockquote>
<br>
Sorry, I didn't make myself clear, because that wasn't my point.
3.10.2 does contain the network code. Why? Perhaps I should have gone
with the example that I was originally going to use, the Compiler.
Just as easily as for the Network code, we could create an image
without the Compiler package. But we don't. Why? For the same reason
I describe below. For the *desired purpose*, an image without a
compiler is not as useful as one that has it. <br>
<br>
Similarly, for an image whose *purpose* is to support the process that
Andreas introduced, it is more useful to put it in than leave it out.<br>
<br>
<blockquote cite="mid:4A5E5B0F.2010906@yahoo.co.uk" type="cite">
<blockquote type="cite">
<pre wrap="">The answer is that the convenience outweighs any the negatives for the
Squeak community as a whole. Someone running embedded Squeak on a
submarine-robot might have to strip out the network code to make it
fit, but nevertheless the network code "belongs" in the base image
simply because of the result of this cost-benefit analysis.
</pre>
</blockquote>
<pre wrap=""><!---->But if the Network code is unloadable and replacable, then it doesnt
matter if you release an image with it or without it. If you want it it
is there, if you don't it is unloadable and replacable.
</pre>
</blockquote>
<br>
Maybe I should have used the term "unload" instead of "strip out"... I
apparently gave you the wrong idea. Of course, I don't mean to imply
that Monticello should have tendrils deep into the system such that it
is difficult to unload.<br>
<br>
<blockquote cite="mid:4A5E5B0F.2010906@yahoo.co.uk" type="cite">
<pre wrap="">
If you think about the problem in terms of modularity, </pre>
</blockquote>
<br>
I do...<br>
<br>
<blockquote cite="mid:4A5E5B0F.2010906@yahoo.co.uk" type="cite">
<pre wrap="">then we can move
forward. If you think about things in terms of an image that someone
owns, then you lock people in.
</pre>
</blockquote>
<br>
... and I don't (think in terms of an image that someone owns).<br>
<br>
Of course, development in Squeak cannot happen without an image. As an
open-source project, Squeak thrives (or fails to) with the
contributions of its community. Therefore, when someone visits
squeak.org, the first image that they find to download should be one
that promotes contributions. For an experienced developer, they can
contributed immediately. For a newbie, they gain visibility into the
process.<br>
<br>
What do you mean by "lock people in"? I cannot see how what I describe
above constitutes lock-in, by any stretch of the imagination.<br>
<br>
<blockquote cite="mid:4A5E5B0F.2010906@yahoo.co.uk" type="cite">
<blockquote type="cite">
<pre wrap="">If Monticello is the way that the development trunk is maintained,
then I want it in the same image. To keep it outside is to generate
unnecessary friction in the process, both to contributors and to those
who want to simply want to keep up-to-date.
</pre>
</blockquote>
<pre wrap=""><!---->Its got nothing to do with whether a release image has it loaded or not.
It has to do with how you treat it, and maintain it.
</pre>
</blockquote>
<br>
OK...<br>
<blockquote cite="mid:4A5E5B0F.2010906@yahoo.co.uk" type="cite">
<pre wrap="">
Keeping MC outside the image,</pre>
</blockquote>
<br>
... or in it, since you just said it doesn't matter.<br>
<br>
<blockquote cite="mid:4A5E5B0F.2010906@yahoo.co.uk" type="cite">
<pre wrap=""> means that MC is developed and maintained
as a service to the whole squeak community, by a benevolent (and
hopefully appreciated) team working for the good of everyone. This then
means that the MC team has the freedom to implement new features, like
atomic loading and binary packages for the good of all.
</pre>
</blockquote>
<br>
This can happen in the new process, no problem! It just needs some
benevolent (and hopefully appreciated) people working on it. You
apparently care about cross-version MC compatibility more than anyone
(thank you!). And I would venture to say that nobody is opposed to
it. So, if you bring the same energy to the new process as you did in
the old one, then you will continue to be successful, and people will
continue to enjoy the fruits of your labor. If some dumbass
inadvertently screws things up, then you can help them understand what
they did wrong so they can fix it. By sharing your knowledge and
wisdom, the community will more quickly learn the ups-and-downs of
cross-version development. In the unfortunate case where someone
obstinately insists on making technically-indefensible changes, the SOB
reserves the right to revoke commit privileges.<br>
<br>
On the other hand, consider some other package (say Balloon3D, although
it's probably not the best example). It hasn't been actively developed
in a while, but all of a sudden someone feels a burst of enthusiasm.
But, they don't care (or maybe don't have the time) to make their
changes backward-compatible. Your process doesn't have a magic
solution for this; it still takes someone who cares to put in the
effort. It's unfortunate that Squeak 3.7 users will be stuck with the
same crufty old B3D, but at least the new process makes contributions
easier, and makes it easier for the enthusiasm of the moment to drag in
other users to help (which would be very unlikely with a Mantis-based
process).<br>
<br>
<blockquote cite="mid:4A5E5B0F.2010906@yahoo.co.uk" type="cite">
<pre wrap="">
Maintaining it as part of a release image limits it to serving the users
of a not yet released image only, which represents the minimum of MC
users out there.
</pre>
</blockquote>
<br>
Again (because advertisers know that repetition works ;-) )... there is
nothing in the new process that forces incompatibility, and nothing in
your process that ensures compatibility.<br>
<br>
<br>
Thanks for the explanation, I feel like I understand where you're
coming from a bit better. Do you feel the same?<br>
<br>
Cheers,<br>
Josh<br>
<br>
<br>
<blockquote cite="mid:4A5E5B0F.2010906@yahoo.co.uk" type="cite">
<pre wrap="">
Keith
</pre>
</blockquote>
<br>
</body>
</html>