Hi, > On 17 Aug 2017, at 11:28, Guillermo Polito <guillermopol...@gmail.com> wrote: > > > > On Thu, Aug 17, 2017 at 10:44 AM, Torsten Bergmann <asta...@gmx.de > <mailto:asta...@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…
most of us :) I will be back next week :P > > > 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/ > > <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 > <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”. yes, update is broken since *at least* Pharo 1.4. I do not think is in our priorities to make it back since we are now bootstrapping (and is very different build process). then… one of the plugins I would like to see is a “reload all packages following baseline” which will make it work on most cases. Still, it will not work 100% of the time (as Pavel points, there are issues that would simply not work updating… but this cases are not common). Esteban > > > 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 > <https://github.com/pharo-project/pharo> > or should it be fixed in the original repo > https://github.com/tesonep/hermes <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 > > <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 <http://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 <http://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 > <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 > <http://www.cnrs.fr/> > > > Web: http://guillep.github.io <http://guillep.github.io/> > Phone: +33 06 52 70 66 13
