[Pharo-dev] Initial Feedback on Pharo 7 contribution process

Guillermo Polito guillermopolito at gmail.com
Thu Aug 17 05:28:51 EDT 2017

On Thu, Aug 17, 2017 at 10:44 AM, Torsten Bergmann <astares at gmx.de> wrote:

> Hi,
> even when contributing to Pharo 7.0 is still very very cumbersome I was
> able
> to sort out most of the problems and contribute already a few smaller
> things.
> Unfortunately there is not much communication on what is currently in the
> pipe
> or planned on easing the process - which can easily lead to the impression
> that we do not really move or slow us down.

Vacations period...

> I know step by step it goes and at least we have again the build process
> rolling
> https://pharoweekly.wordpress.com/2017/08/16/pharo-70-is-
> starting-to-roll-for-real/
> Nonetheless one of my PRs was already integrated and the integration of my
> WebBrowser
> package is still in the pipe (https://github.com/pharo-
> project/pharo/pull/193)

Yes, I need to document better all the process with the baselines, I know :)

> The descriptions from Guille helped me - but there are still things I need
> answers to:
>  1. Will or is it still possible to automatically update" an image in
> Pharo 7
>     or in the future?
>     The World menu entry "System" -> "System update" has been removed?
>     Is this temporary of will it return once we know how it could be done
> again?
AFAIU, this never worked "safely".

>  2. In latest Pharo 7.0 image there is a glitch that a method category
>     has a typo in class "HEBinaryReaderWriter" and is "writting" instead of
>     "writing".
>     Lets assume I want to fix such a simple problem. But Hermes was an
> external package managed on GitHub.
>     And it is now part of the image and therefore also in the "pharo" repo
> on GitHub. So how is it
>     maintainted/managed with the new process?
>     So do I fix this as a regular PR for Pharo 7 https://github.com/pharo-
> project/pharo
>     or should it be fixed in the original repo https://github.com/tesonep/
> hermes
>     and Hermes is synched from time to time into or from Pharo.

My answer to this is: until we support multiple code directories per
repository in iceberg (I think that's scheduled for next release), we kind
of have a fork (as we had before with the image and people committing to
the inbox).

The good way to do the fix on hermes should be, although a bit cumbersome,
the following:
 - fix it in hermes repo
 - then sync hermes with your pharo fork
 - pull request for pharo

I know these are a lots of steps...

>  3. What still hit me most is that it is hard to identify the images and
> find out
>     how "new" they are.
>     Example: In Guilles example https://github.com/guillep/
> PharoIntegrationProcess/wiki/Contribute-a-fix-to-Pharo
>              it is written that one should use
>                   wget -O - get.pharo.org/70+vm | bash
>      This gives me an image file called "Pharo.image" and after a few days
> I do not know how
>      old it is or what it was built from.
>      When I start the image and look into the about box it gives me
>          Pharo 7.0
>          Latest update: #0
>      telling me nothing and when I run
>          SystemVersion current
>      it says "Pharo7.0SNAPSHOT of 16 August 2017 update 0" which is also
> very useless.

True, but if you inspect `SystemVersion` you'll see that it contains the
hash. Thus there are two issues:
  - SystemVersion printing should include more info
  - we should put build information into the image (so far it is only in
the zip archives in files.pharo.org)

The first issue should be easy to fix and maybe a good target for a guy
trying to make his first PR.
The second issue requires understanding a bit more the bootstrap process (I
need to write something more detailed about that, I know, but I'm on
vacations right now and from saturday I've no internet).

I can try to solve them today, I'll not be long I think.

>      Both do not tell me anything about the build number!!! I can only
> guess the git commit from the name
>      of the sources file:
>        Pharo7.0-32bit-c28bff9.sources
>      When I check https://github.com/pharo-project/pharo/commits/
> development with "c28bff9" then at least
>      I have an idea how old it is.
> Especially the last topic is a pain point and the most pressuring to be
> discussed - without a clear image build number
> in the version/about box nobody is able to reproduce in which image one
> run into trouble or he is basing his work on.
> I know during transition time we need more patience and things will get
> more stable and we make progress over
> time. But I whised we would have more communication on the overall topic
> (current work, plans, ...) on this list here.

Well, in part what I wanted as a first milestone is to reach the point
where the process is smooth enough to let people contribute. And well... at
that point people could contribute :)

This is my TODO list, if somebody wants to help:

On the CI and integration front:
 - automate integration mails
 - automate github/jenkins/fogbugz communication

On the Iceberg front:
 - my main wish is to have a smooth experience while submitting a fix to
 - subdirectories (to better manage sub projects)
 - less of a hard issue:
   - there is a nice plugin architecture, I'd like to see more plugins
   - we need people involving themselves on it. I think Esteban alone
cannot with all the issues there.

On the general build process:
 - we need to enhance how packages can be loaded in a `minimal image`
    - Right now, we don't have baselines for each pharo subproject. For
example, the other day I wanted to install spacetally and I did not have a
    - Even if we had baselines, there are ugly dependencies: for example,
spacetally depends on morphic.
    - I started thinking we need the idea of a MultiProject baseline where
a baseline describes a top project with subprojects (baselines) in the same

> I have no idea who is working on what already regarding making the process
> more easier.

Esteban is Iceberg's fairy-knight.
I was working a lot lately with Christophe to have the ci working and make
sure we can integrate PRs and we are not stuck. I made tests green to have
a better indication of the process. I started documenting all this.
Pavel is helping with the overall process too.

>From that list, Esteban is the only full time guy. I'm now doing stuff over
here and there but I'm on vacations and my relationship may depend on not
working so much :P

Now, sending mails like this is good because they raise good issues.
Please, people, raise more like this. For the brave, you can keep trying
publishing some Pull request, sharing your experience, documenting stuff...

> Thanks for any comments or own feedback you can share.
> Thank **you**,


> Regards
> T.


Guille Polito

Research Engineer

French National Center for Scientific Research - *http://www.cnrs.fr*

*Web:* *http://guillep.github.io* <http://guillep.github.io>

*Phone: *+33 06 52 70 66 13
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20170817/7ed0f741/attachment.html>

More information about the Pharo-dev mailing list