Igor Stasenko wrote:
> 2009/3/21 Keith Hodges <keith_hodges at yahoo.co.uk>:
>   
>>> I think you have a full right to decide what [not] to include in Pharo.
>>> Keith mentioned that you making many changes to many different parts
>>> of system , which supposed to be maintained by original authour(s) or
>>> currently active team(s), without giving a feedback or credit or
>>> consulting with them about promoting such changes.
>>> Okay, i think you're not stepping into other's domain.. it would be rude..
>>> But its going to be tricky, when you change the package X (not
>>> maintained by anyone), from which depends a lot of work, which doing
>>> in parallel by other team for package Y, which depends on X.
>>> Here lies the problem, which can be solved by communicating with
>>> people. Of course it requires the good will of both sides :)
>>>
>>>
>>>       
>> 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.
>>
>>     
>
> 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?
>   
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