[squeak-dev] Cross fork development model

2009/7/15 Nicolas Cellier <[hidden email]>:
> My understanding is all are insterested in sharing some bug fixes,
> Kernel improvments, Cog closure and VM improvments, light weight Cuis
> widget improvments, etc...
>
> Nicolas

It makes sense. It's important to have a deeper introspection in
regard to this, whether it worths the weight and efforts it requires.
Would a cross fork development model work if only Squeak people push
it? Provided that everybody is interested into sharing bits of code,
they should make it official with a clear statement and open
communication channels.

Furthermore, it also shouldn't make Squeak dependent on forks' fixes
and alike... we should have our own continuous flow of fix,
improvements and so on.

Ian.

--
http://mecenia.blogspot.com/

+1 to all of Ramon's posts in this topic.  Right on target.

Josh



Ramon Leon wrote:

Which was earned, by developing and demonstrating a number of projects
including LevelPlayingField, and then by going through protocol and
writing a proposal and putting it to the board, which had otherwise
decided to cancel any further development that wasn't spoon.

Andreas has done none of the above, he hasn't put a proposal forward,
and he hasn't replaced the release team.
    

Andreas *ran* his campaign on improving the Squeak process and got
more votes than anyone.  That's all the authority he needs to get
involved in changing the process.

  

If that is the case then we are all wasting our time, I am not involved
in this for the sake of a pissing match. I proposed a vision, the board
accepted, that's it, end of.
    

Obviously, it isn't.  Other people are free to waste their time
however they see fit.

  

If they change their mind then so be it, but that puts out a very
troubling message. (A bit late now I fear)
    

I've seen no one deeply troubled by any of this except you.

  

Not at all. The imposition is not on them, it is on us, that we as the
"squeak" mother branch, as ratified by the board, undertake to make
every piece of progress we develop available in a documented, and
packaged form, that other forks can make use of if they want to.
    

"If you build it they will come" doesn't work if you can't find anyone
to help you build it.

  

Furthermore with the use of automated testing tools we will even make it
possible to load and test our contributions in your fork or derived
image for you.

Finally releases will be assembled out of completed pieces according to
a specified plan, that other forks can examine and use parts of if they
want to.

We will propose specific projects, delivered as externally managed and
publicly shared projects to move "squeak" forward but the results of
those developments will be deployable in all squeak forks. (e.g.
closures, improved HTTPClient, MC1.6, MC1.7, Logging, Rio,
Sake/Packages, SUnit, Morphic3.0?)
    

Yea, so your swinging for the fence wanting the home run.  Good for
you, but don't criticize those who are being pragmatic and going for
the base hit that is known to work.  If you only allow contributions
through Mantis, then you are telling most people not to contribute and
to go away.  It seems pretty clear that most people just want to use
Monticello and check in code.  Fit the process to the people, not the
people to the process.  Andreas is being pragmatic.

  

Since most of their work is not done on changing the kernel, that
doesn't really matter.
    

You can't guarantee that.

  

But it is our primary goal, to update and refactor the kernel and make
it as easy as possible for all forks to take advantage of the stuff we
offer them on a plate.
    

We who?  I don't see an army behind you, but I have seen more positive
response to his proposal than to yours.  Yours is so complex most
people apparently understand what the hell it is.  That you
continually keep having to restate your vision should tell you
something.  You're so deep into your process that you're unable to
compromise or understand that not everyone is trying to rid the world
of forks.  Andreas has praised your tools many times, that's common
ground, build on that.

  

We are not developing, we are integrating already completed stuff.
    

What you are not doing is listening.

  

Again with the presumption that you're right and he's wrong.  Give it
a rest, if his idea sucks it'll fail in due course; if it has merit
then it'll succeed and he'll get people contributing to Squeak.  He's
not trying to solve the problems of every other fork, he's trying to
make it easier to contribute to Squeak.  That might not fit in with
your grand scheme, but if you can't sell him on your scheme, then so
be it, let him be.  He was elected by the community to do this; he's
not just some random dude trying to piss of Keith.

      

He was not elected to do this, he was elected to a position on the board
whose remit is to liase and encourage, and to be consulted on vision and
direction.
    

Yes, he was elected to do this, that's what got him so many votes.

  

The board is a political body, it is not supposed to be heavy handed at
all. The teams that it may choose to ratify are the ones that do the work.

If Andreas wants to be on a release team, then he should step down from
the board first.
    

