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 <steph...@free.fr <mailto: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






Reply via email to