Hi Göran,

first I want to thank you for your constructive and encouraging reply!

goran.krampe at bluefish.se wrote:
> Hi Stephan!
> 
> Stephan Rudlof <sr at evolgo.de> wrote:
> 
>>Hi Göran,
>>
>>goran.krampe at bluefish.se wrote:
>>
>>
>>>...
>>
>>>And I can at this time, for anyone still reading, mention that I
>>>yesterday executed two unit tests green that made the very first partial
>>>dependency analysis. New class called SMDependencyEngine.
>>
>>This is nice for you. And for me, too, if deps are finally coming into SM.
>>
>>But this is also discouraging for my own coding: last night I've started
>>with classes
>>  DepSVersion, DepSTransformation, DepSPerformer,
>>but now I think it makes no sense to continue.
> 
> 

> Well, I needed to start coding a bit to get my thoughts down into
> something concrete, see below.

I understand.

>  
> 
>>My idea has been to just make a backend with a clearly separated
>>interface to be used by SM and other tools, with the main target SM.
> 
> 
> Similarly I have tried to keep my code separated like this:
> 
> 1. The representation of configurations as I have described. They are
> attachable resources to the releases. So this code is
> modifications/additions to the SM base model. Both adding code to handle
> generic resources as has been planned a long time, and also added
> specific resource SMPackageReleaseConfiguration.
> 

> 2. The dependency engine which is a separate class. This means different
> engines/logic/algorithms should be easily written using the basic
> information available in the map (mainly the releases with their
> attached configurations and their compatibility level categories (the
> thing you elected to reflect in the version numbers)).

Such a separation is good.

> 
> 
>>But if you have started to make your own thing, why should I continue?
> 
> 
> Well, I have been "making my own thing" since 2002 in this area -
> although I haven't written specific code until now. :)

I have just meant the dependency mechanism, but I think you know that.

> 
> 
>>To compete with a part of software from you, where you decide to use
>>yours or mine? I know, which I would use in such a situation...
> 
> 
> This is of course an unfortunate scenario. Let us instead see if our
> ideas can be merged and if we can collaborate - as I have wanted all
> along. I would definitely *NOT* stomp all over the very first person
> stepping up wanting to collaborate with me on this.

This sounds good and is encouraging for me!

> 
> My coding so far has not been a "decided course" - but as I said - I
> needed to get some code written to clear my own head and to be able to
> experiment.

I understand.
But there are other valuable approaches, too. E.g. at my job I've made
just concepts for about a year and nevertheless the domain so far hasn't
been precisely described, since it is *very* complex. There are other
reasons for this long time, too (it is a rotten project). But now there
is the time to start with software development there: before it hadn't
made any sense!

Since the domain of a package versioning system is not so simple and
there are in addition many social aspects to taken into account, I've
first written down my thoughts in a conceptual manner, and look for
feedback now.

In your head your view of the domain is much clearer, of course, since
you have written SM...

> 
> 
>>Don't understand me wrong: I can understand that you've just started
>>without making yourself dependent from others.
> 
> 
> The reason for starting was just because I got tired of thinking with a
> pen and pencil.

I understand. But since you have posted your efforts kind of a result ..

<from another mail>
> And I can at this time, for anyone still reading, mention that I
> yesterday executed two unit tests green that made the very first partial
> dependency analysis. New class called SMDependencyEngine.
> 
> So dependencies are finally hitting the code!  :)  But since it is
> currently such a hotly debated area I can't promise anything regarding
> how/when/what will go into the public SM.

.. I've been thinking as I did:

> 
> 
>>Possibly I've misinterpreted your call for help in this area.

> 
> 
> No, you didn't. Let me prove that by replying to your DEPS article.

OK. I've seen, that you already have replied to it (please be patient
with me, don't currently know when I have time to reply to the reply ;-) ).

> And
> I hope you can take my criticism - because there will be a bit of that,

Constructive criticism is good!
Four eyes are seeing more than two, so just in complex domains it is
good to have more people looking onto the concepts. Especially in
domains where the others have to live with a result much *visible* to them!

I think that getting the graph traversing stuff running well is not
simple, but compared with having to solve these other issues it seems to
me to be a small problem. I also think that you will be faced with some
of the principal problems I've mentioned in the paper, independently
from the chosen *technical* solution.

So please take my criticism of *your* concepts - I'm expecting there
will be some - as fight for the best practical solution: I'll always try
to make *arguments* in whatever direction.
I'm also aware of that there always will be some trade off: but for good
decisions the variants should be as clear as possible.

> and then we can borrow/build from there? :).

This sounds promising.

> 
> And then we can start sharing using Monticello when we have boiled this
> down to a first shot.
> 

> You can reply to me in private or on the list - and or join #squeak on
> irc.freenode.org where I am.

I've never used irc so far, but this could be a reason for starting with
it...


Greetings
Stephan

PS: Away to my job...

> 
> 
>>Greetings
>>Stephan
> 
> 
> regards, Göran
> 

-- 
Stephan Rudlof (sr at evolgo.de)
   "Genius doesn't work on an assembly line basis.
    You can't simply say, 'Today I will be brilliant.'"
    -- Kirk, "The Ultimate Computer", stardate 4731.3