[squeak-dev] Cross fork development model

Recent proposition from Andreas is I think a good booster for trunk
squeak development.
However, as Keith underlined, it is not a model for cross-fork development.

You want a simple example?
Try merging source.squeak.org/trunk/Kernel and www.squeaksource.com/Pharo/Kernel
Too many methods changed... and are marked as conflicting.
Cross-fork management requires a much finer grain for sure!
We have to sharpen our tools or invent something...

Nicolas

Nicolas Cellier wrote:
> Recent proposition from Andreas is I think a good booster for trunk
> squeak development.
> However, as Keith underlined, it is not a model for cross-fork development.
>
> You want a simple example?
> Try merging source.squeak.org/trunk/Kernel and www.squeaksource.com/Pharo/Kernel
> Too many methods changed... and are marked as conflicting.
> Cross-fork management requires a much finer grain for sure!
> We have to sharpen our tools or invent something...

Actually, the changes are much less dramatic than what one might think.
After looking at it, it appears that most of the changes are either the
result of converting from underscore to colon-equals (trivial to fix) or
from integrating the closure changes. The latter is something I am
currently working on (if you updated from trunk you may have noticed
that I've added a necessary PackagInfo version that supports
preambles/postscripts) and as of yesterday, I was able to load the
entire closure bootstrap using Monticello (and then it dies when trying
to recompile everything ;-)

But in any case, I think that if you wait until (roughly) the weekend
you will find that the differences have been reduced to something quite
manageable.

Thanks for looking over this though - it is really helpful to get an
understanding about the actual differences and discuss them in context!

Cheers,
   - Andreas

Andreas Raab wrote: Looks like you have forked PackageInfo now...   this is going to descend
into chaos.... nothing is being thought through.

Having one pre-madonna developer doing stuff without thinking and
without planning is the anti-theseis of the process we need

Keith
> But in any case, I think that if you wait until (roughly) the weekend
> you will find that the differences have been reduced to something
> quite manageable.
>
> Thanks for looking over this though - it is really helpful to get an
> understanding about the actual differences and discuss them in context!
>
> Cheers,
>   - Andreas

People,

Why can't we have a migration tool to help code and packages to be
ported to newer version of Squeak or even other forks? I have
mentioned the idea in the past but nobody gave any further thoughts.
We've got this wonderful entirely reflective and dynamic programming
language, which should really make it easy (or not so difficult) to
implement a migration tool.

A package maintainer would simply run his tests, migrate, rerun tests
and see what need to be fixed, if anything.

An interesting migration tool would be ActiveRecord::Migration. Though
the obvious difference between databases and programming languages,
the concept behind it has still something appealing. One can define
migration "up" and "down" using database schema definitions. I like
the idea that we could easily port and backport code with such
definitions. Then they could be either syntactic or semantic
definitions. Definitions that could eventually be either manually
written and/or generated automatically from deltas.

All of a sudden, it would make porting code and packages something
that can be handled with little efforts. And the community would
definitively be more open to changes since it wouldn't break that much
code with such tool in action. =)

Yes|No|Abort ?

Ian.

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

And you wonder why no one seems to listen to you...

Collaboration doesn't mean everyone does it your way or they're just
wrong, nor does it involve name calling.  Andreas hit the nail on the
head earlier, you have to convince other people your ideas are good, and
get them on board with you.  Name calling is not the way to go about it.

It doesn't matter which process is better, it matters which process gets
the most support from the community and which one people are able to
understand.  If you can't tone down the bitterness in your posts, you're
never going to gather enough support to get your ideas accepted.
Thinking you're right is just not enough.

Ramon Leon
http://onsmalltalk.com

