Re: [squeak-dev] Organising and Documenting Micro-Universes in Squeaksource

Stéphane Ducasse wrote:
> Geeeee.
>
> MC is not any project, it is our key infrastructural element. So we  
> must control it.
>  
I disagree, its key to all users of squeak. So you must ensure that it
is looked after and maintained. There is absolutely no need to control
it. You can control it by contributing to it and participating in its
future development.

By competing you kill it, and you are killing it stone dead, because no
one can add a feature without being held back by the users of the other
fork(s).
> But of what are you talking? That you introduced traits support and  
> atomic loading on MC
> and that we do not consider it? But you know several people privately  
> asked us not to
> include your code.
What kind of people are you working with? How rude can people get? This
is open source for goodness sake. You aint paying for this stuff, on the
contrary, its costing me a fortune.

I have a 1977 camper van that I am currently restoring, someone once
said to me "anything you do to it, will be an improvement", well that
was the state of MC1.0.

It's about teamwork, and merging of talents. I never said I was
qualified to take on maintenance of MC, I never wanted to do it. The
fact is that MC1 is unusable, and someone had to fix it. The future of
MC depends entirely upon the contribution of a team of people, but your
attitude and the attitude of these myopic individuals precludes it,
because none of you will contribute to the team effort required.

You have a community full of people who write great code and dont write
a single class comment, and yet their often unusable contributions are
accepted without being completely insulted!
> So we pay attention.
>  
Those people have not contributed to MC either therefore their input is
completely mute and irrelevant. I have said many times before, the code
is not relevant it is the attitude that is important. If you dont like
the code then the repo is open to fix it, and the forums are available
to comment on it. Some people have found their feedback incorporated
within the hour!

People who cant be bothered to offer feedback or participate, have no
right to criticise.

Ok the tests are not up to scratch, I cant help it if whoever wrote the
tests made them incomprehensible.

When lukas loaded MC1.5 an installation error didnt completely unload
the previous version of MC1 then he complained that there were lots of
unsent messages.

I don't have time to work on MC1.5 anymore, so those who say "dont use
keiths code", are sending a huge message to anyone who cant make a
perfect contribution to the community not to bother, your contribution
will be discarded.
> When I took the time to give feedback on kernel extensions or rio this  
>  
But you never even understood what the reason behind kernel-extension
was, you criticised it and refused to use anything that depended on it,
because it wasn't perfectly what you wanted, and it contained method
overrides. That was the whole point, it was supposed to contain method
overrides. If you put all of the method overrides  for the kernel in one
place, then multiple overlapping method overrides from different
packages do not occur, there will be no conflicts. Having them in
Kernel-Extensions gives you a place to manage them and participate in
the discussion over what would be accepted or not. You didn't really
participate in that discussion, you simply said things along the line of
Kernel-Extensions includes Null therefore we dont like it, full stop.
Again you threw the baby out with the bath water.

When I stopped using Kernel-Extensions, and started using changesets to
publish exactly the same code without method overrides, all of a sudden
the same code became magically acceptable! You might be interested to
know that more than 80-90% of what was Kernel-Extensions has already
been added to pharo, so there wasnt so much wrong with it after all.
> Do you think that I'm rude because I reply to you or when I do not  
> reply?
>
>  
Its got nothing to do with replying or not.

Its all to do with your team having the expertise to get SystemEditor
working with Traits, for the good of all, but instead you spend time and
effort forking MC, for the good of yourselves, and in the process trash
a lot of time and effort expended for your benefit.

Its to do with your team forking SUnit unnecessarily etc etc
>> I consider the attitude conveyed by the words "No but we have the  
>> right
>> to choose and consider if we like it or not."  to be tantamount to
>> snobbery,
> You saw how we worked with the settings and preference discussion with  
> alain.
>  
So Alain is external to your team? He had the courtesy of discussing the
preferences ideas with the wider community, and for that I thanked him,
and added him to my "non-rude" list. Hang on... this is a list of projects, most of which dont have any code
yet, and you are talking about rejecting stuff that doesnt meet your
standards! That's exactly what I mean.

If you spec out a project, plan it, and "contribute" to the team that
works on it, then it will meet your standards by definition. Therefore
there is no need to prejudice anything with such comments as "if
'their' work its not up to 'our' standards".

That's my whole point, you get the standards you want by participating
in the process, not by looking down your nose at the contributions being
hacked by some poor old stressed out full time carer.
These "some people", are more folks who have never sent me a single
email discussing the design. And by the way Rio has had three complete
redesigns since it was first written, incorporating various feedback and
ideas.

