On Thu, Aug 17, 2017 at 10:44 AM, Torsten Bergmann <astares@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 pharo

��- subdirectories (to better manage sub projects)

��- less of a hard issue:

�� - there is a nice plugin architecture, I'd like to see more plugins flourish?

�� - 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 baseline

�� - 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 repository

��

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**,

Guille

��

Regards
T.

��	Guille Polito Research Engineer French National Center for Scientific Research - http://www.cnrs.fr Web: http://guillep.github.io Phone: +33 06 52 70 66 13