>
> And you wonder why no one seems to listen to you...
>
> Collaboration doesn't mean everyone does it your way or they're just
> wrong, nor does it involve name calling.  Andreas hit the nail on the
> head earlier, you have to convince other people your ideas are good,
I already did that ground work, Matthew and I wrote proposals, and put
them before the board, Andreas has yet to do that.
> and get them on board with you.  Name calling is not the way to go
> about it.
Do me a favour, that is not name calling.  It is a well known
characterisation of how software projects are often carried out. Its not
meant personally, its a well known label. You all know what it means,
and if the label fits, then I am justified in using the term.

I can say it another way, using the "bus coefficient". The bus
coefficient is the the number of people that, if they were run over by a
bus, would result in your project being caput. The majority of projects
have a bus coefficient of one. Its a very similar thing.

We already have several versions of PackageInfo, some maintained and
some not. There is a public repository in which a lot of work has been
carried out. Matthew improved the speed of PackageInfo by a factor of
10x. I myself moved PackageInfo and PackageOrganizer to be the master
list of loaded packages on behalf of MC. A lot of work has already gone
into this, and the decision to make MC/PI maintained as a project
external to the image was made a number of years ago. The last thing we
need is someone coming in and trashing the work we have already acheived.
> It doesn't matter which process is better, it matters which process
> gets the most support from the community and which one people are able
> to understand.  If you can't tone down the bitterness in your posts,
No bitterness here, I am pointing out the practical status  of what is
occurring. One person has summarily chosen to move the image forward in
a particular way, without considering the bigger philosophical picture.
So yet again we end up with more forks than when we started with, and
lots of work that has already been done is going to go to waste.
> you're never going to gather enough support to get your ideas
> accepted. Thinking you're right is just not enough.
Whatever, if you cant see it... I haven't got the energy to argue.

A wise person once said to me "Go where you are celebrated not where you
are tolerated".

I am making the point so that Andreas will listen to himself and reflect
upon his way of working. He is driving this thing purely on his
technical ability to code something. This is not being thought through.

Keith

> We already have several versions of PackageInfo, some maintained and
> some not. There is a public repository in which a lot of work has been
> carried out. Matthew improved the speed of PackageInfo by a factor of
> 10x. I myself moved PackageInfo and PackageOrganizer to be the master
> list of loaded packages on behalf of MC. A lot of work has already gone
> into this, and the decision to make MC/PI maintained as a project
> external to the image was made a number of years ago. The last thing we
> need is someone coming in and trashing the work we have already acheived.

This would be that sense of entitlement Andreas referred to
previously.  Just because you did work does not mean other people have
to use it.  You have to convince them to use it, if you can't, that is
your failing.  Someone not using your work is not wrong.  Someone
creating another fork is not wrong.  People are going to do what they
want to do.

> No bitterness here, I am pointing out the practical status  of what is
> occurring. One person has summarily chosen to move the image forward in
> a particular way, without considering the bigger philosophical picture.

This is not true.  He's clearly considered it and simply come to
different conclusions about the direction things need to move than you
have, he values different things than you do.  It's not a matter of
right and wrong or correct and incorrect, it's a matter of who gets
more community support and contributors.

> So yet again we end up with more forks than when we started with, and
> lots of work that has already been done is going to go to waste.

And?  Everyone has a right to fork, it's what they do when they're
dissatisfied with the way things currently work.  You seem to have
this presumption that you're right and everyone else is wrong or
misinformed.  Have you considered that perhaps you're wrong?  I'm not
saying you are, I'm just saying you come across as if that's just an
impossibility.

You're trying to wrangle all the forks into cooperation with each
other by imposing a process on them.  If all those people were good at
collaborating with each other, they probably wouldn't have forked in
the first place.  Perhaps they have enough work in their own projects
that they don't have the extra time to follow your process because
sharing everything they do in a way compatible with other forks is not
their primary goal.

Committing code to a package in a trunk is a quite common method of
collaboration among developers; far more common than submitting every
change in code into a bug tracking system so an automated build
process can pick it up.

> Whatever, if you cant see it... I haven't got the energy to argue.