Thankfully I have "some emails" from "some people" who like it

Keith



_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Igor,

I am not understanding your logic.

You appear to be saying that if package X has got current maintainers,
then it is not rude to make your own version of Package X. And that if
you fork a package that has no maintainer then you will be in trouble.

I am saying the opposite - that if you fork a package that has got
current maintainers, you

a) insult the maintainers,
b) you undermine the progress that they may have made,
c) you undermine any efforts thay have made to build a team and
communication around that project.
d) you prevent future progress by the existing team
e) you make extra work for the exisiting team because you dont
communicate with them and they are forced to play catch up to you all
the time
f) you send out the message that volunteering to maintain any part of
the kernel is a hapless task, and will ultimately be a waste of time and
effort.

Keith


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

2009/3/21 Keith Hodges <[hidden email]>:
no, i meant package X having no maintainers and it should be ok to
make fork of it.
The trouble begins when another package - Y is maintained, but it depends on X.
What you suppose to do with such situation?
i agree with you on that.. just read my message more carefully :)

> Keith
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>



--
Best regards,
Igor Stasenko AKA sig.

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Igor Stasenko wrote: You mean the exact situation that many of us have been in for the past
3+ years!

At a lower level, you have to have some kind of buffer package. Thats
what Kernel-Extensions was for, it was the buffer covering the multitude
of sins in the unmaintained Kernel. This can also be achieved with more
intelligent installation tools that can install things according to
rules "if this class is missing then apply this fix/changeset/package".
(btw coincidentally (or not) Sake implements such rules in it's ClassTasks)

That's what "Installer mantis ensureFix:" is all about, its a dumb way
of acheiving the same goal. The next level up in intelligence is
Installer-Scripts (which includes the current implementation of
LevelPlayingField). It  can install things specific to product/image
version. (Pharo's ScriptLoader is somewhat equivalent, for pharo only.)

If everyone who is maintaining packages A,B,C,Y that depends upon X,
manages their fixes to X in a co-ordinated manner with tools such as
Installer-Scripts, or Sake/Packages, this documents all use cases in
detail. Then the future maintainer of X has simply to look at all of the
package load definitions, and the list of fixes to his package that they
require, his work is practically done for him.

Please note that was also the explicit intention and purpose behind
allowing Sake/Packages to be non-declarative if need be. If a user has
to add a script to get a package to work in their specific context, then
Sake/Packages is providing a knowledge capture service for the developer
of X, showing exactly what is needed to get X working in all the
contexts in which it has been applied.

At a higher level, you need to consider architecting your code to be
modular and to have interface/protocol definitions, and at the highest
level you can consider doing interface/protocol negotiations, either
statically (at package load time, or dynamically at run time.

Statically is easiest -  if they have version 1 of the database use
interface A... etc, all of which Sake/Packages can do. For example I
have written a number of modules for seaside28, called the "Client
Framework", these will need to be reimplemented for Seaside29, but
should still provide the same API.

Dynamically is doable, but there is so much irrational feeling against
use of #respondsTo: #askFor:, Null, and other facilities for making this
work on a generic basis. For example Null needs to be in the kernel,
because it must be maintained in sync with the kernel and IDE, otherwise
the Kernel/IDE developers keep doing things which ruin Null's day. (stef
please take note - I know you hate Null, but it is not intended to be a
replacement for nil, it is most useful as a replacement for an entire
missing interface on a macro scale)

Going the other way, there is also help for maintaining a single package
that can be deployed in muliple different contexts. The new PackageInfo
in MC1.5 has more facilities for exporting a package, and deploying it
in different contexts. For example, you can mark methods as "squeak
only", "gemstone", "VW only" for example.

So while you code and maintain "MyPackage" in your repository, when you
save "MyPackage.squeak" it will filter out any vw only methods, or pharo
only methods. When you save MyPackage.vw it will not include classes in
MyPackage-Squeak.  MyPackage.impl filters out the tests, and
MyPackage.test saves the tests only.


...btw Igor in response to your other email about splitting up MC.

MC1.5 has already been organised into categories for potential splitting
up. For example separation of Model and GUI. The tests have already
departed. The Monticello-Orphanage is intended to be unloadable.

I was planning to split out the PasswordManager into a  system project
"System-Passwords".

Keith









_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

>> But you never even understood what the reason behind kernel-extension
> was, you criticised it and refused to use anything that depended on  
> it,
> because it wasn't perfectly what you wanted, and it contained method
> overrides.

This was feedback and explanation for YOU of why we did not include it.

> That was the whole point, it was supposed to contain method
> overrides. If you put all of the method overrides  for the kernel in  
> one
> place, then multiple overlapping method overrides from different
> packages do not occur, there will be no conflicts.


> You didn't really
> participate in that discussion, you simply said things along the  
> line of
> Kernel-Extensions includes Null therefore we dont like it, full stop.

No I gave you feedback.
Who else by the way? **I** sat with damien and we together read the  
code and sent it.


> When I stopped using Kernel-Extensions, and started using changesets  
> to
> publish exactly the same code without method overrides, all of a  
> sudden
> the same code became magically acceptable! You might be interested to
> know that more than 80-90% of what was Kernel-Extensions has already
> been added to pharo, so there wasnt so much wrong with it after all.

Not that much. I checked.

>>
> Its got nothing to do with replying or not.

Yes it is because I can ignore you completely too.

> Its all to do with your team having the expertise to get SystemEditor
> working with Traits, for the good of all, but instead you spend time  
> and
> effort forking MC, for the good of yourselves, and in the process  
> trash
> a lot of time and effort expended for your benefit.

We are not doing that. We are running after time.

> Its to do with your team forking SUnit unnecessarily etc etc

It is not my team, it is people with busy agenda not having the time  
to look at other packages

Good!

>>
> Hang on... this is a list of projects, most of which dont have any  
> code
> yet, and you are talking about rejecting stuff that doesnt meet your
> standards! That's exactly what I mean.

No I just warn you so that you do not get frustrated again.

> If you spec out a project, plan it, and "contribute" to the team that
> works on it, then it will meet your standards by definition. Therefore
> there is no need to prejudice anything with such comments as "if
> 'their' work its not up to 'our' standards".

Exact!
Keith hold on a moment. you are spining on yourself.
We have a lot of deadlines, a lot of administration, I do pharo on my  
free time
often the evening, I have no time to code what I want for my research,  
I fight
all the time to get money, I have a huge pile of unfinished todos. So  
we all
have more or less the same. So my contributions to something will be  
nearly null.
Do you think that lukas can do more than seaside pier, phd, paper and  
books?
Do you think that alex can do more than a start up, writing paper,  
fixing our code base on moose?

> That's my whole point, you get the standards you want by participating
> in the process, not by looking down your nose at the contributions  
> being
> hacked by some poor old stressed out full time carer.

But with the time constraints I have give feedback is the only thing I  
can do right now.
Else I would have wrote another rio and lot more.

I imagine that too.


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Guys,

Let me say few words from my experience, because such fork actually
happened to Swazoo, which maintainer I am. So, was I insulted? Well, I
was surely not happy, but insulted? No!

I took that as a competitive pressure to be even better with main Swazoo
line. To prove therefore with deeds that our branch is the best.

So please, don't mix competition with insulting. Use the competitive
pressure (anger if you wish) to ride on it and be even better! Prove
yourself with your work!

Community is wise enough to be able to choose the best contender at the
end. If you are chosen, celebrate, if you are not, analyze situation and
be better next time, but don't give up, and specially don't feel insulted!

Best regards
Janko



Keith Hodges pravi:
--
Janko Mivšek
Svetovalec za informatiko
Eranova d.o.o.
Ljubljana, Slovenija
www.eranova.si
tel:  01 514 22 55
faks: 01 514 22 56
gsm: 031 674 565

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Janko Mivšek wrote: Again its not about the technical choice, its about the philosophical
principle. Let me make this clear.

"I spent a year of my time on tools and ideas that may benefit all, only
only only only only only only if all choose in principle to use those
ideas." (we sort out the technical details in the end).

Check through my last email, and look at what it means to the community
if Pharo doesnt adopt MC1.5 and SUnit improved ideas (notice I said
ideas, its not just limited to code).

1. You/I will have to manage a separate project JUST for pharo. The
new(1 year old) PackageInfo-Base would allow you to export.
MyPackage.pharo from your main distribution.

2. You will have to manage a separate test suite JUST for Pharo. The
SUnit-improved is designed to allow tests to be marked and categorised
as to what should work where. This scheme should also apply to other
testing frameworks as they are integrated (SSpec).

3. You will have to manage a separate load script/universe for your
pharo code, and users will not have a place to tweak their load scripts
for pharo. Thus to support pharo you are forced to actually try loading
your code in pharo regularly. Remember pharo is a moving target, so you
will have to test it every month/week or so. IF your code ever fails to
load you will get a black mark of incompetence from the community, so
you had better keep on top of it. Meanwhile the squeak users can upload
their feedback of what is needed to make your package work in squeak
into the load scripts in Sake/Packages. Then on your next iteration you
can go and pick up the required changes, at your leisure.

If you wonder why I keep banging on about this, I have over 40 packages
that I maintain both publically and as part of my work. I have gone to
an extreme amount of effort to try and minimise the pain, and the pharo
guys are ignoring the IDEAS and the code, and therefore making
unnecessary work for everyone.

Keith




_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

janko

did we do a fork of swazoo?
I mean in pharo?
I was not aware of that.

Stef

On Mar 21, 2009, at 10:24 AM, Janko Mivšek wrote:


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

2009/3/21 Keith Hodges <[hidden email]>:
Keithy, what you proposing is change the development process pattern
which people used to do for a years now, to a new,
not yet clearly evaluated paradigms.
I think you should be aware that forcing people to change their
development style will meet a certain oppression. From your side, as
an evangelist of a new approach, it very important to show how easy &
painless the new process is going comparing to old one. Write
tutorials , show simple 1.2.3. steps etc etc. Blaming the people that
they keep using old development techniques is not the way to go.

I think that Stephane clearly understands a different problems of
software development , packaging, maintaining & distributing. What he
maybe not clearly sees is a big win from using approach proposed by
you. I hope you will find a meeting points to make interchange between
Squeak & Pharo (and other forks) be painless, fun and productive.

> Keith
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project



--
Best regards,
Igor Stasenko AKA sig.

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Hi Stef,

Stéphane Ducasse pravi:

> did we do a fork of swazoo?
> I mean in pharo?
> I was not aware of that.

No, not on Pharo and not by you the Pharo guys. Fork named Hyper was
done on VW and Gemstone.

Sorry for misunderstanding, I made a general example to show and to
recommend, what to do in such case.

Best regards
Janko


--
Janko Mivšek
Svetovalec za informatiko
Eranova d.o.o.
Ljubljana, Slovenija
www.eranova.si
tel:  01 514 22 55
faks: 01 514 22 56
gsm: 031 674 565

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

> Keithy, what you proposing is change the development process pattern
> which people used to do for a years now, to a new,
> not yet clearly evaluated paradigms.
>  
Igor,

I don't see any change in development process at all, because there is
no existing development process for writing a package that is supported
in multiple forks of squeak.
> I think you should be aware that forcing people to change their
> development style will meet a certain oppression. From your side, as
> an evangelist of a new approach, it very important to show how easy &
> painless the new process is going comparing to old one. Write
> tutorials , show simple 1.2.3. steps etc etc. Blaming the people that
> they keep using old development techniques is not the way to go.
>  
I am not forcing people to change their development style, the issue
here has nothing to do with development style.

The issue here is that I started a dialog, and I made an effort to move
what was unmaintained proprietary getting-ever-more-bespoke-per-image
code, into loadable packages, not tied to any one image, and into the
public arena, owned by the whole community, and maintained on behalf of
the whole community.

This was in response to the visionary direction expressed by all
parties, to work for smaller leaner and meaner kernel images.

The pharo team are actively and purposefully working in the opposite
direction, that's the problem.

I made a lot of effort to make that dialog possible. For SUnit that
dialog was initiated three years ago by making the repositories for
SUnit available on squeaksource with open access, and providing a dummy
SUnit that can be used to make SUnit unloadable from the main image, and
by inviting participation. For Monticello it involved a lot of work
merging all of the existing forks.

My complaint is that the pharo guys are not participating in that dialog
at all they have made no commits to that open repository. They have
rudely forked a maintained code base, and they are "we have to
maintain/take control" of code that is now community owned.

The issue has nothing to do with the code quality or otherwise, it has
nothing to do with a change in development style.

The issue is one of philosophical choices being made by the leadership
of the pharo team, as evidenced by daily contributions to the mailing
list, which promote and demonstrate an exclusive rather than
participatory attitude.

Keith



_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Keith,

Interestingly, I could make only minor modifications, and write that same paragraph with Squeak as the stone wall.  The Squeak community ignored many wonderful ideas over a period of years of maintenance and incremental development; IMHO, look there to explain the numerous forks.  Pharo has a stated objective of breaking what needs to be broken to make progress, and it's not even at a first release yet.

You seem to think that the world will be a great place if all the Squeak forks can share code.  What about VW, Dolphin, X, etc.?  In the spirit of cooperation that you demand from the alpha versions of Pharo, Squeak could have, years ago, done something about its isolation of users of other dialects via its unique handling of underscores.

The Pharo team is not being rude; they are focused on a huge task for the good of research, developers, users/customers, and Smalltalk.  There is no animosity toward Squeak; there is determination to eliminate incompatibilities and cruft in general.

Bill



-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Keith Hodges
Sent: Saturday, March 21, 2009 5:43 AM
[snip]

If you wonder why I keep banging on about this, I have over 40 packages that I maintain both publically and as part of my work. I have gone to an extreme amount of effort to try and minimise the pain, and the pharo guys are ignoring the IDEAS and the code, and therefore making unnecessary work for everyone.

Keith


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Schwab,Wilhelm K wrote:
> Keith,
>
> Interestingly, I could make only minor modifications, and write that same paragraph with Squeak as the stone wall.  The Squeak community ignored many wonderful ideas
Which is why we have finally got to a stage where the paradigm has
shifted, even up to board level.

We started with LevelPlayingField, and that enabled progress in spite of
the release team.
Since that took off, Squeak hasnt been standing still or closed to new
ideas. Nor have those that needed fixes to the image been left stranded,
with "Installer mantis". What we have lacked is a new release in image form.
> over a period of years of maintenance and incremental development;
When I fully joined the squeak community, who was running the release
team? Yes it was exactly the same guys as are the pharo team, namely
Stef, and Marcus.
> IMHO, look there to explain the numerous forks.  Pharo has a stated objective of breaking what needs to be broken to make progress, and it's not even at a first release yet.
>  
And so has LevelPlayingField, it enables you to break what needs to be
broken, because you can put the compatibility back into
LevelPlayingField if you need to.
> You seem to think that the world will be a great place if all the Squeak forks can share code.
No, but I do think it will be a horrible place if we cant, and you have
to think these things through and plan. "If you fail to plan, you plan
to fail", I think it goes.  For a start if projects like Pier and
Seaside go Pharo only, then I am really up a creek.
>  What about VW, Dolphin, X, etc.?  In the spirit of cooperation that you demand from the alpha versions of Pharo, Squeak could have, years ago, done something about its isolation of users of other dialects via its unique handling of underscores.
>  
Agreed. Underscores has been first on my list (waiting for when I get
time to hack the kernel) for three years.
> The Pharo team is not being rude; they are focused on a huge task for the good of research, developers, users/customers, and Smalltalk.  There is no animosity toward Squeak; there is determination to eliminate incompatibilities and cruft in general.
>  
What is your definition of rude then? (
http://www.everything2.org/title/Americans%2520are%2520rude )

If I make a fix to a package that someone else is maintaining, I attempt
to contact the maintainer and talk the change through with them. At the
very least I attempt to check my fix into their repo so that they can
benefit from it.

Before making Sake/Packages, I discussed with the 3.10 release team, and
the creator of Universes to see if we could adapt Universes to provide
the needed functionality. Lex refused to relax the openness of universes
or to compromise on the purely declarative approach, so Sake/Packages
was born. Its called communication and recognising that some one else
put their time and effort into solving the problem before on my behalf,
and also the antithesis of "not invented here".

Keith



_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

>
>> over a period of years of maintenance and incremental development;
> When I fully joined the squeak community, who was running the release
> team? Yes it was exactly the same guys as are the pharo team, namely
> Stef, and Marcus.

booooohhhhh we are the "vilain".....

We were trying to break as much as possible and we did a robust  
release that integrated
more than 625 bug fixes. So please respect that.
And yes you are insulting us.

Stef


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Stéphane Ducasse wrote: I didn't say that.

I was apparently being told that I shouldn't criticise you because you
are the "champions of the new way" and that the old squeak days were far
worse. When in actual fact from my perspective the old old squeak days
are irrelevant (I was using ST/X) and the recent-old squeak days were
run by you, so you are not "champions of a new way" after all, you are
champions of "your way", which is the same way that you did 3.9, but
with less stake holders.

I am not saying that "your way" is villainous. I am saying that it is a
complete straw man to use the "old old ways" of the past to justify how
wonderful "your way" is, when actually "your present way" is just the same,

Keith


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project