Keith Hodges wrote:
> A good set of reasonable questions.
>   
>> Can you explain why?  
>>     
> I can try.
>   

:-)  Thanks, I think that some ideas may have penetrated my skull.

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?

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

Right!  So we're in agreement... what's the problem?

Just kidding... a few remarks:

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.

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? 

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

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.

>> 2) the old process provided significant barriers to contribution (in
>> the form of confusion, extra hassles, etc.)
>>     
> 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.
>   

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.

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.

> 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.
>   
>> 3) having an "update" button built into the default Squeak image is
>> more convenient than having to first load Monticello
>>     
> 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, 

Mostly agree, but this isn't a problem (see below)...

> it cant be refined over time,
>   

What?!?  Isn't "incremental" synonymous with "refined over time"?

> it has to work.
>   

Hopefully most of the time, yes.

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

OK so far...

> and those things get planned,
> implemented and refined over time. Those things can be small fixes or
> revolutionary things like new gui's.
>   

... but now I disagree.  You seem to be arguing against a strawman.

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.

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?


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

No, it does not.  Not if we care about backward-compatibility.

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?

Granted, this assumes that people care to make the effort.  But if they
don't care, then your process can't magically fix that.

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

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

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?

>> 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? 
>>     
> Yes, why indeed, and this has been done with the Kernel Image.
>   

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. 

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.

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

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.

> If you think about the problem in terms of modularity, 

I do...

> then we can move
> forward. If you think about things in terms of an image that someone
> owns, then you lock people in.
>   

... and I don't (think in terms of an image that someone owns).

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.

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.

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

OK...
> Keeping MC outside the image,

... or in it, since you just said it doesn't matter.

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

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.

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

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

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.


Thanks for the explanation, I feel like I understand where you're coming
from a bit better.  Do you feel the same?

Cheers,
Josh


> Keith
>
>
>
>
>   

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