If you don't have the energy to convince others that your ideas have
merit, then you shouldn't have the energy to continually criticize
others who are scratching their itch in a different manner than you'd
have chosen.

> I am making the point so that Andreas will listen to himself and reflect
> upon his way of working. He is driving this thing purely on his
> technical ability to code something. This is not being thought through.
>
> Keith

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.

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?

Ramon Leon
http://onsmalltalk.com

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.

>  Just because you did work does not mean other people have
> to use it.  You have to convince them to use it, if you can't, that is
> your failing.  Someone not using your work is not wrong.  Someone
> creating another fork is not wrong.  People are going to do what they
> want to do.
>  
Like I said before the proposal was accepted. 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.

If they change their mind then so be it, but that puts out a very
troubling message. (A bit late now I fear) 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.

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?)
>   If all those people were good at
> collaborating with each other, they probably wouldn't have forked in
> the first place.  Perhaps they have enough work in their own projects
> that they don't have the extra time to follow your process because
> sharing everything they do in a way compatible with other forks is not
> their primary goal.
>  
Since most of their work is not done on changing the kernel, that
doesn't really matter.

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.
> Committing code to a package in a trunk is a quite common method of
> collaboration among developers; far more common than submitting every
> change in code into a bug tracking system so an automated build
> process can pick it up.
>  
We are not developing, we are integrating already completed stuff.
>> Whatever, if you cant see it... I haven't got the energy to argue.
>>    
>
> If you don't have the energy to convince others that your ideas have
> merit, then you shouldn't have the energy to continually criticize
> others who are scratching their itch in a different manner than you'd
> have chosen.
>  
I agree. 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.

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

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

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.

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.

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

Cheers,
   - Andreas

Keith Hodges pravi:

> A wise person once said to me "Go where you are celebrated not
> where you are tolerated".

> I am making the point so that Andreas will listen to himself and reflect
> upon his way of working. He is driving this thing purely on his
> technical ability to code something. This is not being thought through.

Keith, just to know, I'm also on Adreas side. As a growing number of
people are, just in case you didn't noticed yet by yourself.

And as I already said and others are pointed out too: it is your
attitude which is to blame. So, maybe it is a time to listen that wise
person, and think about it! Otherwise I'm afraid you won't find much
places where you'll be celebrated anymore.

Best regards
Janko


--
Janko Mivšek
AIDA/Web
Smalltalk Web Application Server
http://www.aidaweb.si

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.

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

> Keith, just to know, I'm also on Adreas side. As a growing number of
> people are, just in case you didn't noticed yet by yourself.
>
>  
What is Andreas' side?

I am not talking about any technical issues here. I am primarily
concerned with the way some are prepared to treat others.

The board exists to provide older and wiser oversight and direction, to
what may otherwise be a chaotic situation. The board does not exist to
cause chaos, and undermine the efforts and energies of the community, or
specific members thereof.

This is an important issue for me, and this incident has shown me that
there are certain people, for whom treating others badly without even
any communication, is perfectly acceptable. Three members of the board,
have in their discussions with me indicated that they are prepared to
ride roughshod over other people's work and effort, without caring for
the consequences. This is not what the board was elected for.

I voted for members of the board to act professionally and to represent
us in a professional manner. I didn't vote for people in order to
elevate them to a position from which I could then in turn be treated in
a rude, and condescending manner.

As far as I am concerned the way Andreas has behaved in relation to the
people issue has left me with absolutely no desire to work for or with
him at all. If you are "on his side", and believe that it is ok to treat
people like this, then I have no desire to work with you either.

So basically, I am making no further contribution to "squeak" until the
board, considers its position, and publishes its articles and terms of
engagement. The rot, starts and stops at the top. If the board is
willing to treat people like this, then really they are no board at all.

