Hi guys the board got a good discussion at ESUG about how to improve and a lot of the discussion turned around improving communication. We got some ideas that we will propose soon but I would like to get *your* ideas. If you have idea about improving communication around pharo please tell us. Stef
Hi Stef, Good communication implies being clear when writing about sensitive topics, especially when communicating through virtual channels. I am not in Europe, so I cannot discuss these things with you face to face. Therefore is not clear to me (and others) what are your policies in many subjects. Lately I also delayed the release of packages because my lack of motivation around this community, specially when discussions exists around three or fourth topics for months. Another "motivational" case for me. I stopped to report bugs in fogbuz because I felt there was too much "Won't fix" for me (specifically by a person but I won't go there...) even in cases where it was ilogical. Then I felt tired of reading "It's like that. Invalid". About features. What's the policy about voting for default features in next Pharo images? Let's suppose I am a VM/core Pharo maintainer and I want to include MySuperPackage into a Pharo release, which nobody needs (and I don't care), but it is useful to me.... there will ever be voting there? (note it doesn't makes sense if you are a group of 50 always supporting your work) Images are becoming huge (at least for my workflows). There will be (more) packages included by default (for promotion?) ? How do you plan to manage if some people want the Tests be removed from the official Image? (Personally I never run them) Another example, what happens if another research group came with a better alternative to Calypso, Brick, Telescope, Bloc. Would you integrate first your tool to mark territory? Who decides? For example (IIRC) TxText and Twisty. The same applies if anyone came with another rewrite of classic Smalltalk Workspace, Debugger and Inspector tools, what would you do with GT? GT stays because it came before and others would be optional? There will be anything like PEPs? If someone can answer me I think that would be an example of good communication. Hernán 2016-08-24 1:51 GMT-03:00 stepharo <stepharo@free.fr>:
Hi guys
the board got a good discussion at ESUG about how to improve and a lot of the discussion turned around improving communication. We got some ideas that we will propose soon but I would like to get *your* ideas.
If you have idea about improving communication around pharo please tell us.
Stef
Hi Hernan First thanks for your email because we may disagree but we often agree. :) so this is an email for me.
Hi Stef,
Good communication implies being clear when writing about sensitive topics, especially when communicating through virtual channels. I am not in Europe, so I cannot discuss these things with you face to face. This is what we want to change with montly videos meeting. Therefore is not clear to me (and others) what are your policies in many subjects. Lately I also delayed the release of packages because my lack of motivation around this community, specially when discussions exists around three or fourth topics for months.
Like what? Let us know because we do not
Another "motivational" case for me. I stopped to report bugs in fogbuz because I felt there was too much "Won't fix" for me (specifically by a person but I won't go there...) even in cases where it was ilogical. Then I felt tired of reading "It's like that. Invalid". This is a pity. I know the feeling because some of mine are close too. You are not the only victim of the "Issue closing syndrom" ;). And I would like the syndrome to be more human friendly. Thanks for raising this point.
Now two points - You should always send a mail to the mailing-list and that we discuss your points. - Now what will happen if we all open bugs and none of us works on the open bugs. So what is the solution for you. I mean it concretely. How to deal with dying Looking at bugs is really difficult. There are not enough people looking and fixing bugs.
About features.
What's the policy about voting for default features in next Pharo images? Let's suppose I am a VM/core Pharo maintainer and I want to include MySuperPackage into a Pharo release, which nobody needs (and I don't care), but it is useful to me.... there will ever be voting there? (note it doesn't makes sense if you are a group of 50 always supporting your work)
It does not really work because engineers are paid for certain task.
Images are becoming huge (at least for my workflows). There will be (more) packages included by default (for promotion?) ? Thanks to raise this point because I mentioned it also to the board. So I like when I'm not alone. Now we should not see look only at the size. Doing nothing is size zero :) The point is what are the functionalities delivered.
Three points: - what are the key things we want? keybinding, settings, cool inspector cool.... - how many duplicated functionality can we remove: for example I want to merge MCDefinitions with Ring with RBDefinition we removed pseudo* but this is a lot of work The goal is to throw many system when bloc and brick are ready - what is the list of things that you would remove? - with the bootstrap and all the packages of the image managed with Cargo plus the git management we believe that we will be able to manage a set of images with minimal images. - this is several years that we are working on this goal. Believe me this is the vision document not for the sake of it.
How do you plan to manage if some people want the Tests be removed from the official Image? (Personally I never run them) - then you use a jenkins job to produce your image where you unload the tests.
Another example, what happens if another research group came with a better alternative to Calypso, Brick, Telescope, Bloc. Would you integrate first your tool to mark territory?
No this is not a question of territory. Doru and GT does not do that in that spirit. RMOD too. We do something when we think that this is better. For example Epicea is three years of work of Martin, Fuel was so nice that we could not lose it. You see Ghost got changed by denis, Seamless got rewritten from scratch.
Who decides? For example (IIRC) TxText and Twisty. Igor looked at Twisty seriously and I do not think that it could handle large cobol files.
(you see funnily denis is doing the same with Seamless - He rewrote it from scratch while nick worked on it for several years). Igor wanted to have a stream-based API that could work on modern command-oriented videos card framework. My team (on our own money if you understand what it means) paid Igor to build TxText (and I can tell you that I would have prefered him to do something else).
The same applies if anyone came with another rewrite of classic Smalltalk Workspace, Debugger and Inspector tools, what would you do with GT? GT stays because it came before and others would be optional? No this is not like that. If you are better or answer better needs.
There will be anything like PEPs? I would love but will people have the energy to implement them? I would definitively encourage you as a community to raise points on what you need.
If someone can answer me I think that would be an example of good communication. Hernan I always answered your emails. I always consider your work (and you know it for other reasons and by my facts) after I'm not always in agreement as I'm not always in agreement with other board members and this is how live happens. What is clear is that the most important aspects is to continue to communicate. This is why the board is launching this initiative and I would love to see it taken by people even for their projects.
Hernán
2016-08-24 1:51 GMT-03:00 stepharo <stepharo@free.fr <mailto:stepharo@free.fr>>:
Hi guys
the board got a good discussion at ESUG about how to improve and a lot of the discussion turned around improving communication. We got some ideas that we will propose soon but I would like to get *your* ideas.
If you have idea about improving communication around pharo please tell us.
Stef
Hi, I want to point just a couple of things: 1. You may feel hurt, but is my job to say no. If you think Iâm doing a bad job, is your right to discuss, but do not expect that what you consider a bad design decision would be shared by the board (and me as executor of board policies). 2. Features that goes inside Pharo are not decided by vote. They have to add value and share the Pharo vision (pointed in the vision document who is not slightly updated but still guides our steps). We try to reach consensus and if it is not possible, then we decide. Yes, is like that⦠Iâm sorry for not being perfect democratic but this was never the idea of Pharo (it *has* a benevolent dictator⦠who by the way is not me but a group, the board). 3. TxText vs. Twisty is a bad example (or a good example of how people can interpret things that does not know in a complete missed direction⦠our fault, this has to be communicated better)⦠what actually happened is that Igor and Denis discussed the design and they had a disagreement, but Denis shared the vision of Igor⦠just no time to wait for it because he was working pressures, so he delivered Twisty⦠I love twisty and I use it a lot in my personal projects, but this was like that⦠also, not all useful things needs to be inside Pharo⦠4. You have a very negative opinion about our design choices. Thatâs ok, but we are not going to remove GT just because you dislike it. What we will do is to iterate over it until we have a version that satisfies most people and hopefully you too⦠but this is like that, GT tools is our vision for the future development tools and it will stay⦠improved, of course. Which also means that we will not accept the inclusion of alternative tools. like another workspace or browser⦠Thierry did an excellent job with his AltBrowser, and we look a lot at it to take ideas, but we will not include it either and that does not means we have a problem with him⦠What we want it more people helping us to improve the GT tools and just asking for removal does not help. So again, I cannot stress this enough: Is my job to say no. I know I hurt some people but social development is complicated. I do not think I do a bad job :) cheers! Esteban
On 24 Aug 2016, at 09:38, stepharo <stepharo@free.fr> wrote:
Hi Hernan
First thanks for your email because we may disagree but we often agree. :) so this is an email for me.
Hi Stef,
Good communication implies being clear when writing about sensitive topics, especially when communicating through virtual channels. I am not in Europe, so I cannot discuss these things with you face to face. This is what we want to change with montly videos meeting. Therefore is not clear to me (and others) what are your policies in many subjects. Lately I also delayed the release of packages because my lack of motivation around this community, specially when discussions exists around three or fourth topics for months.
Like what? Let us know because we do not
Another "motivational" case for me. I stopped to report bugs in fogbuz because I felt there was too much "Won't fix" for me (specifically by a person but I won't go there...) even in cases where it was ilogical. Then I felt tired of reading "It's like that. Invalid". This is a pity. I know the feeling because some of mine are close too. You are not the only victim of the "Issue closing syndrom" ;). And I would like the syndrome to be more human friendly. Thanks for raising this point.
Now two points - You should always send a mail to the mailing-list and that we discuss your points.
- Now what will happen if we all open bugs and none of us works on the open bugs. So what is the solution for you. I mean it concretely. How to deal with dying
Looking at bugs is really difficult. There are not enough people looking and fixing bugs.
About features.
What's the policy about voting for default features in next Pharo images? Let's suppose I am a VM/core Pharo maintainer and I want to include MySuperPackage into a Pharo release, which nobody needs (and I don't care), but it is useful to me.... there will ever be voting there? (note it doesn't makes sense if you are a group of 50 always supporting your work)
It does not really work because engineers are paid for certain task.
Images are becoming huge (at least for my workflows). There will be (more) packages included by default (for promotion?) ? Thanks to raise this point because I mentioned it also to the board. So I like when I'm not alone. Now we should not see look only at the size. Doing nothing is size zero :) The point is what are the functionalities delivered.
Three points: - what are the key things we want? keybinding, settings, cool inspector cool....
- how many duplicated functionality can we remove: for example I want to merge MCDefinitions with Ring with RBDefinition we removed pseudo* but this is a lot of work
The goal is to throw many system when bloc and brick are ready
- what is the list of things that you would remove?
- with the bootstrap and all the packages of the image managed with Cargo plus the git management we believe that we will be able to manage a set of images with minimal images. - this is several years that we are working on this goal. Believe me this is the vision document not for the sake of it.
How do you plan to manage if some people want the Tests be removed from the official Image? (Personally I never run them) - then you use a jenkins job to produce your image where you unload the tests.
Another example, what happens if another research group came with a better alternative to Calypso, Brick, Telescope, Bloc. Would you integrate first your tool to mark territory?
No this is not a question of territory. Doru and GT does not do that in that spirit. RMOD too. We do something when we think that this is better. For example Epicea is three years of work of Martin, Fuel was so nice that we could not lose it. You see Ghost got changed by denis, Seamless got rewritten from scratch.
Who decides? For example (IIRC) TxText and Twisty. Igor looked at Twisty seriously and I do not think that it could handle large cobol files.
(you see funnily denis is doing the same with Seamless - He rewrote it from scratch while nick worked on it for several years).
Igor wanted to have a stream-based API that could work on modern command-oriented videos card framework. My team (on our own money if you understand what it means) paid Igor to build TxText (and I can tell you that I would have prefered him to do something else).
The same applies if anyone came with another rewrite of classic Smalltalk Workspace, Debugger and Inspector tools, what would you do with GT? GT stays because it came before and others would be optional? No this is not like that. If you are better or answer better needs.
There will be anything like PEPs? I would love but will people have the energy to implement them? I would definitively encourage you as a community to raise points on what you need.
If someone can answer me I think that would be an example of good communication. Hernan I always answered your emails. I always consider your work (and you know it for other reasons and by my facts) after I'm not always in agreement as I'm not always in agreement with other board members and this is how live happens. What is clear is that the most important aspects is to continue to communicate. This is why the board is launching this initiative and I would love to see it taken by people even for their projects.
Hernán
2016-08-24 1:51 GMT-03:00 stepharo <stepharo@free.fr <mailto:stepharo@free.fr>>: Hi guys
the board got a good discussion at ESUG about how to improve and a lot of the discussion turned around improving communication. We got some ideas that we will propose soon but I would like to get *your* ideas.
If you have idea about improving communication around pharo please tell us.
Stef
Hi, Esteban, Please don't take this personal, but we have differences :) 2016-08-24 5:06 GMT-03:00 Esteban Lorenzano <estebanlm@gmail.com>:
Hi,
I want to point just a couple of things:
1. You may feel hurt, but is my job to say no. If you think Iâm doing a bad job, is your right to discuss, but do not expect that what you consider a bad design decision would be shared by the board (and me as executor of board policies).
Then it makes no sense raise any form of criticism, or the board, if by definition lobby groups silence any possible mistake.
2. Features that goes inside Pharo are not decided by vote. They have to add value and share the Pharo vision (pointed in the vision document who is not slightly updated but still guides our steps). We try to reach consensus and if it is not possible, then we decide. Yes, is like that⦠Iâm sorry for not being perfect democratic but this was never the idea of Pharo (it *has* a benevolent dictator⦠who by the way is not me but a group, the board).
Ok, now people can see one reason why Pharo is light years from the popularity of other OSS. I don't get how do you expect success with Pharo if you never change your mindset... I read a lot of papers and see KDE, gcc, Linux, NetBeans, Python, Mozilla, Apache collaboration models... never *ever* read something like that, specially now where OSS literature is considering distributed democracy. In the end, time will tell, but can you cite another successful open source project with such "model"?
3. TxText vs. Twisty is a bad example (or a good example of how people can interpret things that does not know in a complete missed direction⦠our fault, this has to be communicated better)⦠what actually happened is that Igor and Denis discussed the design and they had a disagreement, but Denis shared the vision of Igor⦠just no time to wait for it because he was working pressures, so he delivered Twisty⦠I love twisty and I use it a lot in my personal projects, but this was like that⦠also, not all useful things needs to be inside Pharoâ¦
4. You have a very negative opinion about our design choices. Thatâs ok, but we are not going to remove GT just because you dislike it.
It's not because of just my dislike. It's because it was never proposed for inclusion (it was just decided), it is because you make it almost impossible to uninstall it, and because it was integrated very early like an enhacement/future/vision set of tools without any votes, or high-resistance policy like many Open-Source projects, and judging by the volume of mails it required a lot of of time of beta-testing by many users. I would love to have the time to invite you, or any GT developer, to work with me just one week with real DNA data, and see how well GT goes... Maybe I should be sorry for not being as obedient and blindly accepting all board decisions as the word of God, as many on this list.
What we will do is to iterate over it until we have a version that satisfies most people and hopefully you too⦠but this is like that, GT tools is our vision for the future development tools and it will stay⦠improved, of course.
Which also means that we will not accept the inclusion of alternative
tools. like another workspace or browser⦠Thierry did an excellent job with his AltBrowser, and we look a lot at it to take ideas, but we will not include it either and that does not means we have a problem with him⦠What we want it more people helping us to improve the GT tools and just asking for removal does not help.
Understood, what makes me most sad is users almost accepted they cannot do better and if they do, their work will never be integrated by default. Instead, non-voters decisions discourages users to be rewarded for their creativity, and imposes many others to work free "supporting" tools which were imposed de facto.
So again, I cannot stress this enough: Is my job to say no. I know I hurt some people but social development is complicated. I do not think I do a bad job :)
Me neither, but you cannot expect conformity from all of us. Hernán
cheers! Esteban
On 24 Aug 2016, at 09:38, stepharo <stepharo@free.fr> wrote:
Hi Hernan
First thanks for your email because we may disagree but we often agree. :) so this is an email for me.
Hi Stef,
Good communication implies being clear when writing about sensitive topics, especially when communicating through virtual channels. I am not in Europe, so I cannot discuss these things with you face to face.
This is what we want to change with montly videos meeting.
Therefore is not clear to me (and others) what are your policies in many subjects. Lately I also delayed the release of packages because my lack of motivation around this community, specially when discussions exists around three or fourth topics for months.
Like what? Let us know because we do not
Another "motivational" case for me. I stopped to report bugs in fogbuz because I felt there was too much "Won't fix" for me (specifically by a person but I won't go there...) even in cases where it was ilogical. Then I felt tired of reading "It's like that. Invalid".
This is a pity. I know the feeling because some of mine are close too. You are not the only victim of the "Issue closing syndrom" ;). And I would like the syndrome to be more human friendly. Thanks for raising this point.
Now two points - You should always send a mail to the mailing-list and that we discuss your points.
- Now what will happen if we all open bugs and none of us works on the open bugs. So what is the solution for you. I mean it concretely. How to deal with dying
Looking at bugs is really difficult. There are not enough people looking and fixing bugs.
About features.
What's the policy about voting for default features in next Pharo images? Let's suppose I am a VM/core Pharo maintainer and I want to include MySuperPackage into a Pharo release, which nobody needs (and I don't care), but it is useful to me.... there will ever be voting there? (note it doesn't makes sense if you are a group of 50 always supporting your work)
It does not really work because engineers are paid for certain task.
Images are becoming huge (at least for my workflows). There will be (more) packages included by default (for promotion?) ?
Thanks to raise this point because I mentioned it also to the board. So I like when I'm not alone. Now we should not see look only at the size. Doing nothing is size zero :) The point is what are the functionalities delivered.
Three points: - what are the key things we want? keybinding, settings, cool inspector cool....
- how many duplicated functionality can we remove: for example I want to merge MCDefinitions with Ring with RBDefinition we removed pseudo* but this is a lot of work
The goal is to throw many system when bloc and brick are ready
- what is the list of things that you would remove?
- with the bootstrap and all the packages of the image managed with Cargo plus the git management we believe that we will be able to manage a set of images with minimal images. - this is several years that we are working on this goal. Believe me this is the vision document not for the sake of it.
How do you plan to manage if some people want the Tests be removed from the official Image? (Personally I never run them)
- then you use a jenkins job to produce your image where you unload the tests.
Another example, what happens if another research group came with a better alternative to Calypso, Brick, Telescope, Bloc. Would you integrate first your tool to mark territory?
No this is not a question of territory. Doru and GT does not do that in that spirit. RMOD too. We do something when we think that this is better. For example Epicea is three years of work of Martin, Fuel was so nice that we could not lose it. You see Ghost got changed by denis, Seamless got rewritten from scratch.
Who decides? For example (IIRC) TxText and Twisty.
Igor looked at Twisty seriously and I do not think that it could handle large cobol files.
(you see funnily denis is doing the same with Seamless - He rewrote it from scratch while nick worked on it for several years).
Igor wanted to have a stream-based API that could work on modern command-oriented videos card framework. My team (on our own money if you understand what it means) paid Igor to build TxText (and I can tell you that I would have prefered him to do something else).
The same applies if anyone came with another rewrite of classic Smalltalk Workspace, Debugger and Inspector tools, what would you do with GT? GT stays because it came before and others would be optional?
No this is not like that. If you are better or answer better needs.
There will be anything like PEPs?
I would love but will people have the energy to implement them? I would definitively encourage you as a community to raise points on what you need.
If someone can answer me I think that would be an example of good communication.
Hernan I always answered your emails. I always consider your work (and you know it for other reasons and by my facts) after I'm not always in agreement as I'm not always in agreement with other board members and this is how live happens. What is clear is that the most important aspects is to continue to communicate. This is why the board is launching this initiative and I would love to see it taken by people even for their projects.
Hernán
2016-08-24 1:51 GMT-03:00 stepharo <stepharo@free.fr>:
Hi guys
the board got a good discussion at ESUG about how to improve and a lot of the discussion turned around improving communication. We got some ideas that we will propose soon but I would like to get *your* ideas.
If you have idea about improving communication around pharo please tell us.
Stef
Hi hernan Could you reply to my mail? Because what is important is how we can make progres. About GT I have some concerns too now I see also a lot of improvements. I love GTInspector and we should remove EyeInspector. I want to have once brick is out another minimal environment not based on anything so that we can have a back-door to debug when the other tools have a problems. Now some answers:
Then it makes no sense raise any form of criticism, or the board, if by definition lobby groups silence any possible mistake.
No this is wrong. You can criticize as I criticize but you should give clear actionable points. Else this is Oh XX is bad. Tell us how we can address your problems and we will try. Without clear feedback we cannot act.
2. Features that goes inside Pharo are not decided by vote. They have to add value and share the Pharo vision (pointed in the vision document who is not slightly updated but still guides our steps). We try to reach consensus and if it is not possible, then we decide. Yes, is like that⦠Iâm sorry for not being perfect democratic but this was never the idea of Pharo (it *has* a benevolent dictator⦠who by the way is not me but a group, the board).
Ok, now people can see one reason why Pharo is light years from the popularity of other OSS. I don't get how do you expect success with Pharo if you never change your mindset... I read a lot of papers and see KDE, gcc, Linux, NetBeans, Python, Mozilla, Apache collaboration models... never *ever* read something like that, specially now where OSS literature is considering distributed democracy.
Sorry but - you would be surprised by how many people would vote to get GT tools inside Pharo :) - then I do not know what to tell you because I'm quite sure that Apache or Mozilla are not managed by vote of people.
In the end, time will tell, but can you cite another successful open source project with such "model"? Sorry I do not have the time to know. We want an doit model: doing in things should be more important than suh having needs (even if clients and users are important)
4. You have a very negative opinion about our design choices. Thatâs ok, but we are not going to remove GT just because you dislike it.
It's not because of just my dislike. It's because it was never proposed for inclusion (it was just decided), it is because you make it almost impossible to uninstall it, and because it was integrated very early like an enhacement/future/vision set of tools without any votes, or high-resistance policy like many Open-Source projects, and judging by the volume of mails it required a lot of of time of beta-testing by many users. You mean beside me someone was not really happy? Seriously? Now you can not use Spotter so I do not see the problem. The Debugger is working well. Playground looks like a default workspace. Then GTInspector works perfectly for me.
I would love to have the time to invite you, or any GT developer, to work with me just one week with real DNA data, and see how well GT goes...
Please do a skype sharing session with Andrei and Doru. I'm sure that they will love to do it. So I take your words and urge you do it. It will help you to get out your frsutration and I'm sure that GT will improve. So a clear win/win situation.
Maybe I should be sorry for not being as obedient and blindly accepting all board decisions as the word of God, as many on this list.
Can you imagine one moment that people like it?
Understood, what makes me most sad is users almost accepted they cannot do better and if they do, their work will never be integrated by default.
No do better. Why I started Spec when ther was Glamour. Why Alain was working on Calipso? I would love that someone comes and tell me: take XX it is super hyper cool UI Builder.
Instead, non-voters decisions discourages users to be rewarded for their creativity, and imposes many others to work free "supporting" tools which were imposed de facto.
So again, I cannot stress this enough: Is my job to say no. I know I hurt some people but social development is complicated. I do not think I do a bad job :)
Me neither, but you cannot expect conformity from all of us.
Hernán
cheers! Esteban
On 24 Aug 2016, at 09:38, stepharo <stepharo@free.fr <mailto:stepharo@free.fr>> wrote:
Hi Hernan
First thanks for your email because we may disagree but we often agree. :) so this is an email for me.
Hi Stef,
Good communication implies being clear when writing about sensitive topics, especially when communicating through virtual channels. I am not in Europe, so I cannot discuss these things with you face to face.
This is what we want to change with montly videos meeting.
Therefore is not clear to me (and others) what are your policies in many subjects. Lately I also delayed the release of packages because my lack of motivation around this community, specially when discussions exists around three or fourth topics for months.
Like what? Let us know because we do not
Another "motivational" case for me. I stopped to report bugs in fogbuz because I felt there was too much "Won't fix" for me (specifically by a person but I won't go there...) even in cases where it was ilogical. Then I felt tired of reading "It's like that. Invalid".
This is a pity. I know the feeling because some of mine are close too. You are not the only victim of the "Issue closing syndrom" ;). And I would like the syndrome to be more human friendly. Thanks for raising this point.
Now two points - You should always send a mail to the mailing-list and that we discuss your points.
- Now what will happen if we all open bugs and none of us works on the open bugs. So what is the solution for you. I mean it concretely. How to deal with dying
Looking at bugs is really difficult. There are not enough people looking and fixing bugs.
About features.
What's the policy about voting for default features in next Pharo images? Let's suppose I am a VM/core Pharo maintainer and I want to include MySuperPackage into a Pharo release, which nobody needs (and I don't care), but it is useful to me.... there will ever be voting there? (note it doesn't makes sense if you are a group of 50 always supporting your work)
It does not really work because engineers are paid for certain task.
Images are becoming huge (at least for my workflows). There will be (more) packages included by default (for promotion?) ?
Thanks to raise this point because I mentioned it also to the board. So I like when I'm not alone. Now we should not see look only at the size. Doing nothing is size zero :) The point is what are the functionalities delivered.
Three points: - what are the key things we want? keybinding, settings, cool inspector cool....
- how many duplicated functionality can we remove: for example I want to merge MCDefinitions with Ring with RBDefinition we removed pseudo* but this is a lot of work
The goal is to throw many system when bloc and brick are ready
- what is the list of things that you would remove?
- with the bootstrap and all the packages of the image managed with Cargo plus the git management we believe that we will be able to manage a set of images with minimal images. - this is several years that we are working on this goal. Believe me this is the vision document not for the sake of it.
How do you plan to manage if some people want the Tests be removed from the official Image? (Personally I never run them)
- then you use a jenkins job to produce your image where you unload the tests.
Another example, what happens if another research group came with a better alternative to Calypso, Brick, Telescope, Bloc. Would you integrate first your tool to mark territory?
No this is not a question of territory. Doru and GT does not do that in that spirit. RMOD too. We do something when we think that this is better. For example Epicea is three years of work of Martin, Fuel was so nice that we could not lose it. You see Ghost got changed by denis, Seamless got rewritten from scratch.
Who decides? For example (IIRC) TxText and Twisty.
Igor looked at Twisty seriously and I do not think that it could handle large cobol files.
(you see funnily denis is doing the same with Seamless - He rewrote it from scratch while nick worked on it for several years).
Igor wanted to have a stream-based API that could work on modern command-oriented videos card framework. My team (on our own money if you understand what it means) paid Igor to build TxText (and I can tell you that I would have prefered him to do something else).
The same applies if anyone came with another rewrite of classic Smalltalk Workspace, Debugger and Inspector tools, what would you do with GT? GT stays because it came before and others would be optional?
No this is not like that. If you are better or answer better needs.
There will be anything like PEPs?
I would love but will people have the energy to implement them? I would definitively encourage you as a community to raise points on what you need.
If someone can answer me I think that would be an example of good communication.
Hernan I always answered your emails. I always consider your work (and you know it for other reasons and by my facts) after I'm not always in agreement as I'm not always in agreement with other board members and this is how live happens. What is clear is that the most important aspects is to continue to communicate. This is why the board is launching this initiative and I would love to see it taken by people even for their projects.
Hernán
2016-08-24 1:51 GMT-03:00 stepharo <stepharo@free.fr <mailto:stepharo@free.fr>>:
Hi guys
the board got a good discussion at ESUG about how to improve and a lot of the discussion turned around improving communication. We got some ideas that we will propose soon but I would like to get *your* ideas.
If you have idea about improving communication around pharo please tell us.
Stef
Hi, Thanks Stef for the reply. I completely concur. @Hernán: About the issues with GT: please do get in touch. We have asked for it several times, and we are still here. If you have concrete issues, please raise them but focus on how to improve concretely. At the same time, also keep in mind that the overall decisions have to take into account other peopleâs constraints. That is why we need to iterate, and just because some requests do not make it, it does not mean that we do not care, but that we could not find a better solution to accommodate all wishes within the given time frame. We would certainly welcome help especially when that help aims to understand the full picture. The IDE is not a straightforward domain and we still have much to learn. Please, letâs work together and remember to have fun in the process :). Cheers, Doru
On Aug 25, 2016, at 8:48 AM, stepharo <stepharo@free.fr> wrote:
Hi hernan Could you reply to my mail? Because what is important is how we can make progres.
About GT I have some concerns too now I see also a lot of improvements. I love GTInspector and we should remove EyeInspector. I want to have once brick is out another minimal environment not based on anything so that we can have a back-door to debug when the other tools have a problems. Now some answers:
Then it makes no sense raise any form of criticism, or the board, if by definition lobby groups silence any possible mistake.
No this is wrong. You can criticize as I criticize but you should give clear actionable points. Else this is Oh XX is bad. Tell us how we can address your problems and we will try. Without clear feedback we cannot act.
2. Features that goes inside Pharo are not decided by vote. They have to add value and share the Pharo vision (pointed in the vision document who is not slightly updated but still guides our steps). We try to reach consensus and if it is not possible, then we decide. Yes, is like that⦠Iâm sorry for not being perfect democratic but this was never the idea of Pharo (it *has* a benevolent dictator⦠who by the way is not me but a group, the board).
Ok, now people can see one reason why Pharo is light years from the popularity of other OSS. I don't get how do you expect success with Pharo if you never change your mindset... I read a lot of papers and see KDE, gcc, Linux, NetBeans, Python, Mozilla, Apache collaboration models... never *ever* read something like that, specially now where OSS literature is considering distributed democracy. Sorry but - you would be surprised by how many people would vote to get GT tools inside Pharo :) - then I do not know what to tell you because I'm quite sure that Apache or Mozilla are not managed by vote of people.
In the end, time will tell, but can you cite another successful open source project with such "model"? Sorry I do not have the time to know. We want an doit model: doing in things should be more important than suh having needs (even if clients and users are important) 4. You have a very negative opinion about our design choices. Thatâs ok, but we are not going to remove GT just because you dislike it.
It's not because of just my dislike. It's because it was never proposed for inclusion (it was just decided), it is because you make it almost impossible to uninstall it, and because it was integrated very early like an enhacement/future/vision set of tools without any votes, or high-resistance policy like many Open-Source projects, and judging by the volume of mails it required a lot of of time of beta-testing by many users. You mean beside me someone was not really happy? Seriously? Now you can not use Spotter so I do not see the problem. The Debugger is working well. Playground looks like a default workspace. Then GTInspector works perfectly for me.
I would love to have the time to invite you, or any GT developer, to work with me just one week with real DNA data, and see how well GT goes...
Please do a skype sharing session with Andrei and Doru. I'm sure that they will love to do it. So I take your words and urge you do it. It will help you to get out your frsutration and I'm sure that GT will improve. So a clear win/win situation.
Maybe I should be sorry for not being as obedient and blindly accepting all board decisions as the word of God, as many on this list.
Can you imagine one moment that people like it?
Understood, what makes me most sad is users almost accepted they cannot do better and if they do, their work will never be integrated by default.
No do better. Why I started Spec when ther was Glamour. Why Alain was working on Calipso? I would love that someone comes and tell me: take XX it is super hyper cool UI Builder.
Instead, non-voters decisions discourages users to be rewarded for their creativity, and imposes many others to work free "supporting" tools which were imposed de facto.
So again, I cannot stress this enough: Is my job to say no. I know I hurt some people but social development is complicated. I do not think I do a bad job :)
Me neither, but you cannot expect conformity from all of us.
Hernán
cheers! Esteban
On 24 Aug 2016, at 09:38, stepharo <stepharo@free.fr> wrote:
Hi Hernan
First thanks for your email because we may disagree but we often agree. :) so this is an email for me.
Hi Stef,
Good communication implies being clear when writing about sensitive topics, especially when communicating through virtual channels. I am not in Europe, so I cannot discuss these things with you face to face. This is what we want to change with montly videos meeting. Therefore is not clear to me (and others) what are your policies in many subjects. Lately I also delayed the release of packages because my lack of motivation around this community, specially when discussions exists around three or fourth topics for months.
Like what? Let us know because we do not
Another "motivational" case for me. I stopped to report bugs in fogbuz because I felt there was too much "Won't fix" for me (specifically by a person but I won't go there...) even in cases where it was ilogical. Then I felt tired of reading "It's like that. Invalid". This is a pity. I know the feeling because some of mine are close too. You are not the only victim of the "Issue closing syndrom" ;). And I would like the syndrome to be more human friendly. Thanks for raising this point.
Now two points - You should always send a mail to the mailing-list and that we discuss your points.
- Now what will happen if we all open bugs and none of us works on the open bugs. So what is the solution for you. I mean it concretely. How to deal with dying
Looking at bugs is really difficult. There are not enough people looking and fixing bugs.
About features.
What's the policy about voting for default features in next Pharo images? Let's suppose I am a VM/core Pharo maintainer and I want to include MySuperPackage into a Pharo release, which nobody needs (and I don't care), but it is useful to me.... there will ever be voting there? (note it doesn't makes sense if you are a group of 50 always supporting your work)
It does not really work because engineers are paid for certain task.
Images are becoming huge (at least for my workflows). There will be (more) packages included by default (for promotion?) ? Thanks to raise this point because I mentioned it also to the board. So I like when I'm not alone. Now we should not see look only at the size. Doing nothing is size zero :) The point is what are the functionalities delivered.
Three points: - what are the key things we want? keybinding, settings, cool inspector cool....
- how many duplicated functionality can we remove: for example I want to merge MCDefinitions with Ring with RBDefinition we removed pseudo* but this is a lot of work
The goal is to throw many system when bloc and brick are ready
- what is the list of things that you would remove?
- with the bootstrap and all the packages of the image managed with Cargo plus the git management we believe that we will be able to manage a set of images with minimal images. - this is several years that we are working on this goal. Believe me this is the vision document not for the sake of it.
How do you plan to manage if some people want the Tests be removed from the official Image? (Personally I never run them) - then you use a jenkins job to produce your image where you unload the tests.
Another example, what happens if another research group came with a better alternative to Calypso, Brick, Telescope, Bloc. Would you integrate first your tool to mark territory?
No this is not a question of territory. Doru and GT does not do that in that spirit. RMOD too. We do something when we think that this is better. For example Epicea is three years of work of Martin, Fuel was so nice that we could not lose it. You see Ghost got changed by denis, Seamless got rewritten from scratch.
Who decides? For example (IIRC) TxText and Twisty. Igor looked at Twisty seriously and I do not think that it could handle large cobol files.
(you see funnily denis is doing the same with Seamless - He rewrote it from scratch while nick worked on it for several years).
Igor wanted to have a stream-based API that could work on modern command-oriented videos card framework. My team (on our own money if you understand what it means) paid Igor to build TxText (and I can tell you that I would have prefered him to do something else).
The same applies if anyone came with another rewrite of classic Smalltalk Workspace, Debugger and Inspector tools, what would you do with GT? GT stays because it came before and others would be optional? No this is not like that. If you are better or answer better needs.
There will be anything like PEPs? I would love but will people have the energy to implement them? I would definitively encourage you as a community to raise points on what you need.
If someone can answer me I think that would be an example of good communication. Hernan I always answered your emails. I always consider your work (and you know it for other reasons and by my facts) after I'm not always in agreement as I'm not always in agreement with other board members and this is how live happens. What is clear is that the most important aspects is to continue to communicate. This is why the board is launching this initiative and I would love to see it taken by people even for their projects.
Hernán
2016-08-24 1:51 GMT-03:00 stepharo <stepharo@free.fr>: Hi guys
the board got a good discussion at ESUG about how to improve and a lot of the discussion turned around improving communication. We got some ideas that we will propose soon but I would like to get *your* ideas.
If you have idea about improving communication around pharo please tell us.
Stef
-- www.tudorgirba.com www.feenk.com "Every successful trip needs a suitable vehicle."
Hi Stef, 2016-08-25 3:48 GMT-03:00 stepharo <stepharo@free.fr>:
Hi hernan
Could you reply to my mail? Because what is important is how we can make progres.
Ok, here it is :)
About GT I have some concerns too now I see also a lot of improvements. I love GTInspector and we should remove EyeInspector.
I want to have once brick is out another minimal environment not based on anything so that we can have a back-door to debug when the other tools have a problems.
Cool you are considering this situation.
Now some answers:
Then it makes no sense raise any form of criticism, or the board, if by definition lobby groups silence any possible mistake.
No this is wrong. You can criticize as I criticize but you should give clear actionable points. Else this is Oh XX is bad. Tell us how we can address your problems and we will try. Without clear feedback we cannot act.
I'm afraid my english is good enough to provide clear feedback. I try to do my best without offending anyone (see below)
2. Features that goes inside Pharo are not decided by vote. They have to
add value and share the Pharo vision (pointed in the vision document who is not slightly updated but still guides our steps). We try to reach consensus and if it is not possible, then we decide. Yes, is like that⦠Iâm sorry for not being perfect democratic but this was never the idea of Pharo (it *has* a benevolent dictator⦠who by the way is not me but a group, the board).
Ok, now people can see one reason why Pharo is light years from the popularity of other OSS. I don't get how do you expect success with Pharo if you never change your mindset... I read a lot of papers and see KDE, gcc, Linux, NetBeans, Python, Mozilla, Apache collaboration models... never *ever* read something like that, specially now where OSS literature is considering distributed democracy.
Sorry but - you would be surprised by how many people would vote to get GT tools inside Pharo :)
In my opinion is because it is biased by the same people who is behind, or invested time testing/fixing it, and we are few to have a valuable N. This will never be fair, newbies will ignore the old inspector/explorer (yes, the old one from Squeak) was just fine and was easily understandable and extensible just adding a few methods. And, I repeat in my opinion, a new inspector isn't really a high priority for our world problems (big data is, for example), much less a framework.... So that's my view on it. But that's all, decision was taken. Now we have to move on.
- then I do not know what to tell you because I'm quite sure that Apache or Mozilla are not managed by vote of people.
Just a few references you, or the board, may consider for the future : Python: https://www.python.org/psf/membership/#who-is-allowed-to-vote KDE : " A "KDE Core Team" uses a democratic voting procedure to resolve important issues " Apache HTTPD : " Proposed changes are voted upon via mailing list; 3 yes votes with no vetos are required to commit a change " Mozilla : "A review and super-review process is required for most code changes." http://flosshub.org/sites/flosshub.org/files/HalloranScherlis.pdf "It is important to keep users involved in the process and not treat them as second-class citizens." Richard P. Gabriel http://www.dreamsongs.com/IHE/IHE-52.html
In the end, time will tell, but can you cite another successful open source project with such "model"?
Sorry I do not have the time to know. We want an doit model: doing in things should be more important than suh having needs (even if clients and users are important)
4. You have a very negative opinion about our design choices. Thatâs ok,
but we are not going to remove GT just because you dislike it.
It's not because of just my dislike. It's because it was never proposed for inclusion (it was just decided), it is because you make it almost impossible to uninstall it, and because it was integrated very early like an enhacement/future/vision set of tools without any votes, or high-resistance policy like many Open-Source projects, and judging by the volume of mails it required a lot of of time of beta-testing by many users.
You mean beside me someone was not really happy? Seriously? Now you can not use Spotter so I do not see the problem. The Debugger is working well. Playground looks like a default workspace. Then GTInspector works perfectly for me.
To be clear, it's not against GT specifically (I don't like it, too slow, takes too much space, etc) but the integration process behind, where the board delivered it and seemed to said f**ck you this must be loved, deal with it if don't. But then we don't have an easy way too uninstall it, I have to spend days investigating how to remove it disabling settings in specific order, and without leaving obsolete instances all around. So what's my proposal for a next release? Respect the freedom of choice for people which is not obligated to love all your tools, by providing an uninstall option (if the tool is not really essential)
I would love to have the time to invite you, or any GT developer, to work with me just one week with real DNA data, and see how well GT goes...
Please do a skype sharing session with Andrei and Doru. I'm sure that they will love to do it. So I take your words and urge you do it. It will help you to get out your frsutration and I'm sure that GT will improve. So a clear win/win situation.
This is hard for me because I'm sure at this point Andrei and Doru should be angry with me for ciriticizing their work. But I will try to make some use cases these days and share with you so I can show you specifically what I'm talking about.
Maybe I should be sorry for not being as obedient and blindly accepting all board decisions as the word of God, as many on this list.
Can you imagine one moment that people like it?
I know people like it. This is not against people but against conformity. I am saying the board, at some point, may have to reflect on if decisions taken and results obtained aren't masked by "likes" and **may be** raising questions like if we want to compete with Python because with such a crappy eval they have hundreds of libraries used by millions, and we are still discussing why there isn't uninstallers.
Understood, what makes me most sad is users almost accepted they cannot do better and if they do, their work will never be integrated by default.
No do better. Why I started Spec when ther was Glamour. Why Alain was working on Calipso? I would love that someone comes and tell me: take XX it is super hyper cool UI Builder.
Me too, and by this point we should really ask ourselves why we don't have yet a cool UI Builder. Hernán Instead, non-voters decisions discourages users to be rewarded for their
creativity, and imposes many others to work free "supporting" tools which were imposed de facto.
So again, I cannot stress this enough: Is my job to say no. I know I hurt some people but social development is complicated. I do not think I do a bad job :)
Me neither, but you cannot expect conformity from all of us.
Hernán
cheers! Esteban
On 24 Aug 2016, at 09:38, stepharo <stepharo@free.fr> wrote:
Hi Hernan
First thanks for your email because we may disagree but we often agree. :) so this is an email for me.
Hi Stef,
Good communication implies being clear when writing about sensitive topics, especially when communicating through virtual channels. I am not in Europe, so I cannot discuss these things with you face to face.
This is what we want to change with montly videos meeting.
Therefore is not clear to me (and others) what are your policies in many subjects. Lately I also delayed the release of packages because my lack of motivation around this community, specially when discussions exists around three or fourth topics for months.
Like what? Let us know because we do not
Another "motivational" case for me. I stopped to report bugs in fogbuz because I felt there was too much "Won't fix" for me (specifically by a person but I won't go there...) even in cases where it was ilogical. Then I felt tired of reading "It's like that. Invalid".
This is a pity. I know the feeling because some of mine are close too. You are not the only victim of the "Issue closing syndrom" ;). And I would like the syndrome to be more human friendly. Thanks for raising this point.
Now two points - You should always send a mail to the mailing-list and that we discuss your points.
- Now what will happen if we all open bugs and none of us works on the open bugs. So what is the solution for you. I mean it concretely. How to deal with dying
Looking at bugs is really difficult. There are not enough people looking and fixing bugs.
About features.
What's the policy about voting for default features in next Pharo images? Let's suppose I am a VM/core Pharo maintainer and I want to include MySuperPackage into a Pharo release, which nobody needs (and I don't care), but it is useful to me.... there will ever be voting there? (note it doesn't makes sense if you are a group of 50 always supporting your work)
It does not really work because engineers are paid for certain task.
Images are becoming huge (at least for my workflows). There will be (more) packages included by default (for promotion?) ?
Thanks to raise this point because I mentioned it also to the board. So I like when I'm not alone. Now we should not see look only at the size. Doing nothing is size zero :) The point is what are the functionalities delivered.
Three points: - what are the key things we want? keybinding, settings, cool inspector cool....
- how many duplicated functionality can we remove: for example I want to merge MCDefinitions with Ring with RBDefinition we removed pseudo* but this is a lot of work
The goal is to throw many system when bloc and brick are ready
- what is the list of things that you would remove?
- with the bootstrap and all the packages of the image managed with Cargo plus the git management we believe that we will be able to manage a set of images with minimal images. - this is several years that we are working on this goal. Believe me this is the vision document not for the sake of it.
How do you plan to manage if some people want the Tests be removed from the official Image? (Personally I never run them)
- then you use a jenkins job to produce your image where you unload the tests.
Another example, what happens if another research group came with a better alternative to Calypso, Brick, Telescope, Bloc. Would you integrate first your tool to mark territory?
No this is not a question of territory. Doru and GT does not do that in that spirit. RMOD too. We do something when we think that this is better. For example Epicea is three years of work of Martin, Fuel was so nice that we could not lose it. You see Ghost got changed by denis, Seamless got rewritten from scratch.
Who decides? For example (IIRC) TxText and Twisty.
Igor looked at Twisty seriously and I do not think that it could handle large cobol files.
(you see funnily denis is doing the same with Seamless - He rewrote it from scratch while nick worked on it for several years).
Igor wanted to have a stream-based API that could work on modern command-oriented videos card framework. My team (on our own money if you understand what it means) paid Igor to build TxText (and I can tell you that I would have prefered him to do something else).
The same applies if anyone came with another rewrite of classic Smalltalk Workspace, Debugger and Inspector tools, what would you do with GT? GT stays because it came before and others would be optional?
No this is not like that. If you are better or answer better needs.
There will be anything like PEPs?
I would love but will people have the energy to implement them? I would definitively encourage you as a community to raise points on what you need.
If someone can answer me I think that would be an example of good communication.
Hernan I always answered your emails. I always consider your work (and you know it for other reasons and by my facts) after I'm not always in agreement as I'm not always in agreement with other board members and this is how live happens. What is clear is that the most important aspects is to continue to communicate. This is why the board is launching this initiative and I would love to see it taken by people even for their projects.
Hernán
2016-08-24 1:51 GMT-03:00 stepharo <stepharo@free.fr>:
Hi guys
the board got a good discussion at ESUG about how to improve and a lot of the discussion turned around improving communication. We got some ideas that we will propose soon but I would like to get *your* ideas.
If you have idea about improving communication around pharo please tell us.
Stef
About GT I have some concerns too now I see also a lot of improvements. I love GTInspector and we should remove EyeInspector.
I want to have once brick is out another minimal environment not based on anything so that we can have a back-door to debug when the other tools have a problems.
Cool you are considering this situation.
We **always** considered it because we aim at building minimal kernels but if Pharo would be only about that then nobody would use it. In PetitsBazars/Ondo is a little try I did to understand what I wanted. And we are not just considering it. We should have it. Now I was waiting for better widgets because I started to hate pluggable* Now if you have the code of the old inspector at hand package it and we will include it and remove the eyeinspector.
Now some answers:
I'm afraid my english is good enough to provide clear feedback. I try to do my best without offending anyone (see below)
I understand really well what you mean. :) Now the key points is how can we turn things positively. Sorry but
- you would be surprised by how many people would vote to get GT tools inside Pharo :)
In my opinion is because it is biased by the same people who is behind, or invested time testing/fixing it, and we are few to have a valuable N. This will never be fair, newbies will ignore the old inspector/explorer (yes, the old one from Squeak) was just fine and was easily understandable and extensible just adding a few methods. And, I repeat in my opinion, a new inspector isn't really a high priority for our world problems (big data is, for example), much less a framework.... So that's my view on it.
But that's all, decision was taken. Now we have to move on.
No I want a basic inspector in the system :)
- then I do not know what to tell you because I'm quite sure that Apache or Mozilla are not managed by vote of people.
Just a few references you, or the board, may consider for the future :
Python: https://www.python.org/psf/membership/#who-is-allowed-to-vote <https://www.python.org/psf/membership/#who-is-allowed-to-vote> KDE : " A "KDE Core Team" uses a democratic voting procedure to resolve important issues " Apache HTTPD : " Proposed changes are voted upon via mailing list; 3 yes votes with no vetos are required to commit a change " Mozilla : "A review and super-review process is required for most code changes."
http://flosshub.org/sites/flosshub.org/files/HalloranScherlis.pdf <http://flosshub.org/sites/flosshub.org/files/HalloranScherlis.pdf>
"It is important to keep users involved in the process and not treat them as second-class citizens." Richard P. Gabriel http://www.dreamsongs.com/IHE/IHE-52.html <http://www.dreamsongs.com/IHE/IHE-52.html>
We are not treating people as second citizens.
To be clear, it's not against GT specifically (I don't like it, too slow, takes too much space, etc) but the integration process behind, where the board delivered it and seemed to said f**ck you this must be loved, deal with it if don't. But then we don't have an easy way too uninstall it, I have to spend days investigating how to remove it disabling settings in specific order, and without leaving obsolete instances all around. So what's my proposal for a next release?
Can you publish the unload process?
Respect the freedom of choice for people which is not obligated to love all your tools, by providing an uninstall option (if the tool is not really essential) I agree about the Unload.... Joseph Pelrine always told me that we are only done when we can upload and that the system is in a good shape.
You may not know it because I spent days working on configuration of RB and friends The problems is that it is a hell to keep them up to date (because of our image). We should have a building process from a seed. Because like that you experiment every single day that you loading script. Now we did not stress enough the unload of Metacello. Now you see Pharo cannot be an empty shell. Because what will happen if we are always listening to someone that does not like something. Now I strongly encourage you to watch the esug talk about bootstrap because with it and all the work of Pavel to define configurations for all the part of the system so people will be able to build their solutions when the official version does not suite their needs.
I would love to have the time to invite you, or any GT developer, to work with me just one week with real DNA data, and see how well GT goes...
Please do a skype sharing session with Andrei and Doru. I'm sure that they will love to do it. So I take your words and urge you do it. It will help you to get out your frsutration and I'm sure that GT will improve. So a clear win/win situation.
This is hard for me because I'm sure at this point Andrei and Doru should be angry with me for ciriticizing their work.
No I do not think so :) I criticized their tools too.
But I will try to make some use cases these days and share with you so I can show you specifically what I'm talking about. Excellent!
Understood, what makes me most sad is users almost accepted they cannot do better and if they do, their work will never be integrated by default.
No do better. Why I started Spec when ther was Glamour. Why Alain was working on Calipso? I would love that someone comes and tell me: take XX it is super hyper cool UI Builder.
Me too, and by this point we should really ask ourselves why we don't have yet a cool UI Builder. Because nobody did it in a way that we can use it.
One guy worked alone on a private project long time ago. We could not give him any feedback because he wanted to have it perfect in the first place. He stoped to work on it because of bad table support. I looked at it once he opened-source it and you would not like to have the code in Pharo. Stef
Hernán
Instead, non-voters decisions discourages users to be rewarded for their creativity, and imposes many others to work free "supporting" tools which were imposed de facto.
So again, I cannot stress this enough: Is my job to say no. I know I hurt some people but social development is complicated. I do not think I do a bad job :)
Me neither, but you cannot expect conformity from all of us.
Hernán
cheers! Esteban
On 24 Aug 2016, at 09:38, stepharo <stepharo@free.fr <mailto:stepharo@free.fr>> wrote:
Hi Hernan
First thanks for your email because we may disagree but we often agree. :) so this is an email for me.
Hi Stef,
Good communication implies being clear when writing about sensitive topics, especially when communicating through virtual channels. I am not in Europe, so I cannot discuss these things with you face to face.
This is what we want to change with montly videos meeting.
Therefore is not clear to me (and others) what are your policies in many subjects. Lately I also delayed the release of packages because my lack of motivation around this community, specially when discussions exists around three or fourth topics for months.
Like what? Let us know because we do not
Another "motivational" case for me. I stopped to report bugs in fogbuz because I felt there was too much "Won't fix" for me (specifically by a person but I won't go there...) even in cases where it was ilogical. Then I felt tired of reading "It's like that. Invalid".
This is a pity. I know the feeling because some of mine are close too. You are not the only victim of the "Issue closing syndrom" ;). And I would like the syndrome to be more human friendly. Thanks for raising this point.
Now two points - You should always send a mail to the mailing-list and that we discuss your points.
- Now what will happen if we all open bugs and none of us works on the open bugs. So what is the solution for you. I mean it concretely. How to deal with dying
Looking at bugs is really difficult. There are not enough people looking and fixing bugs.
About features.
What's the policy about voting for default features in next Pharo images? Let's suppose I am a VM/core Pharo maintainer and I want to include MySuperPackage into a Pharo release, which nobody needs (and I don't care), but it is useful to me.... there will ever be voting there? (note it doesn't makes sense if you are a group of 50 always supporting your work)
It does not really work because engineers are paid for certain task.
Images are becoming huge (at least for my workflows). There will be (more) packages included by default (for promotion?) ?
Thanks to raise this point because I mentioned it also to the board. So I like when I'm not alone. Now we should not see look only at the size. Doing nothing is size zero :) The point is what are the functionalities delivered.
Three points: - what are the key things we want? keybinding, settings, cool inspector cool....
- how many duplicated functionality can we remove: for example I want to merge MCDefinitions with Ring with RBDefinition we removed pseudo* but this is a lot of work
The goal is to throw many system when bloc and brick are ready
- what is the list of things that you would remove?
- with the bootstrap and all the packages of the image managed with Cargo plus the git management we believe that we will be able to manage a set of images with minimal images. - this is several years that we are working on this goal. Believe me this is the vision document not for the sake of it.
How do you plan to manage if some people want the Tests be removed from the official Image? (Personally I never run them)
- then you use a jenkins job to produce your image where you unload the tests.
Another example, what happens if another research group came with a better alternative to Calypso, Brick, Telescope, Bloc. Would you integrate first your tool to mark territory?
No this is not a question of territory. Doru and GT does not do that in that spirit. RMOD too. We do something when we think that this is better. For example Epicea is three years of work of Martin, Fuel was so nice that we could not lose it. You see Ghost got changed by denis, Seamless got rewritten from scratch.
Who decides? For example (IIRC) TxText and Twisty.
Igor looked at Twisty seriously and I do not think that it could handle large cobol files.
(you see funnily denis is doing the same with Seamless - He rewrote it from scratch while nick worked on it for several years).
Igor wanted to have a stream-based API that could work on modern command-oriented videos card framework. My team (on our own money if you understand what it means) paid Igor to build TxText (and I can tell you that I would have prefered him to do something else).
The same applies if anyone came with another rewrite of classic Smalltalk Workspace, Debugger and Inspector tools, what would you do with GT? GT stays because it came before and others would be optional?
No this is not like that. If you are better or answer better needs.
There will be anything like PEPs?
I would love but will people have the energy to implement them? I would definitively encourage you as a community to raise points on what you need.
If someone can answer me I think that would be an example of good communication.
Hernan I always answered your emails. I always consider your work (and you know it for other reasons and by my facts) after I'm not always in agreement as I'm not always in agreement with other board members and this is how live happens. What is clear is that the most important aspects is to continue to communicate. This is why the board is launching this initiative and I would love to see it taken by people even for their projects.
Hernán
2016-08-24 1:51 GMT-03:00 stepharo <stepharo@free.fr <mailto:stepharo@free.fr>>:
Hi guys
the board got a good discussion at ESUG about how to improve and a lot of the discussion turned around improving communication. We got some ideas that we will propose soon but I would like to get *your* ideas.
If you have idea about improving communication around pharo please tell us.
Stef
2016-08-26 6:19 GMT-03:00 stepharo <stepharo@free.fr>:
About GT I have some concerns too now I see also a lot of improvements. I
love GTInspector and we should remove EyeInspector.
I want to have once brick is out another minimal environment not based on anything so that we can have a back-door to debug when the other tools have a problems.
Cool you are considering this situation.
We **always** considered it because we aim at building minimal kernels but if Pharo would be only about that then nobody would use it. In PetitsBazars/Ondo is a little try I did to understand what I wanted. And we are not just considering it. We should have it. Now I was waiting for better widgets because I started to hate pluggable*
Now if you have the code of the old inspector at hand package it and we will include it and remove the eyeinspector.
Now some answers:
I'm afraid my english is good enough to provide clear feedback. I try to do my best without offending anyone (see below)
I understand really well what you mean. :) Now the key points is how can we turn things positively. Sorry but
- you would be surprised by how many people would vote to get GT tools
inside Pharo :)
In my opinion is because it is biased by the same people who is behind, or invested time testing/fixing it, and we are few to have a valuable N. This will never be fair, newbies will ignore the old inspector/explorer (yes, the old one from Squeak) was just fine and was easily understandable and extensible just adding a few methods. And, I repeat in my opinion, a new inspector isn't really a high priority for our world problems (big data is, for example), much less a framework.... So that's my view on it.
But that's all, decision was taken. Now we have to move on.
No I want a basic inspector in the system :)
- then I do not know what to tell you because I'm quite sure that Apache or Mozilla are not managed by vote of people.
Just a few references you, or the board, may consider for the future :
Python: https://www.python.org/psf/membership/#who-is-allowed-to-vote KDE : " A "KDE Core Team" uses a democratic voting procedure to resolve important issues " Apache HTTPD : " Proposed changes are voted upon via mailing list; 3 yes votes with no vetos are required to commit a change " Mozilla : "A review and super-review process is required for most code changes."
http://flosshub.org/sites/flosshub.org/files/HalloranScherlis.pdf
"It is important to keep users involved in the process and not treat them as second-class citizens." Richard P. Gabriel http://www.dreamsongs.com/IHE/IHE-52.html
We are not treating people as second citizens.
To be clear, it's not against GT specifically (I don't like it, too slow, takes too much space, etc) but the integration process behind, where the board delivered it and seemed to said f**ck you this must be loved, deal with it if don't. But then we don't have an easy way too uninstall it, I have to spend days investigating how to remove it disabling settings in specific order, and without leaving obsolete instances all around. So what's my proposal for a next release?
Can you publish the unload process?
Workspace openContents: 'GTPlayground setGTPlaygroundEnabledStatus: false. " ========== Debuggers ========== " Nautilus pluginClasses: nil. SpecDebugger closeAllDebuggers. GTGenericStackDebugger closeAllDebuggers. GTGenericStackDebugger setGTDebuggerEnabledStatus: false. " ========== Miscellany ========== " GTInspector setGTInspectorEnabledStatus: false. GTExampleOrganizer stop. GTEventRecorder cleanUp. GTEventRecorderSettings cleanUp. GTSnippets reset. GTPlayBook reset. GTPlayBook resetDirectories. GTSpotter cleanUp. GTSpotterGlobalShortcut reset. GlobalIdentifier cleanUp. Privacy cleanUp. " ========== QA ========== " QASettings inspectorPluggin: false. QASettings spotterPlugin: false. QAEventCollector unload. (MCPackage named: ''QualityAssistant'') unload. " ========== RPackage ========== " RPackageOrganizer default packageNames select: [ :each | each beginsWith: ''GT'' ] thenDo: [ :each | (MCPackage named: each) unload. RPackageOrganizer default unregisterPackageNamed: each. " Possibly unnecessary... " Smalltalk removeEmptyMessageCategories. Smalltalk cleanOutUndeclared. Smalltalk fixObsoleteReferences. Smalltalk globals flushClassNameCache ]. Behavior flushEvents. Behavior flushObsoleteSubclasses. SmalltalkImage current resetTools.' I still have some obsoletes around AnObsoleteGTSpotterGlobalShortcut . AnObsoleteQANautilusPlugin . AnObsoleteGTExampleFinder AnObsoleteGTExampleOrganizer AnObsoleteGTSpotterProfiler AnObsoleteGTEventCollector AnObsoleteGTExampleNotDefinedRule Tried to clean but no sucess so far.
Respect the freedom of choice for people which is not obligated to love all your tools, by providing an uninstall option (if the tool is not really essential)
I agree about the Unload.... Joseph Pelrine always told me that we are only done when we can upload and that the system is in a good shape.
You may not know it because I spent days working on configuration of RB and friends The problems is that it is a hell to keep them up to date (because of our image). We should have a building process from a seed. Because like that you experiment every single day that you loading script. Now we did not stress enough the unload of Metacello.
Now you see Pharo cannot be an empty shell. Because what will happen if we are always listening to someone that does not like something. Now I strongly encourage you to watch the esug talk about bootstrap because with it and all the work of Pavel to define configurations for all the part of the system so people will be able to build their solutions when the official version does not suite their needs.
I would love to have the time to invite you, or any GT developer, to work with me just one week with real DNA data, and see how well GT goes...
Please do a skype sharing session with Andrei and Doru. I'm sure that they will love to do it. So I take your words and urge you do it. It will help you to get out your frsutration and I'm sure that GT will improve. So a clear win/win situation.
This is hard for me because I'm sure at this point Andrei and Doru should be angry with me for ciriticizing their work.
No I do not think so :) I criticized their tools too.
But I will try to make some use cases these days and share with you so I can show you specifically what I'm talking about.
Excellent!
Understood, what makes me most sad is users almost accepted they cannot do
better and if they do, their work will never be integrated by default.
No do better. Why I started Spec when ther was Glamour. Why Alain was working on Calipso? I would love that someone comes and tell me: take XX it is super hyper cool UI Builder.
Me too, and by this point we should really ask ourselves why we don't have yet a cool UI Builder.
Because nobody did it in a way that we can use it.
One guy worked alone on a private project long time ago. We could not give him any feedback because he wanted to have it perfect in the first place. He stoped to work on it because of bad table support. I looked at it once he opened-source it and you would not like to have the code in Pharo.
Stef
Hernán
Instead, non-voters decisions discourages users to be rewarded for their
creativity, and imposes many others to work free "supporting" tools which were imposed de facto.
So again, I cannot stress this enough: Is my job to say no. I know I hurt some people but social development is complicated. I do not think I do a bad job :)
Me neither, but you cannot expect conformity from all of us.
Hernán
cheers! Esteban
On 24 Aug 2016, at 09:38, stepharo <stepharo@free.fr> wrote:
Hi Hernan
First thanks for your email because we may disagree but we often agree. :) so this is an email for me.
Hi Stef,
Good communication implies being clear when writing about sensitive topics, especially when communicating through virtual channels. I am not in Europe, so I cannot discuss these things with you face to face.
This is what we want to change with montly videos meeting.
Therefore is not clear to me (and others) what are your policies in many subjects. Lately I also delayed the release of packages because my lack of motivation around this community, specially when discussions exists around three or fourth topics for months.
Like what? Let us know because we do not
Another "motivational" case for me. I stopped to report bugs in fogbuz because I felt there was too much "Won't fix" for me (specifically by a person but I won't go there...) even in cases where it was ilogical. Then I felt tired of reading "It's like that. Invalid".
This is a pity. I know the feeling because some of mine are close too. You are not the only victim of the "Issue closing syndrom" ;). And I would like the syndrome to be more human friendly. Thanks for raising this point.
Now two points - You should always send a mail to the mailing-list and that we discuss your points.
- Now what will happen if we all open bugs and none of us works on the open bugs. So what is the solution for you. I mean it concretely. How to deal with dying
Looking at bugs is really difficult. There are not enough people looking and fixing bugs.
About features.
What's the policy about voting for default features in next Pharo images? Let's suppose I am a VM/core Pharo maintainer and I want to include MySuperPackage into a Pharo release, which nobody needs (and I don't care), but it is useful to me.... there will ever be voting there? (note it doesn't makes sense if you are a group of 50 always supporting your work)
It does not really work because engineers are paid for certain task.
Images are becoming huge (at least for my workflows). There will be (more) packages included by default (for promotion?) ?
Thanks to raise this point because I mentioned it also to the board. So I like when I'm not alone. Now we should not see look only at the size. Doing nothing is size zero :) The point is what are the functionalities delivered.
Three points: - what are the key things we want? keybinding, settings, cool inspector cool....
- how many duplicated functionality can we remove: for example I want to merge MCDefinitions with Ring with RBDefinition we removed pseudo* but this is a lot of work
The goal is to throw many system when bloc and brick are ready
- what is the list of things that you would remove?
- with the bootstrap and all the packages of the image managed with Cargo plus the git management we believe that we will be able to manage a set of images with minimal images. - this is several years that we are working on this goal. Believe me this is the vision document not for the sake of it.
How do you plan to manage if some people want the Tests be removed from the official Image? (Personally I never run them)
- then you use a jenkins job to produce your image where you unload the tests.
Another example, what happens if another research group came with a better alternative to Calypso, Brick, Telescope, Bloc. Would you integrate first your tool to mark territory?
No this is not a question of territory. Doru and GT does not do that in that spirit. RMOD too. We do something when we think that this is better. For example Epicea is three years of work of Martin, Fuel was so nice that we could not lose it. You see Ghost got changed by denis, Seamless got rewritten from scratch.
Who decides? For example (IIRC) TxText and Twisty.
Igor looked at Twisty seriously and I do not think that it could handle large cobol files.
(you see funnily denis is doing the same with Seamless - He rewrote it from scratch while nick worked on it for several years).
Igor wanted to have a stream-based API that could work on modern command-oriented videos card framework. My team (on our own money if you understand what it means) paid Igor to build TxText (and I can tell you that I would have prefered him to do something else).
The same applies if anyone came with another rewrite of classic Smalltalk Workspace, Debugger and Inspector tools, what would you do with GT? GT stays because it came before and others would be optional?
No this is not like that. If you are better or answer better needs.
There will be anything like PEPs?
I would love but will people have the energy to implement them? I would definitively encourage you as a community to raise points on what you need.
If someone can answer me I think that would be an example of good communication.
Hernan I always answered your emails. I always consider your work (and you know it for other reasons and by my facts) after I'm not always in agreement as I'm not always in agreement with other board members and this is how live happens. What is clear is that the most important aspects is to continue to communicate. This is why the board is launching this initiative and I would love to see it taken by people even for their projects.
Hernán
2016-08-24 1:51 GMT-03:00 stepharo <stepharo@free.fr>:
Hi guys
the board got a good discussion at ESUG about how to improve and a lot of the discussion turned around improving communication. We got some ideas that we will propose soon but I would like to get *your* ideas.
If you have idea about improving communication around pharo please tell us.
Stef
What we should do is to add an unload method to each of the package manifest of the corresponding projects. We should make the unload protocol a lot more present. I will start with Nautilus.
Can you publish the unload process?
Workspace openContents: 'GTPlayground setGTPlaygroundEnabledStatus: false. " ========== Debuggers ========== "
Nautilus pluginClasses: nil. SpecDebugger closeAllDebuggers. GTGenericStackDebugger closeAllDebuggers. GTGenericStackDebugger setGTDebuggerEnabledStatus: false.
" ========== Miscellany ========== "
GTInspector setGTInspectorEnabledStatus: false. GTExampleOrganizer stop. GTEventRecorder cleanUp. GTEventRecorderSettings cleanUp. GTSnippets reset. GTPlayBook reset. GTPlayBook resetDirectories. GTSpotter cleanUp. GTSpotterGlobalShortcut reset.
GlobalIdentifier cleanUp. Privacy cleanUp.
" ========== QA ========== " QASettings inspectorPluggin: false. QASettings spotterPlugin: false. QAEventCollector unload. (MCPackage named: ''QualityAssistant'') unload.
" ========== RPackage ========== " RPackageOrganizer default packageNames select: [ :each | each beginsWith: ''GT'' ] thenDo: [ :each | (MCPackage named: each) unload. RPackageOrganizer default unregisterPackageNamed: each. " Possibly unnecessary... " Smalltalk removeEmptyMessageCategories. Smalltalk cleanOutUndeclared. Smalltalk fixObsoleteReferences. Smalltalk globals flushClassNameCache ].
Behavior flushEvents. Behavior flushObsoleteSubclasses. SmalltalkImage current resetTools.'
I still have some obsoletes around
AnObsoleteGTSpotterGlobalShortcut . AnObsoleteQANautilusPlugin . AnObsoleteGTExampleFinder AnObsoleteGTExampleOrganizer AnObsoleteGTSpotterProfiler AnObsoleteGTEventCollector AnObsoleteGTExampleNotDefinedRule
Tried to clean but no sucess so far.
Respect the freedom of choice for people which is not obligated to love all your tools, by providing an uninstall option (if the tool is not really essential)
I agree about the Unload.... Joseph Pelrine always told me that we are only done when we can upload and that the system is in a good shape.
You may not know it because I spent days working on configuration of RB and friends The problems is that it is a hell to keep them up to date (because of our image). We should have a building process from a seed. Because like that you experiment every single day that you loading script. Now we did not stress enough the unload of Metacello.
Now you see Pharo cannot be an empty shell. Because what will happen if we are always listening to someone that does not like something. Now I strongly encourage you to watch the esug talk about bootstrap because with it and all the work of Pavel to define configurations for all the part of the system so people will be able to build their solutions when the official version does not suite their needs.
I would love to have the time to invite you, or any GT developer, to work with me just one week with real DNA data, and see how well GT goes...
Please do a skype sharing session with Andrei and Doru. I'm sure that they will love to do it. So I take your words and urge you do it. It will help you to get out your frsutration and I'm sure that GT will improve. So a clear win/win situation.
This is hard for me because I'm sure at this point Andrei and Doru should be angry with me for ciriticizing their work.
No I do not think so :) I criticized their tools too.
But I will try to make some use cases these days and share with you so I can show you specifically what I'm talking about.
Excellent!
Understood, what makes me most sad is users almost accepted they cannot do better and if they do, their work will never be integrated by default.
No do better. Why I started Spec when ther was Glamour. Why Alain was working on Calipso? I would love that someone comes and tell me: take XX it is super hyper cool UI Builder.
Me too, and by this point we should really ask ourselves why we don't have yet a cool UI Builder. Because nobody did it in a way that we can use it.
One guy worked alone on a private project long time ago. We could not give him any feedback because he wanted to have it perfect in the first place. He stoped to work on it because of bad table support. I looked at it once he opened-source it and you would not like to have the code in Pharo.
Stef
Hernán
Instead, non-voters decisions discourages users to be rewarded for their creativity, and imposes many others to work free "supporting" tools which were imposed de facto.
So again, I cannot stress this enough: Is my job to say no. I know I hurt some people but social development is complicated. I do not think I do a bad job :)
Me neither, but you cannot expect conformity from all of us.
Hernán
cheers! Esteban
On 24 Aug 2016, at 09:38, stepharo <stepharo@free.fr <mailto:stepharo@free.fr>> wrote:
Hi Hernan
First thanks for your email because we may disagree but we often agree. :) so this is an email for me.
Hi Stef,
Good communication implies being clear when writing about sensitive topics, especially when communicating through virtual channels. I am not in Europe, so I cannot discuss these things with you face to face.
This is what we want to change with montly videos meeting.
Therefore is not clear to me (and others) what are your policies in many subjects. Lately I also delayed the release of packages because my lack of motivation around this community, specially when discussions exists around three or fourth topics for months.
Like what? Let us know because we do not
Another "motivational" case for me. I stopped to report bugs in fogbuz because I felt there was too much "Won't fix" for me (specifically by a person but I won't go there...) even in cases where it was ilogical. Then I felt tired of reading "It's like that. Invalid".
This is a pity. I know the feeling because some of mine are close too. You are not the only victim of the "Issue closing syndrom" ;). And I would like the syndrome to be more human friendly. Thanks for raising this point.
Now two points - You should always send a mail to the mailing-list and that we discuss your points.
- Now what will happen if we all open bugs and none of us works on the open bugs. So what is the solution for you. I mean it concretely. How to deal with dying
Looking at bugs is really difficult. There are not enough people looking and fixing bugs.
About features.
What's the policy about voting for default features in next Pharo images? Let's suppose I am a VM/core Pharo maintainer and I want to include MySuperPackage into a Pharo release, which nobody needs (and I don't care), but it is useful to me.... there will ever be voting there? (note it doesn't makes sense if you are a group of 50 always supporting your work)
It does not really work because engineers are paid for certain task.
Images are becoming huge (at least for my workflows). There will be (more) packages included by default (for promotion?) ?
Thanks to raise this point because I mentioned it also to the board. So I like when I'm not alone. Now we should not see look only at the size. Doing nothing is size zero :) The point is what are the functionalities delivered.
Three points: - what are the key things we want? keybinding, settings, cool inspector cool....
- how many duplicated functionality can we remove: for example I want to merge MCDefinitions with Ring with RBDefinition we removed pseudo* but this is a lot of work
The goal is to throw many system when bloc and brick are ready
- what is the list of things that you would remove?
- with the bootstrap and all the packages of the image managed with Cargo plus the git management we believe that we will be able to manage a set of images with minimal images. - this is several years that we are working on this goal. Believe me this is the vision document not for the sake of it.
How do you plan to manage if some people want the Tests be removed from the official Image? (Personally I never run them)
- then you use a jenkins job to produce your image where you unload the tests.
Another example, what happens if another research group came with a better alternative to Calypso, Brick, Telescope, Bloc. Would you integrate first your tool to mark territory?
No this is not a question of territory. Doru and GT does not do that in that spirit. RMOD too. We do something when we think that this is better. For example Epicea is three years of work of Martin, Fuel was so nice that we could not lose it. You see Ghost got changed by denis, Seamless got rewritten from scratch.
Who decides? For example (IIRC) TxText and Twisty.
Igor looked at Twisty seriously and I do not think that it could handle large cobol files.
(you see funnily denis is doing the same with Seamless - He rewrote it from scratch while nick worked on it for several years).
Igor wanted to have a stream-based API that could work on modern command-oriented videos card framework. My team (on our own money if you understand what it means) paid Igor to build TxText (and I can tell you that I would have prefered him to do something else).
The same applies if anyone came with another rewrite of classic Smalltalk Workspace, Debugger and Inspector tools, what would you do with GT? GT stays because it came before and others would be optional?
No this is not like that. If you are better or answer better needs.
There will be anything like PEPs?
I would love but will people have the energy to implement them? I would definitively encourage you as a community to raise points on what you need.
If someone can answer me I think that would be an example of good communication.
Hernan I always answered your emails. I always consider your work (and you know it for other reasons and by my facts) after I'm not always in agreement as I'm not always in agreement with other board members and this is how live happens. What is clear is that the most important aspects is to continue to communicate. This is why the board is launching this initiative and I would love to see it taken by people even for their projects.
Hernán
2016-08-24 1:51 GMT-03:00 stepharo <stepharo@free.fr <mailto:stepharo@free.fr>>:
Hi guys
the board got a good discussion at ESUG about how to improve and a lot of the discussion turned around improving communication. We got some ideas that we will propose soon but I would like to get *your* ideas.
If you have idea about improving communication around pharo please tell us.
Stef
You see hernan doing positively is the best way to make that things happen We can have a preUnload hook Now we should check how it fits with cleanForProduction and others. But we should definitively have a way to express this. So let us see how we can design it and then just implement it. I'm sure that GT people are open to such hooks and if you really want to get a better Pharo for you then talk to them and us. https://pharo.fogbugz.com/f/cases/18997/Add-unload-to-package-manifest-in-QA https://pharo.fogbugz.com/f/cases/18998/Add-unload-to-package-manifest-of-Sp... https://pharo.fogbugz.com/f/cases/18999/Add-unload-to-package-manifest-in-GT... https://pharo.fogbugz.com/f/cases/19000/Add-unload-to-package-manifest-in-GT Stef
On 27 Aug 2016, at 11:00, stepharo <stepharo@free.fr> wrote:
You see hernan doing positively is the best way to make that things happen
We can have a
preUnload hook
Now we should check how it fits with cleanForProduction and others.
But we should definitively have a way to express this.
So let us see how we can design it and then just implement it. I'm sure that GT people are open to such hooks
and if you really want to get a better Pharo for you then talk to them and us.
https://pharo.fogbugz.com/f/cases/18997/Add-unload-to-package-manifest-in-QA
I like the idea, but how should it work? What is the package manifest? And how the unload protocol looks like? Do I only add a method called #unload to somewhere? Uko
https://pharo.fogbugz.com/f/cases/18998/Add-unload-to-package-manifest-of-Sp...
https://pharo.fogbugz.com/f/cases/18999/Add-unload-to-package-manifest-in-GT...
https://pharo.fogbugz.com/f/cases/19000/Add-unload-to-package-manifest-in-GT
Stef
Hi yuriy A package manifest is the place where we keep package rules and meta data. We should add documentation and others. I think that all the packages should have a XXXManifest. There we can define a method preUnload and after we can define a class PackageUnloader (or put the logic in the PackageOrganiser way better :)). So that we can say PackageOrganiser current unload: 'XXX' and the preUnload is executed. Stef Le 27/8/16 à 16:23, Yuriy Tymchuk a écrit :
On 27 Aug 2016, at 11:00, stepharo <stepharo@free.fr> wrote:
You see hernan doing positively is the best way to make that things happen
We can have a
preUnload hook
Now we should check how it fits with cleanForProduction and others.
But we should definitively have a way to express this.
So let us see how we can design it and then just implement it. I'm sure that GT people are open to such hooks
and if you really want to get a better Pharo for you then talk to them and us.
https://pharo.fogbugz.com/f/cases/18997/Add-unload-to-package-manifest-in-QA I like the idea, but how should it work? What is the package manifest? And how the unload protocol looks like? Do I only add a method called #unload to somewhere?
Uko
https://pharo.fogbugz.com/f/cases/18998/Add-unload-to-package-manifest-of-Sp...
https://pharo.fogbugz.com/f/cases/18999/Add-unload-to-package-manifest-in-GT...
https://pharo.fogbugz.com/f/cases/19000/Add-unload-to-package-manifest-in-GT
Stef
Hi, I think this is a great idea. Thanks for opening the issues. Now, the only question is where to put these. You suggest the package Manifest. I think this would work for individual packages, but as we are moving to projects (with Metacello), I would suggest to put these methods in the Configurations. This would also fit from a conceptual encapsulation point of view: loading and unloading are in the same place. What do you think? Doru
On Aug 27, 2016, at 11:00 AM, stepharo <stepharo@free.fr> wrote:
You see hernan doing positively is the best way to make that things happen
We can have a
preUnload hook
Now we should check how it fits with cleanForProduction and others.
But we should definitively have a way to express this.
So let us see how we can design it and then just implement it. I'm sure that GT people are open to such hooks
and if you really want to get a better Pharo for you then talk to them and us.
https://pharo.fogbugz.com/f/cases/18997/Add-unload-to-package-manifest-in-QA
https://pharo.fogbugz.com/f/cases/18998/Add-unload-to-package-manifest-of-Sp...
https://pharo.fogbugz.com/f/cases/18999/Add-unload-to-package-manifest-in-GT...
https://pharo.fogbugz.com/f/cases/19000/Add-unload-to-package-manifest-in-GT
Stef
-- www.tudorgirba.com www.feenk.com "Next time you see your life passing by, say 'hi' and get to know her."
I took the inspector from Pharo20 and I will check if it is working in Pharo. Then I will - check EyeInspector from a package perspective (extensions and the rest) - make sure that we can remove EyeInspector - package the attached file as BasicInspector. Now if you want to help you are welcome. Stef
May be we should take the one of Pharo30 and review all the code. Le 27/8/16 à 10:51, stepharo a écrit :
I took the inspector from Pharo20 and I will check if it is working in Pharo. Then I will - check EyeInspector from a package perspective (extensions and the rest) - make sure that we can remove EyeInspector - package the attached file as BasicInspector.
Now if you want to help you are welcome.
Stef
So I think that I will keep Eyeinspector for Spec because it works well using Spec. I will package BasicInspector Then we will see. I think that Smalltalk tools inspector is not good because it is yet another global while the tools should have a tool context (but with a registration mechanism to get refreshed in case). Stef Le 27/8/16 à 10:51, stepharo a écrit :
I took the inspector from Pharo20 and I will check if it is working in Pharo. Then I will - check EyeInspector from a package perspective (extensions and the rest) - make sure that we can remove EyeInspector - package the attached file as BasicInspector.
Now if you want to help you are welcome.
Stef
Dne pátek 26. srpna 2016 Hernán Morales Durand <hernan.morales@gmail.com> napsal(a):
Hi Stef,
2016-08-25 3:48 GMT-03:00 stepharo <stepharo@free.fr <javascript:_e(%7B%7D,'cvml','stepharo@free.fr');>>:
Hi hernan
Could you reply to my mail? Because what is important is how we can make progres.
Ok, here it is :)
About GT I have some concerns too now I see also a lot of improvements. I love GTInspector and we should remove EyeInspector.
I want to have once brick is out another minimal environment not based on anything so that we can have a back-door to debug when the other tools have a problems.
Cool you are considering this situation.
Now some answers:
Then it makes no sense raise any form of criticism, or the board, if by definition lobby groups silence any possible mistake.
No this is wrong. You can criticize as I criticize but you should give clear actionable points. Else this is Oh XX is bad. Tell us how we can address your problems and we will try. Without clear feedback we cannot act.
I'm afraid my english is good enough to provide clear feedback. I try to do my best without offending anyone (see below)
2. Features that goes inside Pharo are not decided by vote. They have to
add value and share the Pharo vision (pointed in the vision document who is not slightly updated but still guides our steps). We try to reach consensus and if it is not possible, then we decide. Yes, is like that⦠Iâm sorry for not being perfect democratic but this was never the idea of Pharo (it *has* a benevolent dictator⦠who by the way is not me but a group, the board).
Ok, now people can see one reason why Pharo is light years from the popularity of other OSS. I don't get how do you expect success with Pharo if you never change your mindset... I read a lot of papers and see KDE, gcc, Linux, NetBeans, Python, Mozilla, Apache collaboration models... never *ever* read something like that, specially now where OSS literature is considering distributed democracy.
Sorry but - you would be surprised by how many people would vote to get GT tools inside Pharo :)
In my opinion is because it is biased by the same people who is behind, or invested time testing/fixing it, and we are few to have a valuable N. This will never be fair, newbies will ignore the old inspector/explorer (yes, the old one from Squeak) was just fine and was easily understandable and extensible just adding a few methods. And, I repeat in my opinion, a new inspector isn't really a high priority for our world problems (big data is, for example), much less a framework.... So that's my view on it.
But that's all, decision was taken. Now we have to move on.
- then I do not know what to tell you because I'm quite sure that Apache or Mozilla are not managed by vote of people.
Just a few references you, or the board, may consider for the future :
Python: https://www.python.org/psf/membership/#who-is-allowed-to-vote KDE : " A "KDE Core Team" uses a democratic voting procedure to resolve important issues " Apache HTTPD : " Proposed changes are voted upon via mailing list; 3 yes votes with no vetos are required to commit a change " Mozilla : "A review and super-review process is required for most code changes."
http://flosshub.org/sites/flosshub.org/files/HalloranScherlis.pdf
"It is important to keep users involved in the process and not treat them as second-class citizens." Richard P. Gabriel http://www.dreamsongs.com/IHE/IHE-52.html
In the end, time will tell, but can you cite another successful open source project with such "model"?
Sorry I do not have the time to know. We want an doit model: doing in things should be more important than suh having needs (even if clients and users are important)
4. You have a very negative opinion about our design choices. Thatâs ok,
but we are not going to remove GT just because you dislike it.
It's not because of just my dislike. It's because it was never proposed for inclusion (it was just decided), it is because you make it almost impossible to uninstall it, and because it was integrated very early like an enhacement/future/vision set of tools without any votes, or high-resistance policy like many Open-Source projects, and judging by the volume of mails it required a lot of of time of beta-testing by many users.
You mean beside me someone was not really happy? Seriously? Now you can not use Spotter so I do not see the problem. The Debugger is working well. Playground looks like a default workspace. Then GTInspector works perfectly for me.
To be clear, it's not against GT specifically (I don't like it, too slow, takes too much space, etc) but the integration process behind, where the board delivered it and seemed to said f**ck you this must be loved, deal with it if don't. But then we don't have an easy way too uninstall it, I have to spend days investigating how to remove it disabling settings in specific order, and without leaving obsolete instances all around. So what's my proposal for a next release?
Respect the freedom of choice for people which is not obligated to love all your tools, by providing an uninstall option (if the tool is not really essential)
As the side-effect of the bootstrap process we are increasing granularity of the configurations of the reloaded system. Partly simply because of practical reasons. It is easier to maintain smaller subsystems. So now we are generating as intermediate steps in our bootstrap/reload process images without tools, with non-GT tools and with GT. Now these images are very far from being clean because we need firstly focus on other things but we already removed package dependencies caused by extension methods. If you want clean images without GT tools as soon as possible, your help is welcome. -- Pavel
I would love to have the time to invite you, or any GT developer, to work with me just one week with real DNA data, and see how well GT goes...
Please do a skype sharing session with Andrei and Doru. I'm sure that they will love to do it. So I take your words and urge you do it. It will help you to get out your frsutration and I'm sure that GT will improve. So a clear win/win situation.
This is hard for me because I'm sure at this point Andrei and Doru should be angry with me for ciriticizing their work. But I will try to make some use cases these days and share with you so I can show you specifically what I'm talking about.
Maybe I should be sorry for not being as obedient and blindly accepting all board decisions as the word of God, as many on this list.
Can you imagine one moment that people like it?
I know people like it. This is not against people but against conformity. I am saying the board, at some point, may have to reflect on if decisions taken and results obtained aren't masked by "likes" and **may be** raising questions like if we want to compete with Python because with such a crappy eval they have hundreds of libraries used by millions, and we are still discussing why there isn't uninstallers.
Understood, what makes me most sad is users almost accepted they cannot do better and if they do, their work will never be integrated by default.
No do better. Why I started Spec when ther was Glamour. Why Alain was working on Calipso? I would love that someone comes and tell me: take XX it is super hyper cool UI Builder.
Me too, and by this point we should really ask ourselves why we don't have yet a cool UI Builder.
Hernán
Instead, non-voters decisions discourages users to be rewarded for their
creativity, and imposes many others to work free "supporting" tools which were imposed de facto.
So again, I cannot stress this enough: Is my job to say no. I know I hurt some people but social development is complicated. I do not think I do a bad job :)
Me neither, but you cannot expect conformity from all of us.
Hernán
cheers! Esteban
On 24 Aug 2016, at 09:38, stepharo <stepharo@free.fr <javascript:_e(%7B%7D,'cvml','stepharo@free.fr');>> wrote:
Hi Hernan
First thanks for your email because we may disagree but we often agree. :) so this is an email for me.
Hi Stef,
Good communication implies being clear when writing about sensitive topics, especially when communicating through virtual channels. I am not in Europe, so I cannot discuss these things with you face to face.
This is what we want to change with montly videos meeting.
Therefore is not clear to me (and others) what are your policies in many subjects. Lately I also delayed the release of packages because my lack of motivation around this community, specially when discussions exists around three or fourth topics for months.
Like what? Let us know because we do not
Another "motivational" case for me. I stopped to report bugs in fogbuz because I felt there was too much "Won't fix" for me (specifically by a person but I won't go there...) even in cases where it was ilogical. Then I felt tired of reading "It's like that. Invalid".
This is a pity. I know the feeling because some of mine are close too. You are not the only victim of the "Issue closing syndrom" ;). And I would like the syndrome to be more human friendly. Thanks for raising this point.
Now two points - You should always send a mail to the mailing-list and that we discuss your points.
- Now what will happen if we all open bugs and none of us works on the open bugs. So what is the solution for you. I mean it concretely. How to deal with dying
Looking at bugs is really difficult. There are not enough people looking and fixing bugs.
About features.
What's the policy about voting for default features in next Pharo images? Let's suppose I am a VM/core Pharo maintainer and I want to include MySuperPackage into a Pharo release, which nobody needs (and I don't care), but it is useful to me.... there will ever be voting there? (note it doesn't makes sense if you are a group of 50 always supporting your work)
It does not really work because engineers are paid for certain task.
Images are becoming huge (at least for my workflows). There will be (more) packages included by default (for promotion?) ?
Thanks to raise this point because I mentioned it also to the board. So I like when I'm not alone. Now we should not see look only at the size. Doing nothing is size zero :) The point is what are the functionalities delivered.
Three points: - what are the key things we want? keybinding, settings, cool inspector cool....
- how many duplicated functionality can we remove: for example I want to merge MCDefinitions with Ring with RBDefinition we removed pseudo* but this is a lot of work
The goal is to throw many system when bloc and brick are ready
- what is the list of things that you would remove?
- with the bootstrap and all the packages of the image managed with Cargo plus the git management we believe that we will be able to manage a set of images with minimal images. - this is several years that we are working on this goal. Believe me this is the vision document not for the sake of it.
How do you plan to manage if some people want the Tests be removed from the official Image? (Personally I never run them)
- then you use a jenkins job to produce your image where you unload the tests.
Another example, what happens if another research group came with a better alternative to Calypso, Brick, Telescope, Bloc. Would you integrate first your tool to mark territory?
No this is not a question of territory. Doru and GT does not do that in that spirit. RMOD too. We do something when we think that this is better. For example Epicea is three years of work of Martin, Fuel was so nice that we could not lose it. You see Ghost got changed by denis, Seamless got rewritten from scratch.
Who decides? For example (IIRC) TxText and Twisty.
Igor looked at Twisty seriously and I do not think that it could handle large cobol files.
(you see funnily denis is doing the same with Seamless - He rewrote it from scratch while nick worked on it for several years).
Igor wanted to have a stream-based API that could work on modern command-oriented videos card framework. My team (on our own money if you understand what it means) paid Igor to build TxText (and I can tell you that I would have prefered him to do something else).
The same applies if anyone came with another rewrite of classic Smalltalk Workspace, Debugger and Inspector tools, what would you do with GT? GT stays because it came before and others would be optional?
No this is not like that. If you are better or answer better needs.
There will be anything like PEPs?
I would love but will people have the energy to implement them? I would definitively encourage you as a community to raise points on what you need.
If someone can answer me I think that would be an example of good communication.
Hernan I always answered your emails. I always consider your work (and you know it for other reasons and by my facts) after I'm not always in agreement as I'm not always in agreement with other board members and this is how live happens. What is clear is that the most important aspects is to continue to communicate. This is why the board is launching this initiative and I would love to see it taken by people even for their projects.
Hernán
2016-08-24 1:51 GMT-03:00 stepharo <stepharo@free.fr <javascript:_e(%7B%7D,'cvml','stepharo@free.fr');>>:
Hi guys
the board got a good discussion at ESUG about how to improve and a lot of the discussion turned around improving communication. We got some ideas that we will propose soon but I would like to get *your* ideas.
If you have idea about improving communication around pharo please tell us.
Stef
Hi 2016-08-24 18:58 GMT+02:00 Hernán Morales Durand <hernan.morales@gmail.com>:
2. Features that goes inside Pharo are not decided by vote. They have to
add value and share the Pharo vision (pointed in the vision document who is not slightly updated but still guides our steps). We try to reach consensus and if it is not possible, then we decide. Yes, is like that⦠Iâm sorry for not being perfect democratic but this was never the idea of Pharo (it *has* a benevolent dictator⦠who by the way is not me but a group, the board).
Ok, now people can see one reason why Pharo is light years from the popularity of other OSS. I don't get how do you expect success with Pharo if you never change your mindset... I read a lot of papers and see KDE, gcc, Linux, NetBeans, Python, Mozilla, Apache collaboration models... never *ever* read something like that, specially now where OSS literature is considering distributed democracy.
I would say Pharo is still too young. And Pharo parents want to bring up it in own way. I think at some point Pharo could become adult enough to move away from parents (in good meaning of these words:) (without losing respect to parents vision)).
On Wed, 24 Aug 2016 09:38:20 +0200 stepharo <stepharo@free.fr> wrote: Hello,
Looking at bugs is really difficult. There are not enough people looking and fixing bugs.
just a short note from a Pharo noob...it is, imho, very strange that one cannot even take a look at bugs *without* creating account at tracker. By having ability to, at least, skim at bugs and see if there are some low-hanging fruits to tackle, maybe more work could be accomplished? Having issue tracker closed for the public emits, imho, not very friendly signal to potential contributors. Sincerely, Gour -- Just try to learn the truth by approaching a spiritual master. Inquire from him submissively and render service unto him. The self-realized souls can impart knowledge unto you because they have seen the truth.
On 24 Aug 2016, at 10:07, Gour <gour@atmarama.com> wrote:
On Wed, 24 Aug 2016 09:38:20 +0200 stepharo <stepharo@free.fr> wrote:
Hello,
Looking at bugs is really difficult. There are not enough people looking and fixing bugs.
just a short note from a Pharo noob...it is, imho, very strange that one cannot even take a look at bugs *without* creating account at tracker.
By having ability to, at least, skim at bugs and see if there are some low-hanging fruits to tackle, maybe more work could be accomplished?
Having issue tracker closed for the public emits, imho, not very friendly signal to potential contributors.
yes, this is bad but fogbugz is a company that does issue tracking for big companies, not open source projects so they do not have this feature. You may ask then why we use them⦠is because we used to use google issue tracker and when they dropped support we needed some replacement. Long story short, none of the open issue tracker offered what we needed and fogbugz people kindly offered to give us a free account. Now we would like to solve this problem but is hard to leave because migration is a lot of work and also (very important) because maybe fogbugz does not looks super cool, but is an *excellent* tool for tracking our issues⦠so we would need to find time to define a news process if we want to use, for example github or atlassian⦠cheers, Esteban
Sincerely, Gour
-- Just try to learn the truth by approaching a spiritual master. Inquire from him submissively and render service unto him. The self-realized souls can impart knowledge unto you because they have seen the truth.
Hello,
Looking at bugs is really difficult. There are not enough people looking and fixing bugs. just a short note from a Pharo noob...it is, imho, very strange that one cannot even take a look at bugs *without* creating account at tracker.
We know. Now the company offered us a professional service (cost around 25$ per month per user) for free. And also to maintain it. We do not want to spend our resources on maintaining... Then we migrating with pain from the google service.
By having ability to, at least, skim at bugs and see if there are some low-hanging fruits to tackle, maybe more work could be accomplished?
Having issue tracker closed for the public emits, imho, not very friendly signal to potential contributors. Yes but we cannot do much
Stef
Hi! Hola! I would like to help with some of this, so I sorted a bit the ideas in the previous emails to see if we can extract some concrete actions to apply. So I'll make a step back and put some titles to the topics of discussion: !Human/Social/Politics stuff 1) Policies - Deciding about what goes inside - And what does not - e.g., what is the official IDE? What is a valid issue? - And what is necessary or useful for the community Well, on the one hand Esteban and Steph answered to this already I think. At least about how this works in reality. I have however two remarks on this: - First, I think that all accepted issues should be aligned with Pharo's vision. And this means first that this vision must be well documented and updated. Second, it means that people should know and read that vision document (and not get mad if ). But also, this "alignment" is kind of subjective: there is somebody that decides if this happens or not. And this happens to be the board who does it... - Second, I do not really care what the heck is the process to decide this. But I believe that documenting it is nothing but a good move. (And this is related to the PEPs Hernan named and I talk about below...) 2) Discussion around the same topics for months - can we have some examples about these? From the top of my head I can think about * <example> * Logging * ? Well, I see also sometimes that we have long-running discussions that go nowhere... But: - First, I take them as people is learning. In Pharo-dev people discuss sometimes about things they are not sure of or maybe they want to share and change. And maybe they are discussing to explore new ideas. So, please do not ban these discussions, I thing that we have to encourage them. Also, the traffic in Pharo-dev is so high that if something is not interesting to us, we have to either learn to filter that out, or follow other lower-traffic options such as pharo-users or pharo's new newsletter. - Second, please, if you feel that you have something to propose, drop it in the mailing list! But as you make it public, do not expect that everybody will agree :). Also, as you have noticed, many people in this list have really strong opinions, so we have to understand and continue pushing. 3) PEPs (Pharo Enhancement Proposals?) Well, this is an interesting idea. I think it is important to document well - the integration process - the decision process - the release process - the proposal process (which BTW I really, since to propose some enhancement you need to really describe and design it and not just say "mine is cooler!") - Coding idioms and styles (maybe we can autogenerate this from lint rules???? Invoking Yuriy here!!) A question I would pose is - where should this be? a wiki somewhere? some part inside the pharo site? !Technical stuff, about Big images, modularization, removing tests Hernan, I am really interested in your use case where having the image tests is really bothering. We are working on modularizing it, yes, but we also believe the default environment should contain tests to guarantee some quality => otherwise, breaking the system would be far much easier! But if you are interested in modular images just drop me (and Christophe, and Pavel) an email and we can see how we can collaborate. And also, Hernan, what would you collaborate with? Because in your email I had the impression that you "expect" something from people: to accept your issues, to fix your issues, to communicate with you, but it's fuzzy what you're doing also to make that happen. This is maybe just an email miscommunication, just take this as a proposal to really move your ideas forward (with your help, of course). Guille -------- Original Message --------
Hello,
Looking at bugs is really difficult. There are not enough people
looking and fixing bugs.
just a short note from a Pharo noob...it is, imho, very strange that one
cannot even take a look at bugs *without* creating account at tracker.
We know. Now the company offered us a professional service (cost around 25$ per month per user)
for free. And also to maintain it. We do not want to spend our resources on maintaining...
Then we migrating with pain from the google service.
By having ability to, at least, skim at bugs and see if there are some
low-hanging fruits to tackle, maybe more work could be accomplished?
Having issue tracker closed for the public emits, imho, not very
friendly signal to potential contributors.
Yes but we cannot do much
Stef
On Thu, 25 Aug 2016 09:05:45 +0200 stepharo <stepharo@free.fr> wrote:
Yes but we cannot do much
OK. I got it...do you believe it makes sense for a noob to create acount in case there are some low-hanging fruits to pick? Sincerely, Gour --
From wherever the mind wanders due to its flickering and unsteady nature, one must certainly withdraw it and bring it back under the control of the self.
Hi,
On Aug 25, 2016, at 5:31 PM, Gour <gour@atmarama.com> wrote:
On Thu, 25 Aug 2016 09:05:45 +0200 stepharo <stepharo@free.fr> wrote:
Yes but we cannot do much
OK. I got it...do you believe it makes sense for a noob to create acount in case there are some low-hanging fruits to pick?
It definitely does! We are all noobs in many parts in our system. But, if you take your time and are willing to dig, the system is kind enough to reveal itself to you :). That is the beauty of this world. Please join us. Just dive :). Cheers, Doru
Sincerely, Gour
-- From wherever the mind wanders due to its flickering and unsteady nature, one must certainly withdraw it and bring it back under the control of the self.
-- www.tudorgirba.com www.feenk.com "If you interrupt the barber while he is cutting your hair, you will end up with a messy haircut."
On Thu, 25 Aug 2016 23:06:51 +0200 Tudor Girba <tudor@tudorgirba.com> wrote:
It definitely does! We are all noobs in many parts in our system.
Heh, I'm for the whole system. :-)
But, if you take your time and are willing to dig, the system is kind enough to reveal itself to you :). That is the beauty of this world. Please join us. Just dive :).
OK, thank you for encouraging me...I'm going to create it. ;) Sincerely, Gour -- A person is said to be established in self-realization and is called a yogÄ« [or mystic] when he is fully satisfied by virtue of acquired knowledge and realization. Such a person is situated in transcendence and is self-controlled. He sees everything â whether it be pebbles, stones or gold â as the same.
On Thu, Aug 25, 2016 at 11:31 PM, Gour <gour@atmarama.com> wrote:
On Thu, 25 Aug 2016 09:05:45 +0200 stepharo <stepharo@free.fr> wrote:
Yes but we cannot do much
OK. I got it...do you believe it makes sense for a noob to create account in case there are some low-hanging fruits to pick?
Definitely. And not necessarily that you *solve* an issues, but that I found a benefit from "goal directed learning". When I started using Pharo I learned a lot from: * trying to reproduce issues - which also benefits core developers if you can gather more complete symptom info * testing other people's solutions - putting halts in the changed code and simultaneously stepping through the original and solution code. Actually I was surprised at far into the depths of the system this led me sometimes and how accessible they were. Look for issue marked "Fixed - review needed" cheers -ben
On Fri, 26 Aug 2016 14:27:24 +0800 Ben Coman <btc@openinworld.com> wrote:
Definitely. And not necessarily that you *solve* an issues, but that I found a benefit from "goal directed learning".
That's a good point!
When I started using Pharo I learned a lot from: * trying to reproduce issues - which also benefits core developers if you can gather more complete symptom info * testing other people's solutions - putting halts in the changed code and simultaneously stepping through the original and solution code. Actually I was surprised at far into the depths of the system this led me sometimes and how accessible they were. Look for issue marked "Fixed - review needed"
Thank you. It seems that I'm ahead of new (learning) experience provided by "inspired by Smalltalk" environment. :-) Sincerely, Gour -- But for one who takes pleasure in the self, whose human life is one of self-realization, and who is satisfied in the self only, fully satiated â for him there is no duty.
So true. :) >> On Thu, 25 Aug 2016 09:05:45 +0200 >> stepharo <stepharo@free.fr> wrote: >> >>> Yes but we cannot do much >> OK. I got it...do you believe it makes sense for a noob to create account >> in case there are some low-hanging fruits to pick? > Definitely. And not necessarily that you *solve* an issues, but that > I found a benefit from "goal directed learning". > When I started using Pharo I learned a lot from: > * trying to reproduce issues - which also benefits core developers if > you can gather more complete symptom info > * testing other people's solutions - putting halts in the changed code > and simultaneously stepping through the original and solution code. > Actually I was surprised at far into the depths of the system this led > me sometimes and how accessible they were. Look for issue marked > "Fixed - review needed" > > cheers -ben > >
Definitively :) I started to do that when I discovered Smalltalk. I wanted to learn and I read the submissions of people and try to understand and comment. And I learned a lot about the system, about myself, about quality. Stef Le 25/8/16 à 17:31, Gour a écrit :
On Thu, 25 Aug 2016 09:05:45 +0200 stepharo <stepharo@free.fr> wrote:
Yes but we cannot do much OK. I got it...do you believe it makes sense for a noob to create acount in case there are some low-hanging fruits to pick?
Sincerely, Gour
Now I will try to be more positive. 2016-08-24 4:38 GMT-03:00 stepharo <stepharo@free.fr>:
Hi Hernan
First thanks for your email because we may disagree but we often agree. :) so this is an email for me.
Hi Stef,
Good communication implies being clear when writing about sensitive topics, especially when communicating through virtual channels. I am not in Europe, so I cannot discuss these things with you face to face.
This is what we want to change with montly videos meeting.
Good initiative, thanks!
Therefore is not clear to me (and others) what are your policies in many subjects. Lately I also delayed the release of packages because my lack of motivation around this community, specially when discussions exists around three or fourth topics for months.
Like what? Let us know because we do not
I don't get why we don't have more discussions about end-developer tools : XML, i18n, GIS, simulation & expert systems, big data, reporting...
Another "motivational" case for me. I stopped to report bugs in fogbuz because I felt there was too much "Won't fix" for me (specifically by a person but I won't go there...) even in cases where it was ilogical. Then I felt tired of reading "It's like that. Invalid".
This is a pity. I know the feeling because some of mine are close too. You are not the only victim of the "Issue closing syndrom" ;). And I would like the syndrome to be more human friendly. Thanks for raising this point.
Now two points - You should always send a mail to the mailing-list and that we discuss your points.
- Now what will happen if we all open bugs and none of us works on the open bugs. So what is the solution for you. I mean it concretely. How to deal with dying
Looking at bugs is really difficult. There are not enough people looking and fixing bugs.
I think you could implement some reward system for devs with more bug fixes: Interviews, consortium membership, maybe voting on some issues...?
About features.
What's the policy about voting for default features in next Pharo images? Let's suppose I am a VM/core Pharo maintainer and I want to include MySuperPackage into a Pharo release, which nobody needs (and I don't care), but it is useful to me.... there will ever be voting there? (note it doesn't makes sense if you are a group of 50 always supporting your work)
It does not really work because engineers are paid for certain task.
Images are becoming huge (at least for my workflows). There will be (more) packages included by default (for promotion?) ?
Thanks to raise this point because I mentioned it also to the board. So I like when I'm not alone. Now we should not see look only at the size. Doing nothing is size zero :) The point is what are the functionalities delivered.
Three points: - what are the key things we want? keybinding, settings, cool inspector cool....
- how many duplicated functionality can we remove: for example I want to merge MCDefinitions with Ring with RBDefinition we removed pseudo* but this is a lot of work
The goal is to throw many system when bloc and brick are ready
- what is the list of things that you would remove?
To me there a couple of things which must have two versions (considering we lack a sub-image where to do image repairing). - Inspector: -- One cool (this seems will ever be GT) -- One bullet-proof very very limited (to repair GT when broken, or minimal image) - System Browser -- One cool (like Nautilus) -- One standard (to not have an unusable image if the cool one gets broken) - with the bootstrap and all the packages of the image managed with
Cargo plus the git management we believe that we will be able to manage a set of images with minimal images. - this is several years that we are working on this goal. Believe me this is the vision document not for the sake of it.
How do you plan to manage if some people want the Tests be removed from the official Image? (Personally I never run them)
- then you use a jenkins job to produce your image where you unload the tests.
I see, never tried Jenkins for real (but maybe rethorical question: is that true users need all the Tests in the image? To test a package like Graphics-Test?)
Another example, what happens if another research group came with a better alternative to Calypso, Brick, Telescope, Bloc. Would you integrate first your tool to mark territory?
No this is not a question of territory. Doru and GT does not do that in that spirit. RMOD too. We do something when we think that this is better. For example Epicea is three years of work of Martin, Fuel was so nice that we could not lose it. You see Ghost got changed by denis, Seamless got rewritten from scratch.
Who decides? For example (IIRC) TxText and Twisty.
Igor looked at Twisty seriously and I do not think that it could handle large cobol files.
(you see funnily denis is doing the same with Seamless - He rewrote it from scratch while nick worked on it for several years).
Igor wanted to have a stream-based API that could work on modern command-oriented videos card framework. My team (on our own money if you understand what it means) paid Igor to build TxText (and I can tell you that I would have prefered him to do something else).
So the money decides :)
The same applies if anyone came with another rewrite of classic Smalltalk Workspace, Debugger and Inspector tools, what would you do with GT? GT stays because it came before and others would be optional?
No this is not like that. If you are better or answer better needs.
There will be anything like PEPs?
I would love but will people have the energy to implement them? I would definitively encourage you as a community to raise points on what you need.
I would write a "PEP" if someone from the board seriously considers to review it and integrate it (or not) with a clear communication.
If someone can answer me I think that would be an example of good communication.
Hernan I always answered your emails. I always consider your work (and you know it for other reasons and by my facts) after I'm not always in agreement as I'm not always in agreement with other board members and this is how live happens. What is clear is that the most important aspects is to continue to communicate. This is why the board is launching this initiative and I would love to see it taken by people even for their projects.
Thank you Stef for raising this space to consider both good and uncomfortable things. I believe one day we -pharo users- have to take the world and show what's happening here. Time passes and we have an unique chance of changing the world through Pharo, our beloved self-convinced textual-relational world. Pharo technology is designed to push limits, so let's do things differently once. One thing that could change the world: Let's browse Java/Python code directly from Nautilus. Hernán 2016-08-24 1:51 GMT-03:00 stepharo <stepharo@free.fr>:
Hi guys
the board got a good discussion at ESUG about how to improve and a lot of the discussion turned around improving communication. We got some ideas that we will propose soon but I would like to get *your* ideas.
If you have idea about improving communication around pharo please tell us.
Stef
Let us know because we do not
I don't get why we don't have more discussions about end-developer tools : XML, i18n, GIS, simulation & expert systems, big data, reporting...
Yes the idea is that we would like to try a process for Pharo and that such process can be used by other projects such as Moose.
I think you could implement some reward system for devs with more bug fixes: Interviews, consortium membership, maybe voting on some issues...?
I wanted to have something like the bug fixers of the month but my plate is fuller than people can imagine. Now we pay really attention that work of many contributors/fixers get really reviewed fast. And this is a way to thank them for their energy and contributions.
About features
To me there a couple of things which must have two versions (considering we lack a sub-image where to do image repairing).
- Inspector: -- One cool (this seems will ever be GT) -- One bullet-proof very very limited (to repair GT when broken, or minimal image)
Definitively. Why don't you help me remove EyeInspector and build such low level inspector.
- System Browser -- One cool (like Nautilus) -- One standard (to not have an unusable image if the cool one gets broken) Same here. I started to write one that is really really minimal two panes :) but I want real widgets.
I see, never tried Jenkins for real (but maybe rethorical question: is that true users need all the Tests in the image? To test a package like Graphics-Test?)
- No users do not need that but we do not want to have to load them when we need them. We can offer a jenkins account to you and you can build your image without any problem. They will even show up in PharoLauncher.
Another example, what happens if another research group came with a better alternative to Calypso, Brick, Telescope, Bloc. Would you integrate first your tool to mark territory?
No this is not a question of territory. Doru and GT does not do that in that spirit. RMOD too. We do something when we think that this is better. For example Epicea is three years of work of Martin, Fuel was so nice that we could not lose it. You see Ghost got changed by denis, Seamless got rewritten from scratch.
Who decides? For example (IIRC) TxText and Twisty.
Igor looked at Twisty seriously and I do not think that it could handle large cobol files.
(you see funnily denis is doing the same with Seamless - He rewrote it from scratch while nick worked on it for several years).
Igor wanted to have a stream-based API that could work on modern command-oriented videos card framework. My team (on our own money if you understand what it means) paid Igor to build TxText (and I can tell you that I would have prefered him to do something else).
So the money decides :) Not only, energy too. If you propose a basic inspector we will integrate it. When I said to inria give an engineer for doing X and X is key for the future of Pharo (put Athens, TxText, VM build, Package, Bootstrap....) I cannot ask two times so it has to be done.
The same applies if anyone came with another rewrite of classic Smalltalk Workspace, Debugger and Inspector tools, what would you do with GT? GT stays because it came before and others would be optional?
No this is not like that. If you are better or answer better needs.
There will be anything like PEPs?
I would love but will people have the energy to implement them? I would definitively encourage you as a community to raise points on what you need.
I would write a "PEP" if someone from the board seriously considers to review it and integrate it (or not) with a clear communication.
What do you mean integrate it. A PEP is first a description and then after we decide. We cannot give a free check but please write a PEP One page max.
Hernan I always answered your emails. I always consider your work (and you know it for other reasons and by my facts) after I'm not always in agreement as I'm not always in agreement with other board members and this is how live happens.
What is clear is that the most important aspects is to continue to communicate. This is why the board is launching this initiative and I would love to see it taken by people even for their projects.
Thank you Stef for raising this space to consider both good and uncomfortable things.
Thank. You see I think that the board was not communicating within itself too and we should address this. We cannot be all running like hamsters :)
I believe one day we -pharo users- have to take the world and show what's happening here. Time passes and we have an unique chance of changing the world through Pharo, our beloved self-convinced textual-relational world. Pharo technology is designed to push limits, so let's do things differently once. Yes One thing that could change the world: Let's browse Java/Python code directly from Nautilus. You can do it in Moose :)
Hernán
2016-08-24 1:51 GMT-03:00 stepharo <stepharo@free.fr <mailto:stepharo@free.fr>>:
Hi guys
the board got a good discussion at ESUG about how to improve and a lot of the discussion turned around improving communication. We got some ideas that we will propose soon but I would like to get *your* ideas.
If you have idea about improving communication around pharo please tell us.
Stef
2016-08-24 9:38 GMT+02:00 stepharo <stepharo@free.fr>:
Igor looked at Twisty seriously and I do not think that it could handle large cobol files.
(you see funnily denis is doing the same with Seamless - He rewrote it from scratch while nick worked on it for several years).
Just to clarify: Twisty was not rewrite of TxText. When Igor returned to project I already moved to my design ideas which was opposite to Igor. And I just decided to finish what I started with new project name. About long files - TxText optimization needs to be implemented in Twisty. That's all. Current design could be evolved for it. I does not know which project is better. In Twisty I implemented my practical needs: various kinds of editors. To approve which design is better someone needs to implement same in TxText and compare it with Twisty. Probably simple example of masked text could be enough. And I must mention Seamless to clarify that Nick work is not lost. He implemented important ideas on asynchronous data transfer which helps me a lot. I extracted them to separate project Basys with better abstraction which is independent from Seamless goals. It improved testability and leaded to rest of other changes.
In context of discussion how to propose Mocketry and StateSpecs to be part of Pharo? We often said that Pharo provides the best approach to TDD but we have no mock library inside. And nobody use mocks for Pharo tests because of that 2016-08-24 6:51 GMT+02:00 stepharo <stepharo@free.fr>:
Hi guys
the board got a good discussion at ESUG about how to improve and a lot of the discussion turned around improving communication. We got some ideas that we will propose soon but I would like to get *your* ideas.
If you have idea about improving communication around pharo please tell us.
Stef
participants (10)
-
Ben Coman -
Denis Kudriashov -
Esteban Lorenzano -
Gour -
Guille Polito -
Hernán Morales Durand -
Pavel Krivanek -
stepharo -
Tudor Girba -
Yuriy Tymchuk