Hi torsten

On Thu, Aug 17, 2017 at 10:44 AM, Torsten Bergmann <[email protected]> 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.

Excellent. Because with my first contribution I broke filetree itself.
And while trying to integrate fixes Iceberg felt apart on me. I kept a
version for esteban postmortem analysis :)


> 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.

We want to get close to the confort we got before. So controlling
fogbugs from Pharo..
I do not want to

 - write email by hand
 - close fogbugs issue by hand
 - relaunch the PR tests by hand (because right now we are saturating
the inria slaves when we rescan the status of the PR).



> 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)

Well you see.
Run the tests, review the code, integrate and redo.
Now I cannot spend my day doing this.




> 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?

Immediately no because the problem is that image that a fix is split
in two packages.
and package Z should be loaded before package A. Then loading blindly
the packages
will not work. So a baseline expressing this dependency order is
needed and right now we
do not automatically have it.



>     The World menu entry "System" -> "System update" has been removed?

Yes

>     Is this temporary of will it return once we know how it could be done 
> again?

I would love.


>>  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.

Normally we always say that packages inside Pharo should be fixed in
Pharo and PR issued to their home
so that Pharo does not wait for a PR to come for an external package.



>  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.
>
>      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.

Yes guille did a fix for that. Because this is super annoying for a
guy like me that downloads one image after each integration.




>
> 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.

Marcus and esteban are coming back from vacation and we will get up to speed.
I should sit with marcus to show you how to survive to git.
Because git is More complex (esteban told me that this is a real
distributed version control system while MC was not .... nevertheless
it is more complex. For example: do I clone for the origin or the fork
.... and it influences on the process).


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

Guille and Pavel were and Esteban will work on it.


> Thanks for any comments or own feedback you can share.
>
> Regards
> T.
>
>
>

Reply via email to