This is complicated by the fact that the board is not the squeak
community, it is but one tiny part. I haven't worked out what my ongoing
contribution to the wider squeak community is going to be in the longer
term.
> And as I already said and others are pointed out too: it is your
> attitude which is to blame. So, maybe it is a time to listen that wise
> person, and think about it! Otherwise I'm afraid you won't find much
> places where you'll be celebrated anymore.
>
> Best regards
> Janko
>  
You are on the webteam, perhaps you would do well to realise that you
are one election away from being replaced without consultation or
consideration. If you go on holiday, be prepared for all your work to be
replaced while you are away.

this is simply not an acceptable way for our elected board to behave,
and those who think that it is should resign forthwith.

Keith

---

Looking for the perfect gift? Give the gift of Flickr!

 
And just in case people are in any doubt about the board's
mal-functioning in its role as oversight and co-ordination.

The number of emails from the board or board members discussing release
issues with the release team in June, on the release list = 0 emails.
The last communication with any member of the board was recieved on 6th May.

Then the release team is accused of not producing an image.... when the
proposal clearly states that the image is not the deliverable being
worked upon. (move the goal posts why don't you).

The release team is then accused of not making contributions easy, when
the mantis process had just been completely automated for the first time
ever.

All of a sudden, the board is saying we want a new image, when a year
ago they were saying, don't bother with 3.11 since spoon aka Squeak 5.0
will be released in a month.

Keith

Ramon Leon wrote:
Agreed. Forks have their reasons to exist. They are not a bad thing. And
if you believe you have the magic recipe to join them, you're wrong.
Each fork might have different reasons. For example, it looks like Pharo
exists because of people issues, not technical. So most likely, they
will not want to join back with Squeak, no matter what process we have.
As another example, Cuis, my own fork exists because I want to clean the
Squeak kernel. So, it can _not_ use the Squeak kernel! Before designing
the whole process after the idea of joining forks, we should ask "Do
forks want to join?" "Do forks want to adopt this process and tools?"

Cheers,
Juan Vuletich

Keith Hodges wrote:
> What is Andreas' side?

It's the attempt to find a development model that will work for our
community. I'm trying to find alternative ways to contribute in order to
lower the barriers of contribution and enable more people to contribute.
We have Mantis which works well for a particular type of contribution,
but from my perspective it is too difficult to use for others.
Consequently I'm looking for alternatives - such as a shared community
repository with a fairly open commit policy that people can just
contribute to.

> I am not talking about any technical issues here. I am primarily
> concerned with the way some are prepared to treat others.

 From my perspective, I treat others in this discussion like I would
like to be treated myself. I am asking for help without attempting to
tell others what they can and cannot do. I'm doing this since I am in
this (just like most of us) as a fun little side project. I'm not
getting paid for any of my contributions here, so nobody is in a
position to tell me what to work on or how to work on it. And neither am
I in a position to tell anyone else. What I can do, is invite people to
contribute. What I can do is try to make it attractive to contribute.

Cheers,
   - Andreas

The title of this discussion is "Cross fork development model" and I'd
like to bring it back for a second. Your attention, please.

My understanding is there are no official statement from any fork in
effect that they are willing to be involved into such cross fork
efforts. They might or might not be interested to rebranch with Squeak
at later time. Except, perhaps, people from Etoys expressed some
interest in this idea.

The question arise to know whether or not the leaders of other forks
are hand-in-hand with Squeak Oversight Board to ensure the viability
of this effort.

Provided that it would not be the case, why on earth are we wasting
time on this while the community have more pressing needs?

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

2009/7/15 Juan Vuletich <[hidden email]>:
My initial question was not whether to un-fork.
It was how to re-use as much as possible code across forks (like a
kernel improvment or a bugfix).
It's rather a question of using ad hoc tools, and yes, I wish the
discussion took a more technical angle on some detailed examples.

Maybe some simple Installer snippets can help like:
Installer squeakTrunk applyDeltasVsAncestorOf: 'Kernel-ar.185'.

Nicolas

> Cheers,
> Juan Vuletich
>
>

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

2009/7/15 Ian Trudel <[hidden email]>: