Hi I would like that you think a bit about our community and that there is a value in using common tools to share and develop common libraries. Because to me it feels like we are getting balkanize. It may look super cool and be hyper trendy to use github (because like that you can say that you use latest hyper cool features), but I would like to ask especially people building libraries to pay attention that it is important that other people can contribute back easily and that there is an easy way to load/contribute. Today I experienced Bloc - I cannot load code and I cannot contribute. - I saw mdl with a mixture between smalltalkhub and github (sounds super hyper cool) and I saw paul not being able to contribute :( Yes you can say that monticello sucks yes it is terrible yes we all fell like Cobol programmers but at the end of the day. Yes the herb is always greener elsewhere. Yes yes yes. Let us take some facts. We managed pharo and moose with it over the last 8 years successfully and Pharo and moose are not 5 packages together from what I can see. So pay attention about the decision you take. Now we will provide git support (this is 8 months that nicolas is exclusively working/thinking/dreaming about that) and that we are doing experiments (Guille is managing the bootstrap in github). Now when everybody will have its own little project lost on github (I do not count the amount of time I do not find pillar on github because I forget that it is called pillar-markup), what will we do. So we need an infrastructure to handle this and christophe is working on this. I think that you should consider the accidental complexity as something that we can minimise by using patterns and common practices. Now you can think that I'm an idiot and that I have no vision (be my guest) but we should pay attention because we are a small community. Stef
It may look super cool and be hyper trendy to use github (because like that you can say that you use latest hyper cool
features), but I would like to ask especially people building libraries to pay attention that it is important
that other people can contribute back easily and that there is an easy way to load/contribute.
Indeed Git and Github are hypercool and trendy but the important question here is why. Why C++ is so popular, why Java is so popular, why Javascript is so popular, Why python is so popular. When you ask why you understand that being hyper cool, its not a thing, its not something you can glance over its a practical need we needed a language that is super fast with ability to handle complex code, C++ we needed a language that is focused on enterprise development , Java we needed a language to make web developent, Javascript we needed a language to simplify C/C++/Java and C# without losing libraries, Python we needed a superfast decentralized versions control systems for both code and other assets , Git we needed a place to host online open source projects with git , Github we needed the perfect language , the perfect libraries a tool to end all tools , Nothing each one of those hypercools excel in what you are doing, in many cases they are more than one, not because they are easy but because they are powerful. To go back to old alternatives would be like going back to caves because you have hard time opening the front door of your house. You may choose to go back to the cave but do not expect people to follow you. You preach people not to leave the comforts of the nest because its safe and it easy, but in the end I find that as wasted potential. The question I am asking myself everyday how far can Pharo go with taking advantage of modern technology, how far Pharo can go if it gains access to the same exact resources as all other programming languages ? What would it mean for the average Pharo developer to be able to use not just web dev libraries but any library, any tool , any programming language , any time ? If you can answer these questions then you know why embracing git and github is the right choice even if it pains you, even if makes you lose sleep sometimes or even if you find it hard. Just because Smalltalk is an island, Pharo does not need to be one. Afterall .... Pharo is not Smalltalk, or so we claim Its time to put our money where our mouths are.
Dimitris better reread what I wrote because you missed it. My point is let us minimize the mess and act in a concerted way. Do you think that we would pay 9 months of dev + esteban that will started to push there too and base all our dev on it if we would not believe that moving to git is stupid! Can you read what I write? Stef Le 6/11/16 à 13:05, stepharo a écrit :
Hi
I would like that you think a bit about our community and that there is a value in using common tools
to share and develop common libraries. Because to me it feels like we are getting balkanize.
It may look super cool and be hyper trendy to use github (because like that you can say that you use latest hyper cool
features), but I would like to ask especially people building libraries to pay attention that it is important
that other people can contribute back easily and that there is an easy way to load/contribute.
Today I experienced Bloc
- I cannot load code and I cannot contribute.
- I saw mdl with a mixture between smalltalkhub and github (sounds super hyper cool) and I saw paul not being able to contribute :(
Yes you can say that monticello sucks yes it is terrible yes we all fell like Cobol programmers but at the end of the day.
Yes the herb is always greener elsewhere. Yes yes yes. Let us take some facts.
We managed pharo and moose with it over the last 8 years successfully and Pharo and moose are not 5 packages together from
what I can see. So pay attention about the decision you take.
Now we will provide git support (this is 8 months that nicolas is exclusively working/thinking/dreaming
about that) and that we are doing experiments (Guille is managing the bootstrap in github).
Now when everybody will have its own little project lost on github (I do not count the amount of time I do not find pillar on github because I forget
that it is called pillar-markup), what will we do.
So we need an infrastructure to handle this and christophe is working on this.
I think that you should consider the accidental complexity as something that we can minimise by using patterns and common practices.
Now you can think that I'm an idiot and that I have no vision (be my guest) but we should pay attention because we are a small community.
Stef
If you really want to embrace Github , kill Smalltalkhub. Smalltalkhub should have been dead years ago. Its unmaintained anyway apart from when it crashes and Esteban fixes. Smalltalkhub has been a constant state from crashes since 2011 when I joined Pharo community. Give people a month to move their projects in github and then kill it. At worst give only read access the same way squeakers made the old squeaksource read only. Another thing that must be fixed is the file format chosen for git, the idea to fragment source code to a billion diffirent source code files each one containing a method or class definition is problematic both for viewing those files offline and online. There is very little chance that if I give a link to my github repo to an outsider to take a look at my code that he will have the patience to navigate 10 files to read the code for 10 methods. Even the class comment is a separate file. I don't even have the patience to do that. Make an organisation for people to join, those are made inside github we have one for the books we have none for the community , this way we can gain easier visibility of source code and it will also make easier for people to contribute to third party code. Move the meta repos of Pharo to Github and remove "meta" from the name. Instead name them Pharo Packages Catalog as we do inside the image. One repo for all versions of Pharo. Branches can be used to separate versions. Add to Playground the ability to paste code directly to Gist. This is a low priority one but its a nice touch. A biggy one is the pharo repo of the pharo image on github. Its a mess. https://github.com/pharo-project/pharo-core/commits/6.0 seriously, Github makes us visible , this does not look good at all. If you do all the above you will have reduced the pain of working with Git by 80%. On Sun, Nov 6, 2016 at 4:37 PM stepharo <stepharo@free.fr> wrote:
Dimitris
better reread what I wrote because you missed it.
My point is let us minimize the mess and act in a concerted way. Do you think that we would pay 9 months of dev + esteban that will started to push there too
and base all our dev on it if we would not believe that moving to git is stupid!
Can you read what I write?
Stef
Le 6/11/16 à 13:05, stepharo a écrit :
Hi
I would like that you think a bit about our community and that there is a value in using common tools
to share and develop common libraries. Because to me it feels like we are getting balkanize.
It may look super cool and be hyper trendy to use github (because like that you can say that you use latest hyper cool
features), but I would like to ask especially people building libraries to pay attention that it is important
that other people can contribute back easily and that there is an easy way to load/contribute.
Today I experienced Bloc
- I cannot load code and I cannot contribute.
- I saw mdl with a mixture between smalltalkhub and github (sounds super hyper cool) and I saw paul not being able to contribute :(
Yes you can say that monticello sucks yes it is terrible yes we all fell like Cobol programmers but at the end of the day.
Yes the herb is always greener elsewhere. Yes yes yes. Let us take some facts.
We managed pharo and moose with it over the last 8 years successfully and Pharo and moose are not 5 packages together from
what I can see. So pay attention about the decision you take.
Now we will provide git support (this is 8 months that nicolas is exclusively working/thinking/dreaming
about that) and that we are doing experiments (Guille is managing the bootstrap in github).
Now when everybody will have its own little project lost on github (I do not count the amount of time I do not find pillar on github because I forget
that it is called pillar-markup), what will we do.
So we need an infrastructure to handle this and christophe is working on this.
I think that you should consider the accidental complexity as something that we can minimise by using patterns and common practices.
Now you can think that I'm an idiot and that I have no vision (be my guest) but we should pay attention because we are a small community.
Stef
On 6 Nov 2016, at 16:27, Dimitris Chloupis <kilon.alios@gmail.com> wrote:
A biggy one is the pharo repo of the pharo image on github. Its a mess.
https://github.com/pharo-project/pharo-core/commits/6.0
seriously, Github makes us visible , this does not look good at all.
why not ? how is this different from a multi file commit in any other language ?
The commit messages, say nothing about the commits On Sun, 6 Nov 2016 at 17:47, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 6 Nov 2016, at 16:27, Dimitris Chloupis <kilon.alios@gmail.com> wrote:
A biggy one is the pharo repo of the pharo image on github. Its a mess.
https://github.com/pharo-project/pharo-core/commits/6.0
seriously, Github makes us visible , this does not look good at all.
why not ? how is this different from a multi file commit in any other language ?
Hi Stef, I think that you are raising a valid point, and I actually agree with it. But I think there is another side of the coin as well. I think that right now we are in between worlds and this is not quite beneficial. Switching to GitHub is a significant effort, and treating it as business as usual will not work. That is why I think it is so important that we committed to the move for Pharo 7 and that we invest in the infrastructure. But, this will not be enough either if we do not get people to exercise it as soon as possible. To give an example. When the first version of Iceberg was announced, I started to use it for a couple of projects. I stumbled across problems that prevented me from working for several weeks. I could have easily switched to SmalltalkHub, but I did not. I connected with Nicolas and we worked through those problems. Btw, Nicolas is doing a wonderful job, and people should not take this for granted. He tends to be shy, so if you see him around, please give him a hug and let him know that we count on him. Or better yet, use Iceberg for your projects and send him your feedback :). I am sure that there are more problems ahead, and the only way to go through them is committing to go through them. This will push us back for a while, but I really believe in the promise once we get on the other side. I actually think that GitHub is not really a good match for Pharo from a conceptual point of view (the mismatch between what it offers and what we need is quite large), but it is an engineering decision that makes perfect sense for the future. So, yes, we should take GitHub with a grain of salt, and make it a goal to not change much our concept of what makes sense for Pharo. For example, we should not give up on having to resort to the file system. That is why it is so important to make Iceberg (this is not for you Stef because I know you know it, but for others :)). And I certainly agree that we should look for sane patterns, but as it goes with patterns, they emerge out of practice. I think we should aim for limiting the time of being in between the two worlds. It will not be pleasant, and we can only do it if we stick together and go through it as soon as possible. Cheers, Doru
On Nov 6, 2016, at 1:05 PM, stepharo <stepharo@free.fr> wrote:
Hi
I would like that you think a bit about our community and that there is a value in using common tools
to share and develop common libraries. Because to me it feels like we are getting balkanize.
It may look super cool and be hyper trendy to use github (because like that you can say that you use latest hyper cool
features), but I would like to ask especially people building libraries to pay attention that it is important
that other people can contribute back easily and that there is an easy way to load/contribute.
Today I experienced Bloc
- I cannot load code and I cannot contribute.
- I saw mdl with a mixture between smalltalkhub and github (sounds super hyper cool) and I saw paul not being able to contribute :(
Yes you can say that monticello sucks yes it is terrible yes we all fell like Cobol programmers but at the end of the day.
Yes the herb is always greener elsewhere. Yes yes yes. Let us take some facts.
We managed pharo and moose with it over the last 8 years successfully and Pharo and moose are not 5 packages together from
what I can see. So pay attention about the decision you take.
Now we will provide git support (this is 8 months that nicolas is exclusively working/thinking/dreaming
about that) and that we are doing experiments (Guille is managing the bootstrap in github).
Now when everybody will have its own little project lost on github (I do not count the amount of time I do not find pillar on github because I forget
that it is called pillar-markup), what will we do.
So we need an infrastructure to handle this and christophe is working on this.
I think that you should consider the accidental complexity as something that we can minimise by using patterns and common practices.
Now you can think that I'm an idiot and that I have no vision (be my guest) but we should pay attention because we are a small community.
Stef
-- www.tudorgirba.com www.feenk.com "Presenting is storytelling."
Le 6/11/16 à 17:12, Tudor Girba a écrit :
Hi Stef,
I think that you are raising a valid point, and I actually agree with it.
But I think there is another side of the coin as well.
I think that right now we are in between worlds and this is not quite beneficial. Switching to GitHub is a significant effort, and treating it as business as usual will not work. That is why I think it is so important that we committed to the move for Pharo 7 and that we invest in the infrastructure. But, this will not be enough either if we do not get people to exercise it as soon as possible.
Yes this what we decided.
To give an example. When the first version of Iceberg was announced, I started to use it for a couple of projects. I stumbled across problems that prevented me from working for several weeks. I could have easily switched to SmalltalkHub, but I did not. I connected with Nicolas and we worked through those problems. Btw, Nicolas is doing a wonderful job, and people should not take this for granted. He tends to be shy, so if you see him around, please give him a hug and let him know that we count on him. Or better yet, use Iceberg for your projects and send him your feedback :).
Yes people should try but should pay attention for libraries.
I am sure that there are more problems ahead, and the only way to go through them is committing to go through them. This will push us back for a while, but I really believe in the promise once we get on the other side. I actually think that GitHub is not really a good match for Pharo from a conceptual point of view (the mismatch between what it offers and what we need is quite large), but it is an engineering decision that makes perfect sense for the future. So, yes, we should take GitHub with a grain of salt, and make it a goal to not change much our concept of what makes sense for Pharo. For example, we should not give up on having to resort to the file system. That is why it is so important to make Iceberg (this is not for you Stef because I know you know it, but for others :)).
And I certainly agree that we should look for sane patterns, but as it goes with patterns, they emerge out of practice.
I think we should aim for limiting the time of being in between the two worlds. It will not be pleasant, and we can only do it if we stick together and go through it as soon as possible.
This why I mentioned that we should pay attention to create different versions
Cheers, Doru
On Nov 6, 2016, at 1:05 PM, stepharo <stepharo@free.fr> wrote:
Hi
I would like that you think a bit about our community and that there is a value in using common tools
to share and develop common libraries. Because to me it feels like we are getting balkanize.
It may look super cool and be hyper trendy to use github (because like that you can say that you use latest hyper cool
features), but I would like to ask especially people building libraries to pay attention that it is important
that other people can contribute back easily and that there is an easy way to load/contribute.
Today I experienced Bloc
- I cannot load code and I cannot contribute.
- I saw mdl with a mixture between smalltalkhub and github (sounds super hyper cool) and I saw paul not being able to contribute :(
Yes you can say that monticello sucks yes it is terrible yes we all fell like Cobol programmers but at the end of the day.
Yes the herb is always greener elsewhere. Yes yes yes. Let us take some facts.
We managed pharo and moose with it over the last 8 years successfully and Pharo and moose are not 5 packages together from
what I can see. So pay attention about the decision you take.
Now we will provide git support (this is 8 months that nicolas is exclusively working/thinking/dreaming
about that) and that we are doing experiments (Guille is managing the bootstrap in github).
Now when everybody will have its own little project lost on github (I do not count the amount of time I do not find pillar on github because I forget
that it is called pillar-markup), what will we do.
So we need an infrastructure to handle this and christophe is working on this.
I think that you should consider the accidental complexity as something that we can minimise by using patterns and common practices.
Now you can think that I'm an idiot and that I have no vision (be my guest) but we should pay attention because we are a small community.
Stef
-- www.tudorgirba.com www.feenk.com
"Presenting is storytelling."
On 11/6/16 1:12 PM, Tudor Girba wrote:
Hi Stef,
I think that you are raising a valid point, and I actually agree with it.
But I think there is another side of the coin as well.
I think that right now we are in between worlds and this is not quite beneficial. Switching to GitHub is a significant effort, and treating it as business as usual will not work. That is why I think it is so important that we committed to the move for Pharo 7 and that we invest in the infrastructure. But, this will not be enough either if we do not get people to exercise it as soon as possible. Doru, there are also holes in the tool set that are not being addressed ... there are a number of critical tools that need to be created and I don't see anyone working on them ....
I went through this transition 5 years ago with my tool set and with the proper set of tools approach the difficult transition will be a bit easier ... As it stands Pharo is standing with one foot in two boats ... there are the old Monticello tools and the new Git/Filetree tools and what is needed is a tool or two that can unify to both tool sets so that the transition between the two can be seamless ... these two sets of tools are not complicated and there working implementations that can be adapted to Pharo or used as a fairly detailed guide ... The confusion and frustration that I see now is not a surprise to me ... I wrote" the emails" at the beginning of this year because I saw that Pharo was finally reaching a critical point in its move to integrate git into the mainstream development environment and I knew that these types of issues were going to come up where Monticello and Git were going to create friction --- friction that can be reduced by creating some simple "unifying tools" ... I want to help, I have tried to help and I am still willing to help, but I cannot write the tools for Pharo ... Dale
Hi Dale, I think I missed your mails. I would be interested in hearing your opinion. Letâs aim for a chat sometime next week. Would this work for you? Cheers, Doru
On Nov 7, 2016, at 6:30 AM, Dale Henrichs <dale.henrichs@gemtalksystems.com> wrote:
On 11/6/16 1:12 PM, Tudor Girba wrote:
Hi Stef,
I think that you are raising a valid point, and I actually agree with it.
But I think there is another side of the coin as well.
I think that right now we are in between worlds and this is not quite beneficial. Switching to GitHub is a significant effort, and treating it as business as usual will not work. That is why I think it is so important that we committed to the move for Pharo 7 and that we invest in the infrastructure. But, this will not be enough either if we do not get people to exercise it as soon as possible. Doru, there are also holes in the tool set that are not being addressed ... there are a number of critical tools that need to be created and I don't see anyone working on them ....
I went through this transition 5 years ago with my tool set and with the proper set of tools approach the difficult transition will be a bit easier ...
As it stands Pharo is standing with one foot in two boats ... there are the old Monticello tools and the new Git/Filetree tools and what is needed is a tool or two that can unify to both tool sets so that the transition between the two can be seamless ... these two sets of tools are not complicated and there working implementations that can be adapted to Pharo or used as a fairly detailed guide ...
The confusion and frustration that I see now is not a surprise to me ... I wrote" the emails" at the beginning of this year because I saw that Pharo was finally reaching a critical point in its move to integrate git into the mainstream development environment and I knew that these types of issues were going to come up where Monticello and Git were going to create friction --- friction that can be reduced by creating some simple "unifying tools" ...
I want to help, I have tried to help and I am still willing to help, but I cannot write the tools for Pharo ...
Dale
-- www.tudorgirba.com www.feenk.com "There are no old things, there are only old ways of looking at them."
On 11/7/16 2:59 AM, Tudor Girba wrote:
Hi Dale,
I think I missed your mails. I would be interested in hearing your opinion. Letâs aim for a chat sometime next week. Would this work for you? You're not the only one :) Yes it would ... Monday is a travel day so Tuesday or beyond would work for me ...
Dale
Am 07.11.2016 um 10:40 schrieb Dale Henrichs <dale.henrichs@gemtalksystems.com>:
On 11/7/16 2:59 AM, Tudor Girba wrote:
Hi Dale,
I think I missed your mails. I would be interested in hearing your opinion. Letâs aim for a chat sometime next week. Would this work for you? You're not the only one :) Yes it would ... Monday is a travel day so Tuesday or beyond would work for me â¦
Would it make sense to make that a group conversation? Norbert
On 11/7/16 6:42 AM, Norbert Hartl wrote:
Am 07.11.2016 um 10:40 schrieb Dale Henrichs <dale.henrichs@gemtalksystems.com>:
On 11/7/16 2:59 AM, Tudor Girba wrote:
Hi Dale,
I think I missed your mails. I would be interested in hearing your opinion. Letâs aim for a chat sometime next week. Would this work for you? You're not the only one :) Yes it would ... Monday is a travel day so Tuesday or beyond would work for me â¦
Would it make sense to make that a group conversation?
I don't mind, but I do have to say that I am struggling in communicated some of the "simple concepts" ... My talk last Wednesday was my first attempt and I don't think I did a good job of communicating about some of the more complicated tasks that come up like: load specs, clone/lock/rehome, sharing local clones across multiple images, private image clones, etc. ... My inclination is to have a focused conversation with Doru to help me express the key concepts ... then a more public discussion with another straw man where we put the ideas out again ... Dale
We are developing Iceberg⦠and I know is not enough :) Which âunifying toolsâ are you referring ? I have followed very close your TOdE development⦠in a moment I was planning a migration of it for pure-pharo, just⦠lack of time as always and then later we started iceberg. now, we are in the process of defining a process ;) who works for pharo and is the moment to build the bridges we need, but in general I think that staying "with a foot in two boatsâ can just work during a very short lapse of time, after that, the stream continues going and if you do not finish your jump into one of the boats you will be very fast in the water. What I mean is that we can help any transition, but at the end there is no way of having a ânice, coexistingâ ecosystem: we will have one OR the other, or something that does not works at all, but we will not have seamlessly one AND the other (which does not means people using monticello will be forced to use git tools or vice-versa, just that you will need to chose one⦠right now many (many for real) of our problems come from the attempt of keeping our git support behaving as regular monticello⦠and that way of doing has a limit. A limit I think we already passed. Anyway, if you can list what you think we will need for the transition, I will be very glad to see what we can do :) Esteban
On 7 Nov 2016, at 06:30, Dale Henrichs <dale.henrichs@gemtalksystems.com> wrote:
On 11/6/16 1:12 PM, Tudor Girba wrote:
Hi Stef,
I think that you are raising a valid point, and I actually agree with it.
But I think there is another side of the coin as well.
I think that right now we are in between worlds and this is not quite beneficial. Switching to GitHub is a significant effort, and treating it as business as usual will not work. That is why I think it is so important that we committed to the move for Pharo 7 and that we invest in the infrastructure. But, this will not be enough either if we do not get people to exercise it as soon as possible. Doru, there are also holes in the tool set that are not being addressed ... there are a number of critical tools that need to be created and I don't see anyone working on them ....
I went through this transition 5 years ago with my tool set and with the proper set of tools approach the difficult transition will be a bit easier ...
As it stands Pharo is standing with one foot in two boats ... there are the old Monticello tools and the new Git/Filetree tools and what is needed is a tool or two that can unify to both tool sets so that the transition between the two can be seamless ... these two sets of tools are not complicated and there working implementations that can be adapted to Pharo or used as a fairly detailed guide ...
The confusion and frustration that I see now is not a surprise to me ... I wrote" the emails" at the beginning of this year because I saw that Pharo was finally reaching a critical point in its move to integrate git into the mainstream development environment and I knew that these types of issues were going to come up where Monticello and Git were going to create friction --- friction that can be reduced by creating some simple "unifying tools" ...
I want to help, I have tried to help and I am still willing to help, but I cannot write the tools for Pharo ...
Dale
btw this is pharo-dev discussion, redirecting there. Esteban
On 7 Nov 2016, at 08:50, Esteban Lorenzano <estebanlm@gmail.com> wrote:
We are developing Iceberg⦠and I know is not enough :) Which âunifying toolsâ are you referring ?
I have followed very close your TOdE development⦠in a moment I was planning a migration of it for pure-pharo, just⦠lack of time as always and then later we started iceberg. now, we are in the process of defining a process ;) who works for pharo and is the moment to build the bridges we need, but in general I think that staying "with a foot in two boatsâ can just work during a very short lapse of time, after that, the stream continues going and if you do not finish your jump into one of the boats you will be very fast in the water.
What I mean is that we can help any transition, but at the end there is no way of having a ânice, coexistingâ ecosystem: we will have one OR the other, or something that does not works at all, but we will not have seamlessly one AND the other (which does not means people using monticello will be forced to use git tools or vice-versa, just that you will need to chose one⦠right now many (many for real) of our problems come from the attempt of keeping our git support behaving as regular monticello⦠and that way of doing has a limit. A limit I think we already passed.
Anyway, if you can list what you think we will need for the transition, I will be very glad to see what we can do :)
Esteban
On 7 Nov 2016, at 06:30, Dale Henrichs <dale.henrichs@gemtalksystems.com> wrote:
On 11/6/16 1:12 PM, Tudor Girba wrote:
Hi Stef,
I think that you are raising a valid point, and I actually agree with it.
But I think there is another side of the coin as well.
I think that right now we are in between worlds and this is not quite beneficial. Switching to GitHub is a significant effort, and treating it as business as usual will not work. That is why I think it is so important that we committed to the move for Pharo 7 and that we invest in the infrastructure. But, this will not be enough either if we do not get people to exercise it as soon as possible. Doru, there are also holes in the tool set that are not being addressed ... there are a number of critical tools that need to be created and I don't see anyone working on them ....
I went through this transition 5 years ago with my tool set and with the proper set of tools approach the difficult transition will be a bit easier ...
As it stands Pharo is standing with one foot in two boats ... there are the old Monticello tools and the new Git/Filetree tools and what is needed is a tool or two that can unify to both tool sets so that the transition between the two can be seamless ... these two sets of tools are not complicated and there working implementations that can be adapted to Pharo or used as a fairly detailed guide ...
The confusion and frustration that I see now is not a surprise to me ... I wrote" the emails" at the beginning of this year because I saw that Pharo was finally reaching a critical point in its move to integrate git into the mainstream development environment and I knew that these types of issues were going to come up where Monticello and Git were going to create friction --- friction that can be reduced by creating some simple "unifying tools" ...
I want to help, I have tried to help and I am still willing to help, but I cannot write the tools for Pharo ...
Dale
On 11/7/16 4:52 AM, Esteban Lorenzano wrote:
btw this is pharo-dev discussion, redirecting there.
Esteban
On 7 Nov 2016, at 08:50, Esteban Lorenzano <estebanlm@gmail.com> wrote:
We are developing Iceberg⦠and I know is not enough :) Which âunifying toolsâ are you referring ? The main unifying tool is a Metacello Project Browser (or something like the tODE project list).
You have a nice tool with the CatalogBrowser (modulo BaselineOf support) ... but you know that already:) but once you load a Project into the image with the CatalogBrowser it sort of disappears ... There needs to be a way to see the _projects_ are loaded in the image ... right now you can see the package loaded into the image, and you can see the dirty packages, but the package is at too low a level From the project browser you should be able to commit a project --- which saves all of the dirty packages in the project --- in one commit for a git project --- all of the dirty packages written in one operation for mcz packages ... This project browser can provide the same set of services for an mcz project (ConfigurationOf) or a filetree project (BaselineOf): - save - load -- this is a bit more complicated to explain (I tried at the Metacello Dr. talk, but more discussion is needed) - diff -- project level diff over a collection of packages - commit log -- For ConfigurationOf, list the commit history of the Configuration. For a BaselineOf list the commit log for the git repository The workflow at the project level is not that different between Mcz and Filetree, so it is straightforward to work with ... The unification comes because you can use one metaphor (project) to work with both Mcz and Filetree ... the underlying implementation will ultimately... The next layer of unified tools is when you look at version history, for a method, you need to provide the ability to view the git commit history for the method (if stored in git) or the image history ... git commit hisotry can be provided at the project/package/class/method ... whereever possible the equivalent mcz/git service should be provided so that the two systems are on an even par ... The Monticello Browser and Iceberg GUI's don't go away, because it is often necessary to do work at the package level, but I think that putting focus on the project is the key ingredient to success for integrating git ... Since git repos are persistent on disk and will be shared ... it is important that there be a way for developers to easily access the git repos for projects that have been cloned locally but not yet loaded in the image itself ... I am really struggling with getting how important this point as this is the also a point that ties a Catalog Browser and Project Browser together I've been using this approach for several years now and once you have the tools and can see at a glance what's "going on in your image" it is fun to work in a mixed environment ... all of this frustration that is bubbling on the list is largely due to not having these missing tools and underlying support --- I think ...
I have followed very close your TOdE development⦠in a moment I was planning a migration of it for pure-pharo, just⦠lack of time as always and then later we started iceberg.
Yes, I have intended to do a port of tODE to Pharo, but of time is the killer :)
now, we are in the process of defining a process ;) who works for pharo and is the moment to build the bridges we need, but in general I think that staying "with a foot in two boatsâ can just work during a very short lapse of time, after that, the stream continues going and if you do not finish your jump into one of the boats you will be very fast in the water. Yes but the two boat environment will last years ... it has taken almost 5 years for filetree to start to be used regularly ... and with the Metacello Project Browser approach the transition will not be nearly as painful, besides I think that the project-centric tools set is required when work with git....
What I mean is that we can help any transition, but at the end there is no way of having a ânice, coexistingâ ecosystem: we will have one OR the other, or something that does not works at all, but we will not have seamlessly one AND the other (which does not means people using monticello will be forced to use git tools or vice-versa, just that you will need to chose one⦠right now many (many for real) of our problems come from the attempt of keeping our git support behaving as regular monticello⦠As I say, I think that monticello/filetree can be abstracted away at the Metacello Project Browser level ... a commit of dirty packages writes all the dirty packages for the project in the appropriate repository ... BaselineOf are filetree and ConfigurationOf are mcz ... it doesn't take a whole lot of code to smoothly handle both projects --- as I've said, I have code in tODE that can be looked at for the key trickery and then re-implemented within Pharo without too much trouble ...
Then the choice does not have to be made between supporting ConfigurationOf and BaselineOf as both are supported ... eventually a developer may choose to build an image that does not include ConfigurationOf and Monticello support --- but both are needed for at least the next several years
and that way of doing has a limit. A limit I think we already passed.
Anyway, if you can list what you think we will need for the transition, I will be very glad to see what we can do :) the presentation that I made last Wednesday really covers the most critical things that I think are required ... Metacello Project Browser and load specs are the big ones ... presumably a Project Browser/code browser that allows you to read code at the project level to augment the existing package level code browsers with the commit history integrated at project/package/class/method level ... project level diff tool -- multi-package diffs in one window ... and a git merge tool that does a three-way merge within the image ...
Dale
On 7 Nov 2016, at 11:28, Dale Henrichs <dale.henrichs@gemtalksystems.com> wrote:
On 11/7/16 4:52 AM, Esteban Lorenzano wrote:
btw this is pharo-dev discussion, redirecting there.
Esteban
On 7 Nov 2016, at 08:50, Esteban Lorenzano <estebanlm@gmail.com> wrote:
We are developing Iceberg⦠and I know is not enough :) Which âunifying toolsâ are you referring ? The main unifying tool is a Metacello Project Browser (or something like the tODE project list).
You have a nice tool with the CatalogBrowser (modulo BaselineOf support) ... but you know that already:) but once you load a Project into the image with the CatalogBrowser it sort of disappears ...
There needs to be a way to see the _projects_ are loaded in the image ... right now you can see the package loaded into the image, and you can see the dirty packages, but the package is at too low a level
From the project browser you should be able to commit a project --- which saves all of the dirty packages in the project --- in one commit for a git project --- all of the dirty packages written in one operation for mcz packages ...
This project browser can provide the same set of services for an mcz project (ConfigurationOf) or a filetree project (BaselineOf): - save - load -- this is a bit more complicated to explain (I tried at the Metacello Dr. talk, but more discussion is needed) - diff -- project level diff over a collection of packages - commit log -- For ConfigurationOf, list the commit history of the Configuration. For a BaselineOf list the commit log for the git repository
The workflow at the project level is not that different between Mcz and Filetree, so it is straightforward to work with â¦
this is what is provided by iceberg⦠it still needs some work, but this is precisely what is supposed to do :) (and btw, this is why I disagree with Thierry some mails below).
The unification comes because you can use one metaphor (project) to work with both Mcz and Filetree ... the underlying implementation will ultimately...
The next layer of unified tools is when you look at version history, for a method, you need to provide the ability to view the git commit history for the method (if stored in git) or the image history ... git commit hisotry can be provided at the project/package/class/method ... whereever possible the equivalent mcz/git service should be provided so that the two systems are on an even par â¦
also, this is supposed to be provided by iceberg.
The Monticello Browser and Iceberg GUI's don't go away, because it is often necessary to do work at the package level, but I think that putting focus on the project is the key ingredient to success for integrating git â¦
Iceberg is not package-oriented. It just show repositories/packages/classes/methods⦠this is a good way to do it and I do not thing anything is lost like this. You need to take a second look at Iceberg :)
Since git repos are persistent on disk and will be shared ... it is important that there be a way for developers to easily access the git repos for projects that have been cloned locally but not yet loaded in the image itself ... I am really struggling with getting how important this point as this is the also a point that ties a Catalog Browser and Project Browser together
this is something to think⦠I do not get what catalog browser can do here (but yes, a way to browse local repositories needs to be provided).
I've been using this approach for several years now and once you have the tools and can see at a glance what's "going on in your image" it is fun to work in a mixed environment ... all of this frustration that is bubbling on the list is largely due to not having these missing tools and underlying support --- I think â¦
I do not think we are so far from your vision. I think you did not get it Iceberg right⦠please, take a second look :) now⦠is true that now everything you say is already done⦠but this is general orientation :) Esteban ps: all of this is *clearly* not pharo-users but pharo-dev discussion, letâs move there.
I have followed very close your TOdE development⦠in a moment I was planning a migration of it for pure-pharo, just⦠lack of time as always and then later we started iceberg.
Yes, I have intended to do a port of tODE to Pharo, but of time is the killer :)
now, we are in the process of defining a process ;) who works for pharo and is the moment to build the bridges we need, but in general I think that staying "with a foot in two boatsâ can just work during a very short lapse of time, after that, the stream continues going and if you do not finish your jump into one of the boats you will be very fast in the water. Yes but the two boat environment will last years ... it has taken almost 5 years for filetree to start to be used regularly ... and with the Metacello Project Browser approach the transition will not be nearly as painful, besides I think that the project-centric tools set is required when work with git....
What I mean is that we can help any transition, but at the end there is no way of having a ânice, coexistingâ ecosystem: we will have one OR the other, or something that does not works at all, but we will not have seamlessly one AND the other (which does not means people using monticello will be forced to use git tools or vice-versa, just that you will need to chose one⦠right now many (many for real) of our problems come from the attempt of keeping our git support behaving as regular monticello⦠As I say, I think that monticello/filetree can be abstracted away at the Metacello Project Browser level ... a commit of dirty packages writes all the dirty packages for the project in the appropriate repository ... BaselineOf are filetree and ConfigurationOf are mcz ... it doesn't take a whole lot of code to smoothly handle both projects --- as I've said, I have code in tODE that can be looked at for the key trickery and then re-implemented within Pharo without too much trouble ...
Then the choice does not have to be made between supporting ConfigurationOf and BaselineOf as both are supported ... eventually a developer may choose to build an image that does not include ConfigurationOf and Monticello support --- but both are needed for at least the next several years
and that way of doing has a limit. A limit I think we already passed.
Anyway, if you can list what you think we will need for the transition, I will be very glad to see what we can do :) the presentation that I made last Wednesday really covers the most critical things that I think are required ... Metacello Project Browser and load specs are the big ones ... presumably a Project Browser/code browser that allows you to read code at the project level to augment the existing package level code browsers with the commit history integrated at project/package/class/method level ... project level diff tool -- multi-package diffs in one window ... and a git merge tool that does a three-way merge within the image ...
Dale
On 11/7/16 7:36 AM, Esteban Lorenzano wrote:
On 7 Nov 2016, at 11:28, Dale Henrichs <dale.henrichs@gemtalksystems.com> wrote:
On 11/7/16 4:52 AM, Esteban Lorenzano wrote:
btw this is pharo-dev discussion, redirecting there.
Esteban
On 7 Nov 2016, at 08:50, Esteban Lorenzano <estebanlm@gmail.com> wrote:
We are developing Iceberg⦠and I know is not enough :) Which âunifying toolsâ are you referring ? The main unifying tool is a Metacello Project Browser (or something like the tODE project list).
You have a nice tool with the CatalogBrowser (modulo BaselineOf support) ... but you know that already:) but once you load a Project into the image with the CatalogBrowser it sort of disappears ...
There needs to be a way to see the _projects_ are loaded in the image ... right now you can see the package loaded into the image, and you can see the dirty packages, but the package is at too low a level
From the project browser you should be able to commit a project --- which saves all of the dirty packages in the project --- in one commit for a git project --- all of the dirty packages written in one operation for mcz packages ...
This project browser can provide the same set of services for an mcz project (ConfigurationOf) or a filetree project (BaselineOf): - save - load -- this is a bit more complicated to explain (I tried at the Metacello Dr. talk, but more discussion is needed) - diff -- project level diff over a collection of packages - commit log -- For ConfigurationOf, list the commit history of the Configuration. For a BaselineOf list the commit log for the git repository
The workflow at the project level is not that different between Mcz and Filetree, so it is straightforward to work with ⦠this is what is provided by iceberg⦠it still needs some work, but this is precisely what is supposed to do :) (and btw, this is why I disagree with Thierry some mails below). Well, I don't think that Iceberg is doing package loads and I don't think that Iceberg will provide support for mcz repositories so I still think there is a need for this Metacello Project Browser ... the Metacello Project Browser would delegate to Iceberg for all of the services that it does provide.
The Metacello Project Browser would not be a purely git/github tool ... Metacello Projects are repository format neutral so svn, hg, etc. would be equally supported from the Metacello Project Browser ... the standard set of operations: save/load/diff/log are needed for all different repository types ... I don't think it's a lot of work to implement the Metacello Project Browser tool and it is important that there be one place to look for and manage the projects loaded in image .... this is the "unifying" bit ...
The unification comes because you can use one metaphor (project) to work with both Mcz and Filetree ... the underlying implementation will ultimately...
The next layer of unified tools is when you look at version history, for a method, you need to provide the ability to view the git commit history for the method (if stored in git) or the image history ... git commit hisotry can be provided at the project/package/class/method ... whereever possible the equivalent mcz/git service should be provided so that the two systems are on an even par ⦠also, this is supposed to be provided by iceberg.
The Monticello Browser and Iceberg GUI's don't go away, because it is often necessary to do work at the package level, but I think that putting focus on the project is the key ingredient to success for integrating git ⦠Iceberg is not package-oriented. It just show repositories/packages/classes/methods⦠this is a good way to do it and I do not thing anything is lost like this. You need to take a second look at Iceberg :)
Well I am specifically referring to this issue[1] and this comment by Guille[2] and Nico[3]. If Iceberg isn't going to load packages, then you need a tool that will load a package ... and as I say above this tool must work with ConfigurationOf and BaselineOf for svn, hg, etc. repositories ... [1] https://github.com/npasserini/iceberg/issues/184 [2] https://github.com/npasserini/iceberg/issues/184#issuecomment-254139549 [3] https://github.com/npasserini/iceberg/issues/184#issuecomment-257865003
Since git repos are persistent on disk and will be shared ... it is important that there be a way for developers to easily access the git repos for projects that have been cloned locally but not yet loaded in the image itself ... I am really struggling with getting how important this point as this is the also a point that ties a Catalog Browser and Project Browser together this is something to think⦠I do not get what catalog browser can do here (but yes, a way to browse local repositories needs to be provided).
again in tODE, the Metacello Project Browser (aka project list) allows one to view projects that are cloned to local disk but not loaded in the current image ... note that I an using the term "project" not git repository ... the catalog browser defines "load specs" for projects ... but the developer is not able to control how the project gets loaded ... a better more flexible catalog browser would actually download spec objects into the Metacello Project Browser and allow developers to adjust the "load spec" for their environment, share this "load spec" with the other images in the "image cluster" and use the "load spec" to clone github projects to local disk and then load from the Metacello Project Browser ...
I've been using this approach for several years now and once you have the tools and can see at a glance what's "going on in your image" it is fun to work in a mixed environment ... all of this frustration that is bubbling on the list is largely due to not having these missing tools and underlying support --- I think ⦠I do not think we are so far from your vision. I think you did not get it Iceberg right⦠please, take a second look :)
I would agree that not far is fair and I don't think that there is a ton of work to be done, but it is work that needs to be done ... so going the last little bit is necessary ... Nico is open to discussion, but I am not sure that all of the things that need to go into the Metacello Project Browser belong in Iceberg ....
now⦠is true that now everything you say is already done⦠but this is general orientation :)
Esteban
ps: all of this is *clearly* not pharo-users but pharo-dev discussion, letâs move there.
oops now you tell me:) Dale
Hi, On 07/11/16 02:50, Esteban Lorenzano wrote: [...]
What I mean is that we can help any transition, but at the end there is no way of having a ânice, coexistingâ ecosystem: we will have one OR the other, or something that does not works at all, but we will not have seamlessly one AND the other (which does not means people using monticello will be forced to use git tools or vice-versa, just that you will need to chose one⦠right now many (many for real) of our problems come from the attempt of keeping our git support behaving as regular monticello⦠and that way of doing has a limit. A limit I think we already passed. [...]
That's clarifying. Thanks a lot Esteban. I will try to keep myself on the Monticello boat a little longer, until the filetree and Iceberg stuff become clearer to me and I can see how to use them in a way that doesn't interrupt the workflow I have now (as happens with Monticello and Fossil).
Anyway, if you can list what you think we will need for the transition, I will be very glad to see what we can do :)
Yes, Dale, your experience would be very appreciated. Cheers, Offray
Hi, This thread derived on using GitHub, the transitions to it, the mismatch between the Smalltalk code model and the files code model. I would like to offer another view. Pharo is working pretty well here. We have just finished our seventh edition of the Data Week workshop+hackathon. This time we explored the fossil DCVS and make some templates with mustache to export/publish some data visualizations. The infrastructure we have now doesn't get in our way, installing the software with Catalog, updating with Monticello, syncing changes while the workshop is happening, working with teapot, tealight and the mustache binding all that went pretty smooth. The supporting documentation for these tools was of great help. Nicolas is making a good job in making the transition to Git/GitHub smooth, but at the same time he is having a critical perspective on git and its workflow (which is not the best for every community, case or project) and I think that's healthy, so we don't need to make Pharo conform to git. So I just want to add that there are other places and people (mostly not developers), here in Colombia, South America, that really appreciate what the Pharo ecosystem, in its current form, is offering: its fluid, uniform, connected, self contained, and powerful. It is a breath of fresh air in the current overcomplicated technology. I just hope that the migration and evolution preserve and maximize that. Keeping the equilibrium between fast feedback, change, diversity, balkanisation, visibility and hyper trendy is difficult, but hopefully the core experience that Pharo is providing, will guide such equilibrium, and continue to serve its several communities around the world. Cheers, Offray On 06/11/16 07:05, stepharo wrote:
Hi
I would like that you think a bit about our community and that there is a value in using common tools
to share and develop common libraries. Because to me it feels like we are getting balkanize.
It may look super cool and be hyper trendy to use github (because like that you can say that you use latest hyper cool
features), but I would like to ask especially people building libraries to pay attention that it is important
that other people can contribute back easily and that there is an easy way to load/contribute.
Today I experienced Bloc
- I cannot load code and I cannot contribute.
- I saw mdl with a mixture between smalltalkhub and github (sounds super hyper cool) and I saw paul not being able to contribute :(
Yes you can say that monticello sucks yes it is terrible yes we all fell like Cobol programmers but at the end of the day.
Yes the herb is always greener elsewhere. Yes yes yes. Let us take some facts.
We managed pharo and moose with it over the last 8 years successfully and Pharo and moose are not 5 packages together from
what I can see. So pay attention about the decision you take.
Now we will provide git support (this is 8 months that nicolas is exclusively working/thinking/dreaming
about that) and that we are doing experiments (Guille is managing the bootstrap in github).
Now when everybody will have its own little project lost on github (I do not count the amount of time I do not find pillar on github because I forget
that it is called pillar-markup), what will we do.
So we need an infrastructure to handle this and christophe is working on this.
I think that you should consider the accidental complexity as something that we can minimise by using patterns and common practices.
Now you can think that I'm an idiot and that I have no vision (be my guest) but we should pay attention because we are a small community.
Stef
I agree Pharo works great for me with Git apart from the file tree issue. On Sun, 6 Nov 2016 at 20:22, Offray Vladimir Luna Cárdenas < offray.luna@mutabit.com> wrote:
Hi,
This thread derived on using GitHub, the transitions to it, the mismatch between the Smalltalk code model and the files code model. I would like to offer another view.
Pharo is working pretty well here. We have just finished our seventh edition of the Data Week workshop+hackathon. This time we explored the fossil DCVS and make some templates with mustache to export/publish some data visualizations. The infrastructure we have now doesn't get in our way, installing the software with Catalog, updating with Monticello, syncing changes while the workshop is happening, working with teapot, tealight and the mustache binding all that went pretty smooth. The supporting documentation for these tools was of great help.
Nicolas is making a good job in making the transition to Git/GitHub smooth, but at the same time he is having a critical perspective on git and its workflow (which is not the best for every community, case or project) and I think that's healthy, so we don't need to make Pharo conform to git.
So I just want to add that there are other places and people (mostly not developers), here in Colombia, South America, that really appreciate what the Pharo ecosystem, in its current form, is offering: its fluid, uniform, connected, self contained, and powerful. It is a breath of fresh air in the current overcomplicated technology. I just hope that the migration and evolution preserve and maximize that. Keeping the equilibrium between fast feedback, change, diversity, balkanisation, visibility and hyper trendy is difficult, but hopefully the core experience that Pharo is providing, will guide such equilibrium, and continue to serve its several communities around the world.
Cheers,
Offray
On 06/11/16 07:05, stepharo wrote:
Hi
I would like that you think a bit about our community and that there is a value in using common tools
to share and develop common libraries. Because to me it feels like we are getting balkanize.
It may look super cool and be hyper trendy to use github (because like that you can say that you use latest hyper cool
features), but I would like to ask especially people building libraries to pay attention that it is important
that other people can contribute back easily and that there is an easy way to load/contribute.
Today I experienced Bloc
- I cannot load code and I cannot contribute.
- I saw mdl with a mixture between smalltalkhub and github (sounds super hyper cool) and I saw paul not being able to contribute :(
Yes you can say that monticello sucks yes it is terrible yes we all fell like Cobol programmers but at the end of the day.
Yes the herb is always greener elsewhere. Yes yes yes. Let us take some facts.
We managed pharo and moose with it over the last 8 years successfully and Pharo and moose are not 5 packages together from
what I can see. So pay attention about the decision you take.
Now we will provide git support (this is 8 months that nicolas is exclusively working/thinking/dreaming
about that) and that we are doing experiments (Guille is managing the bootstrap in github).
Now when everybody will have its own little project lost on github (I do not count the amount of time I do not find pillar on github because I forget
that it is called pillar-markup), what will we do.
So we need an infrastructure to handle this and christophe is working on this.
I think that you should consider the accidental complexity as something that we can minimise by using patterns and common practices.
Now you can think that I'm an idiot and that I have no vision (be my guest) but we should pay attention because we are a small community.
Stef
And for us, without Git :-). Offray On 06/11/16 13:27, Dimitris Chloupis wrote:
I agree Pharo works great for me with Git apart from the file tree issue. On Sun, 6 Nov 2016 at 20:22, Offray Vladimir Luna Cárdenas <offray.luna@mutabit.com <mailto:offray.luna@mutabit.com>> wrote:
Hi,
This thread derived on using GitHub, the transitions to it, the mismatch between the Smalltalk code model and the files code model. I would like to offer another view.
Pharo is working pretty well here. We have just finished our seventh edition of the Data Week workshop+hackathon. This time we explored the fossil DCVS and make some templates with mustache to export/publish some data visualizations. The infrastructure we have now doesn't get in our way, installing the software with Catalog, updating with Monticello, syncing changes while the workshop is happening, working with teapot, tealight and the mustache binding all that went pretty smooth. The supporting documentation for these tools was of great help.
Nicolas is making a good job in making the transition to Git/GitHub smooth, but at the same time he is having a critical perspective on git and its workflow (which is not the best for every community, case or project) and I think that's healthy, so we don't need to make Pharo conform to git.
So I just want to add that there are other places and people (mostly not developers), here in Colombia, South America, that really appreciate what the Pharo ecosystem, in its current form, is offering: its fluid, uniform, connected, self contained, and powerful. It is a breath of fresh air in the current overcomplicated technology. I just hope that the migration and evolution preserve and maximize that. Keeping the equilibrium between fast feedback, change, diversity, balkanisation, visibility and hyper trendy is difficult, but hopefully the core experience that Pharo is providing, will guide such equilibrium, and continue to serve its several communities around the world.
Cheers,
Offray
On 06/11/16 07:05, stepharo wrote: > Hi > > I would like that you think a bit about our community and that there > is a value in using common tools > > to share and develop common libraries. Because to me it feels like we > are getting balkanize. > > > It may look super cool and be hyper trendy to use github (because like > that you can say that you use latest hyper cool > > features), but I would like to ask especially people building > libraries to pay attention that it is important > > that other people can contribute back easily and that there is an easy > way to load/contribute. > > Today I experienced Bloc > > - I cannot load code and I cannot contribute. > > - I saw mdl with a mixture between smalltalkhub and github (sounds > super hyper cool) and I saw paul not being able to contribute :( > > > Yes you can say that monticello sucks yes it is terrible yes we all > fell like Cobol programmers but at the end of the day. > > Yes the herb is always greener elsewhere. Yes yes yes. Let us take > some facts. > > We managed pharo and moose with it over the last 8 years successfully > and Pharo and moose are not 5 packages together from > > what I can see. So pay attention about the decision you take. > > Now we will provide git support (this is 8 months that nicolas is > exclusively working/thinking/dreaming > > about that) and that we are doing experiments (Guille is managing the > bootstrap in github). > > Now when everybody will have its own little project lost on github (I > do not count the amount of time I do not find pillar on github because > I forget > > that it is called pillar-markup), what will we do. > > So we need an infrastructure to handle this and christophe is working > on this. > > I think that you should consider the accidental complexity as > something that we can minimise by using patterns and common practices. > > Now you can think that I'm an idiot and that I have no vision (be my > guest) but we should pay attention because we are a small community. > > Stef > > > > >
On 11/6/16 9:05 AM, stepharo wrote:
Hi
I would like that you think a bit about our community and that there is a value in using common tools
to share and develop common libraries. Because to me it feels like we are getting balkanize.
It may look super cool and be hyper trendy to use github (because like that you can say that you use latest hyper cool
features), but I would like to ask especially people building libraries to pay attention that it is important
that other people can contribute back easily and that there is an easy way to load/contribute.
Today I experienced Bloc
- I cannot load code and I cannot contribute.
- I saw mdl with a mixture between smalltalkhub and github (sounds super hyper cool) and I saw paul not being able to contribute :( Stef, I have been working with git/monticello projects for about 5 years now and have been using a "mixed system" during that entire time ... My message has been consistent that in order to make a smooth transition that you need some specific tools, now the fact that you guys are _not_ building those tools has been concerning me for some time now ... I sent mails at the beginning of this year a) describing the tools to the best of my ability and b) offering to help ... it seems that you are somehow blaming git/github for this problem ... and as I come to this discussion late others are blaming smalltalkhub ...
I don't think it is necessary to move everything to github, as I said, I have been using a "mixed system" for 5 years ... and I think that the problem lies in the lack of the proper tools ... of course your problems with Bloc may be actually totally unrelated to packages, but it is clear to me that you are frustrated with the environment ... and that is a tools problem! I can and want to help. I have had good discussions with the Pharo team, but I am afraid that I am not able to get my ... to me ... simple points across ... and it is frustrating to me that I am not able to successfully communicate the simple solutions that I see ... I will repeat that Pharo is missing some very critical tools that I consider to be absolutely required (in some form) to be able to be successful ... the required tools do not take a phd to implement, they are very straightforward and simple ... perhaps they are not sexy and complicated so noone is interested, but they are required ... If you want to have a conversation about this I am willing ... now it happens that I am in Buenos Aires (soon to be Tucuman) so this week is not convenient for me to talk ... If you don't want to talk to me then look at the series of messages that I wrote last winter/spring to this mailing list (or pharo dev) where I described what I think you guys are missing ... and then ask me questions ... Dale
participants (8)
-
Dale Henrichs -
Dimitris Chloupis -
Esteban Lorenzano -
Norbert Hartl -
Offray Vladimir Luna Cárdenas -
stepharo -
Sven Van Caekenberghe -
Tudor Girba