2016-08-26 6:19 GMT-03:00 stepharo <steph...@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 <steph...@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 <steph...@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
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>
>