You cannot claim to derive authority from the board and then protest
its authority.

  

Obviously, some people agree with him, respect him, and find it easier
to contribute with his method.  If your process was so easy and
simple, you'd have everyone doing it your way already.  Since they
aren't, you have to ask yourself why?

      

Look how many fixes are on mantis and have got scripts attached.

That is my way

Keith
    

Yes, that is your way, and people are clearly unsatisfied with it and
what they perceive to be a lack of contributions from the community.
You say *we* an awful lot but from what I can gather *we* usually just
means you and Matthew.  The community is bigger than the release team
and they need an easy way to contribute *anything they want*, not just
well tested well documented bug fixes submitted to Mantas as change
sets.

If the current process worked so well, Andreas wouldn't be trying out
an alternative one trying to re-inspire the community.  In a sense,
you're wanting to be in charge of the release branch and Andreas is
trying to setup an unstable branch where contribution is easy and much
less formal, a simple check-in with comments should suffice.  What's
wrong with having both?

Ramon Leon
http://onsmalltalk.com

  

Keith Hodges wrote:

Andreas Raab wrote:
  

Keith Hodges wrote:
    

Looks like you have forked PackageInfo now...  
      

For factual reference, I used the version that was in Croquet because
it has seen years of use and I trust it. It itself is based on
PackageInfo-avi.20 which is straight from the horse's mouth as far as
I am concerned.

If you have a better version, how about contributing it to the trunk?
    

Absolutely not.

MC is maintained as an external package, once for all, the repository is
open. It is not maintained in trunk, nor should it be.
  

Can you explain why?  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
2) the old process provided significant barriers to contribution (in the form of confusion, extra hassles, etc.)
3) having an "update" button built into the default Squeak image is more convenient than having to first load Monticello
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. 

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? 

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.

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.

Cheers,
Josh

If you want to load LPF and base trunk on 3.10.2-build as a starting
point then that would be a good idea, but MC should remain as an
externally maintained entity.

Keith
  

I find that these comments are indeed more towards what Keith has been saying all along.

And I find that Keith's posts have always made positive sense from a point of view of the long term good of the Squeak Community.
These goals are a big part of what he has in mind.
He has done a massive amount of work to this end. With help, the processes could be improved and streamlined.

To those that accuse him of not listening, or of having a poor attitude, I say they had better look really, really seriously at their own listening skills and attitudes.

To me, Keith is showing real insight and leadership for the good of the Squeak Community as a whole.
His ideas and work deserve far better treatment than the community is currently showing.

I am sure there are far more people in the community that can also see this but are not speaking up.

Ken G. Brown

At 5:54 PM +0200 7/15/09, Nicolas Cellier apparently wrote:

Am 15.07.2009 um 20:00 schrieb Ken G. Brown:
+1

Regards
Andreas

On Jul 15, 2009, at 2:00 PM, Ken G. Brown wrote:

Well put.  No one can change what has already taken place, but it  
would be nice if everyone could take a step back, take a breath, and  
look at how both sets of objectives can be met as they don't appear to  
be (entirely) mutually exclusive and, with a little work, should be  
able to complement each other.

Thanks,
Phil

+1
cheers, reinhard

Ken G. Brown schrieb:

A good set of reasonable questions.
> Can you explain why?  
I can try.
> 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?
> 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.

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, it cant be refined over time,
it has to work.

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, and those things get planned,
implemented and refined over time. Those things can be small fixes or
revolutionary things like new gui's.
> 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)

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

If you think about the problem in terms of modularity, then we can move
forward. If you think about things in terms of an image that someone
owns, then you lock people in.
> 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.

Keeping MC outside the image, 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.

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.

Keith

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




  

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? Won't it
also make using MC in other smalltalks gratituously harder?

Juan Vuletich wrote:
Well, once the image is split entirely into packages and we have an
automatic build tool, won't the forks turn into configurations for that
tool? i.e. instead of having Squeak and Pharo, we have the Squeak people
distributing their own build tool config that loads packages A, B and C,
while the Pharo people have a config that builds their images from
packages X, Y and Z. Over this you could then load LevelPlayingField to
provide a common API for portable code.

With that sort of setup, forks should disappear, replaced by packages
and build configurations.

Douglas Brebner wrote:

Joshua Gargus wrote:
  

Keith Hodges wrote:
    

Andreas Raab wrote:
  
      

Keith Hodges wrote:
    
        

