Hi
SM has been a success story so far. Just this morning I threw up a package loader after a long pause using Squeak and I could instantly load one of the 400 existing packages. This would have been unthinkable three years ago. Congratulations Göran and the others who helped to put this in place.
As for centralization / decentralisation: SM is basically a catalogue and having just one instead of several is surely a great advantage. Especially if we currently still deal with a few hundered packages and two hundred developers (which is encouraging though).
The packages themselves are in various places (though cached in SM AFAIK) and they have a unique ID. So it is possible to create build scripts with repeatable results which is really necessary for working in an environement like Squeak which is in constant flux.
And SM supports different source managment systems. Currently there are 5 package formats http://map1.squeakfoundation.org/sm/category/93f6630c-58a6-42c5-9eb0-a43017b...
SM is a catalogue with 200 people maintaing the entries - from a organizsational viewpoint this is far from beeing a centralized solution.
But it works and it works fine.
Cheers Hannes
Hi Hannes and all!
Hannes Hirzel hirzel@spw.unizh.ch wrote:
Hi
SM has been a success story so far. Just this morning I threw up a package loader after a long pause using Squeak and I could instantly load one of the 400 existing packages. This would have been unthinkable three years ago. Congratulations Göran and the others who helped to put this in place.
Thanks!
As for centralization / decentralisation: SM is basically a catalogue and having just one instead of several is surely a great advantage.
I think so. Sure, we should strive to add the possibility of SM objects with limited visibility (read company/organization/individual etc) but I do not want to sacrifice the power of having ONE model/catalog.
<autotriggered rant not aimed at Hannes :) >
I repeat again what I have written a bunch of times already - distributing/splitting a catalog over disparate unknown servers, forcing the user to find the servers and somehow "collect" information from them - and not knowing if there are even more servers out there somewhere that he/she has missed.... well, it is simply a bad idea IMHO.
The only good reason for having multiple servers is the visibility argument (the ability to have private packages etc), but I still want to know how to get that without sacrificing tons of other good things we have today.
</rant>
Especially if we currently still deal with a few hundered packages and two hundred developers (which is encouraging though).
I think we can cope with more. The map is still quite small - and if we move it to an incremental model (not having to download a full snapshot every time) we should be able to handle LOTS of objects.
Note that Debian just recently added "categories" (they call them debtags and I almost called categories "tags" too when I wrote the first SM) and AFAIK they have more than 12000 packages in Debian proper.
The packages themselves are in various places (though cached in SM AFAIK) and they have a unique ID. So it is possible
Only cached on the client at this point, though the server side cache has been written but still sitting in my development image. The client will first try the original URL and then falls back on the server cache if that fails.
to create build scripts with repeatable results which is really necessary for working in an environement like Squeak which is in constant flux.
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.
And SM supports different source managment systems. Currently there are 5 package formats http://map1.squeakfoundation.org/sm/category/93f6630c-58a6-42c5-9eb0-a43017b...
Yes, and if there are others out there that people would like to add - just holler. IIRC someone mentioned sucking releases straight out of StORE a while back?
SM is a catalogue with 200 people maintaing the entries - from a organizsational viewpoint this is far from beeing a centralized solution.
But it works and it works fine.
Cheers Hannes
Cheers!
/Göran
Hi Göran,
goran.krampe@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.
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.
But if you have started to make your own thing, why should I continue? 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...
Don't understand me wrong: I can understand that you've just started without making yourself dependent from others.
Possibly I've misinterpreted your call for help in this area.
Greetings Stephan
...
Hi Stephan!
Stephan Rudlof sr@evolgo.de wrote:
Hi Göran,
goran.krampe@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.
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)).
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. :)
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.
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.
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.
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. And I hope you can take my criticism - because there will be a bit of that, and then we can borrow/build from there? :).
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.
Greetings Stephan
regards, Göran
Hi Göran,
first I want to thank you for your constructive and encouraging reply!
goran.krampe@bluefish.se wrote:
Hi Stephan!
Stephan Rudlof sr@evolgo.de wrote:
Hi Göran,
goran.krampe@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:
- 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.
- 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
Hi Stephan and all!
Stephan Rudlof sr@evolgo.de wrote:
Hi Göran,
first I want to thank you for your constructive and encouraging reply!
Well, "I try my very best". :) (a quote from a hilarious sketch that is shown on TV in Sweden every new years eve)
[SNIP]
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.
Yes, and I actually meant that too. :)
I think my plan originates from OOPSLA2002, and many things I have done in SM since then has had it in mind. But it is only recently of course that I have reached the point where coding is useful. For example, there was no point in coding for dependencies earlier when we didn't have releases. And I still hesitate slightly to go for it without first having modifiable local maps, which would make it much easier to integrate the posting of configurations from users into the Squeak tools.
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!
It should. :)
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.
Which is a good approach.
In your head your view of the domain is much clearer, of course, since you have written SM...
Well, I am not sure. :)
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:
Well, reasonable. But as I said - we will not take anything into "deployment" until we are in some form of agreement I think. Of course, everyone can't be happy - for example, Lex and I seem to be quite far from each other regarding this (my perception is that he wants dependencies per package and I *really* want them per releases, etc) - so we will just have to see where it leads.
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!
Yes, but hard to write and hard to read without people getting a little bit hurt. :)
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.
Well, yes and no. The graph traversal in itself is of course not *that* hard (but not trivial eiher) - but there are so many other parameters in this problem so it turns quite complex. For example, I have now code that seems to be able to find all possible non-conflicting sets of releases that needs to be installed as prerequisites for a given set of releases. Ok, but:
- How can/should we choose from the calculated scenarios? They need to be rated somehow.
- What if there is no scenario found? Then the "tweaking" begins - perhaps try 1.01 instead of 1.0 of package X? But there may be multiple such tweaks for multiple of the scenarios. How do we find the most suitable tweaks to offer the user?
etc etc. Of course, everything is "doable". But there are *many* degrees of freedom here that needs to be considered.
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.
Sure.
and then we can borrow/build from there? :).
This sounds promising.
I hope you are still positive after reading my DEPS-reply. :)
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...
I hadn't used it earlier either - but I have grown to like it a lot. It is nice to be able to exchange thoughts a bit more swiftly and it strenghtens the "community feeling" in Squeak. I almost daily talk with Craig, Jecel, Brian, Ken, Avi, Bryce, Ragnar, Cees, Marcus, Doug etc on that channel. And I still don't understand why so few show up!
Greetings Stephan
regards, Göran
squeak-dev@lists.squeakfoundation.org