Ramon Leon wrote:
>> 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. 
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.
>> 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.
>   
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)
>> 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.
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.
>> 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.
>   
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