Looks like you have forked PackageInfo now...  
      
          

For factual reference, I used the version that was in Croquet because
it has seen years of use and I trust it. It itself is based on
PackageInfo-avi.20 which is straight from the horse's mouth as far as
I am concerned.

If you have a better version, how about contributing it to the trunk?
    
        

Absolutely not.

MC is maintained as an external package, once for all, the repository is
open. It is not maintained in trunk, nor should it be.
  
      

Can you explain why?  Consider the following (please grant me the
first point, in the interest of a meaningful discussion):


    

Isn't keeping MC in the trunk directly contradictory to the whole point
of seperating the image into packages and splitting them out? 

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

Won't it
also make using MC in other smalltalks gratituously harder?

  

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

Cheers,
Josh

Joshua Gargus wrote: Conveniently structured images build from packages is what Kieths build
tool is for. 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?

Awesome! My reply to you is exactly the paragraph you are quoting. Please
read it again. I already said why I presume Pharo will not join. I also
said why Cuis will most likely not join. Cuis could be integrated into
Squeak (i.e. used as a starting point to build the Squeak kernel on which
packages are loaded), but not joined (i.e. taking the Squeak kernel as a
base to build Cuis).

Cheers,
Juan Vuletich

Joshua Gargus wrote: 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. 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.
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. I am telling you what has happened historically and is happening before
my very eyes now. 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" 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.
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. 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. 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. 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

[hidden email] wrote: I'm afraid you misunderstand. I'm not talking about joining the forks
together, I'm talking about forks as such being no longer necessary.

After all, if all images are built from a collection of packages (*not*
a core image+packages, I include building the kernel from packages like
Spoon) then what exactly will distinguish an official Squeak, Cuis or
Pharo image from each other or any random image someone makes? Only the
stamp of approval put on them by the owner of the build configuration.
Of course, some people may see these builds as forking but I don't see
it that way since all that changes is the arrangement of packages, not
the code itself.

This is looking a fair bit into the future though...

When you say "If all images are built from a collection of packages" you
are presuming what you are trying to prove. I believe that will never
happen. It might happen for Squeak (I won't hold my breath), but why would
other people adopt that process?

You say that the code itself doesn't change. Forks exists because people
want to change the code!

As I said before:
"if you believe you have the magic recipe to join them, you're wrong."
"Do forks want to join?" "Do forks want to adopt this process and tools?"
For some, the answers might be "yes". For others, they might be "no, thanks".

Cheers,
Juan Vuletich

On Jul 16, 2009, at 7:53 AM, Keith Hodges wrote:

I'm not much use around here, but on this I can try to help.  I can  
barely begin to compile a list of contributions of every version of  
MC (Madonna Ciccone) that had ever existed, but I shall try:

In no particular order, Contributions of Every Version of MC (Madonna  
Ciccone) that has ever existed

1.  Pop songs ("True Blue," "Holiday," etc.)
2.  Dance hits ("Into the Groove," "Vogue," "Ray of Light," etc.)
3.  Posters, magazine covers for teenagers
4.  Controversy
5.  Wholesome films
6.  Not-so-wholesome films
7.  Fashion
8.  Books
9.  Children
10.  Dance moves
11.  Gossip
12.  Increasing the public's awareness of obscure religions
13.  Charity work
14.  Women's rights
15.  Divorce settlements
16.  Business obligations
17.  More!

Whew!  I'm out of breath.  Madonna has contributed so much through  
her many reformations and re-inventions.  It is hard work to compile  
them all.  I am sure I left a few out!  If I need to post a .cs of  
this somewhere please let me know.

HTH,
Tim

Guys, come on. Let's focus!

Tim, I'd like to suggest you to write tests and commit to
http://source.squeak.org/tests/, rather than spending time writing
such email to Keith. That'd be a better way to make a statement.

At least we can say that you know a lot about Madonna. :)

All the best,
Ian

--
http://mecenia.blogspot.com/

Ian Trudel wrote:
> Tim, I'd like to suggest you to write tests and commit to
> http://source.squeak.org/tests/, rather than spending time writing
> such email to Keith. That'd be a better way to make a statement.

Indeed. And that goes both ways. Anyone who does *not* agree with the
trunk model they should contribute using Keith's framework! At the end
of the day my goal is not to be "right" - my stated goal is to improve
the contributions to Squeak. If that means people start contributing in
different ways than I am imagining that's just fine with me ;-)

Cheers,
   - Andreas