Joshua Gargus wrote:
>>  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.
Bear in mind that the Board put forward Spoon as Squeak 5.0, and they
cancelled 3.11. Therefore moving forward is not as important as you
might suppose. If it was then they would never have conceived of
cancelling the 3.11 effort, which they did.

They also told me that too much progress on 3.11 would be a problem
since the re-licencing would have more to catch up on, and the
relicencing was more important.

(no one has sacked Craigs ideas because he hasn't delivered anything,
not even an email in a year, is he still alive?)
Andreas would be better off working on spoon to move us all forward.

So moving forward is not the most important thing at all.

I believe that having a process that supports open contributions that
are not in the control of one person/release team is. Until we have that
process, any work "moving forward" is actually making the problem worse.
Someone will have to sift through all of the work that is being done in
trunk and do it all again. Just as I had to sift through Edgar's
SqueakLightII in order to try and capture the knowledge in a usable form.
> 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? 
You have established a scenario, where only one person can make big
plans. That person is (currently) Andreas, and he doesn't publish a
project proposal, document an API, etc etc. He just sets to work on the
trunk repository. No body knows what he is going to do in advance.
Everyone is waiting for him, and is limited to throwing in a couple of
fixes here and there.

If you want to make a contribution to trunk, you have to review all of
the changes made before you first, since it is a moving target. You have
to guess what other people are up to and fit around them. This is by
default a situation in which it is virtually impossible to plan more
than one step forward at a time, but no one knows what other people are
planning as their next step.

How is someone supposed to announce, "I am going to replace morphic" and
do it in trunk? It wont happen. Not only that but the person who wants
to make a radical proposal has no place to contribute it now. Anyone
else who has big plans, has to get his ideas through Andreas, because he
is defacto in charge of the trunk repository. If you have a big plan,
and start putting it into practice in the repository, you will break a
few things, and that will not work with the updates mechanism.

So in summary, the trunk is defacto in control of Andreas, only he knows
what he is going to do next, and this then limits everyone else. They
are not idiots, but they have no means to plan "interventions", because
they cant read Andreas' mind, and neither can Andreas read their mind.

Squeak as yet again hitched its wagon to one person's view of the way
forward. However the fact that forks exist indicate that this isn't the
way to go, and we need a process that fits the forking/forked world better.

Trunk is a linear development model where only one thing can be
integrated into the image at a time, and that thing has to be totally ready.
> (BTW, I hink that many people find this condescending... you are quite
> literally saying that only those who agree with you are doing any
> thinking;
Not at all, I am saying that the situation does not allow the kind of
thinking that is required, and anyone who does the thinking offline,
will not be able to apply it, and get their ideas accepted for several
reasons.

Firstly they will have difficulty deploying their ideas into trunk,
because trunk is moving continuously. To get an idea accepted they need
to gain mindshare, the best way of doing that is to show it working they
need to integrate it into the image. To integrate it into the image they
need to gain mindshare.

The only way of having a big idea integrated is is the trunk guys stop
work on their stuff moving their ideas forward for a bit, and say right
we are going to spend time integrating X's contribution. But X's
contribution has to be completely ready.

So big progress is now limited to linear one integration of a completed
thing at a time, at Andreas' behest.
> only by reading between the lines can we infer that "it" must refer to
> something more specific.  Not exactly conducive to a constructive
> dialogue).
>
>> 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.  
Well thats the way it was, and now apparently still is.
> 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.
Its a chaotic free for all, for those that are in the inner circle, a
bottleneck for everyone else.
>> it cant be refined over time,
>>   
>
> What?!?  Isn't "incremental" synonymous with "refined over time"?
>
Incremental means here is your new method and it must work, the
increment is not for refinement, every increment is a release.

No one can post a non-working work in progress to the update stream that
is for the community to refine.

>> 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.
You work in your image, you pick other peoples fixes from mantis as they
come along and load them into your image, and you publish to your MC
repository  bob builds test images from your MC repository, and the
minimum set of fixes that you nominate are necessary.

Your new gui needs to be published as a unit, together with a minimum
set of fixes that are necessary for it to work. Then other forks can use it.
>
> 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?
>
Because the plan isn't written in code. The only way for you to know
what the plan is is to read others minds.
>>> 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.
I am telling you what has happened historically and is happening before
my very eyes now.
> 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?
Because fixes written for integration into 3.11 have to be
simultaneously loadable into 3.10. Any 3.10 user with an existing image,
must be able to apply fixes in order to maintain some level of API
parity, and thus this facilitates him moving his code to the new image.

All fixes that are included in 3.11 must also be published as individual
ad ons for users in 3.10. Infact the build process builds 3.10+fixes
first, and then applies the 3.11 generating script.

There is no place for an intermediate "some image that some folks have
worked on and made incompatible with previous releases because they felt
like it"
> 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,
Actually I merged the work of several contributors, and others have
contributed. Merging forks is not being a pre-madonna, its clearing up
other people's messes.
> 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?
If Andreas was to take the contributions of every version of MC that had
ever existed and was to merge them all and then move things forward, I
would be all for it. But I doubt he has time.

That's what I did.

>>> 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.
The release should simply include the latest version of every external
package. The release/trunk should not patch or fix any external package.
If Andreas wants to work on MC he should join the MC team and work in
the MC repository.

Yes compiler can be an external package, as can Network, MC is, SUnit is.
>> 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.
Lock in occurs when you pick an image to base your project on. You are
then locked in to the choices that that fork's release team makes on
your behalf.
>>> 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 why dont they see using it as even a low priority.
> 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.
Because this process is unworkable, it doesn't provide any slot into
which I can contribute.
> 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 no way of knowing either way.
> and nothing in your process that ensures compatibility.
Yes there is. Developing the new release based upon the fixed point of
the old release, does ensure some compatibility. Any incompatibilities
found can be rectified on the next build. ALL fixes are by definition
backportable because they are developed for the old image not the new one.

Any big packges for integration in the new release can also be
backported to the previous release if necessary, because the fixes
needed are backported be definition.
>
> Thanks for the explanation, I feel like I understand where you're
> coming from a bit better.  Do you feel the same?
>
> Cheers,
> Josh
its a pleasure

Keith