Hi torsten 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.
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-fo...
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-... 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.