Smalltalk › Pharo › Pharo Smalltalk Developers

Initial Feedback on Pharo 7 contribution process

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

9 messages Options

Torsten Bergmann

Initial Feedback on Pharo 7 contribution process

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.

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)

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?

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.

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.

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.
I have no idea who is working on what already regarding making the process more easier.

Thanks for any comments or own feedback you can share.

Regards
T.

Guillermo Polito

Re: Initial Feedback on Pharo 7 contribution process

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

Pavel Krivanek-3

Re: Initial Feedback on Pharo 7 contribution process

In reply to this post by Torsten Bergmann

2017-08-17 10:44 GMT+02:00 Torsten Bergmann <[hidden email]>:

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.

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)

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?

You can update your image in Iceberg by switching to the updated #development branch and then to reload all packages. In most cases it will probably work fine but it does not know the right packages loading order, does not know changes in the packages structure etc.

And some updates cannot be done at all (e.g. https://github.com/pharo-project/pharo/pull/205). So you can expect troubles.

With Cargo we can get smoother updating process but trying to maintain it now would be IMHO waste of resources.

-- Pavel

EstebanLM

Re: Initial Feedback on Pharo 7 contribution process

In reply to this post by Guillermo Polito

Hi,

On 17 Aug 2017, at 11:28, Guillermo Polito <[hidden email]> wrote:

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

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

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

alistairgrant

Re: Initial Feedback on Pharo 7 contribution process

In reply to this post by Pavel Krivanek-3

On Thu, Aug 17, 2017 at 11:54:57AM +0200, Pavel Krivanek wrote:

>
>
> 2017-08-17 10:44 GMT+02:00 Torsten Bergmann <[hidden email]>:
>
> 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.
>
> 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)
>
> 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?
>
>
> You can update your image in Iceberg by switching to the updated #development
> branch and then to reload all packages. In most cases it will probably work
> fine but it does not know the right packages loading order, does not know
> changes in the packages structure etc.
> And some updates cannot be done at all (e.g. https://github.com/pharo-project/
> pharo/pull/205). So you can expect troubles.
> With Cargo we can get smoother updating process but trying to maintain it now
> would be IMHO waste of resources.
>
> -- Pavel

If the order is important...

Iceberg models the commits, so it should be possible to start at the
head and trace back to the commit used to build the image. The
resulting list of commits could then be loaded in the correct order.
(I don't know if this would help in the case of PR #205)

Just to add a positive note to the conversation: I'm not very
knowledgable about git, but it seems to be the best source control tool
by far (based on my limited experience), and I've seen steady
improvement in Iceberg since Esteban indicated that it would be the
basis of source control for Pharo. What I've seen so far makes me think
that we are going down a good path, even if it is taking longer we would
like and is causing some pain along the way.

Cheers,
Alistair

EstebanLM

Re: Initial Feedback on Pharo 7 contribution process

> On 17 Aug 2017, at 17:37, Alistair Grant <[hidden email]> wrote:
>
> On Thu, Aug 17, 2017 at 11:54:57AM +0200, Pavel Krivanek wrote:
>>
>>
>> 2017-08-17 10:44 GMT+02:00 Torsten Bergmann <[hidden email]>:
>>
>> 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.
>>
>> 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)
>>
>> 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?
>>
>>
>> You can update your image in Iceberg by switching to the updated #development
>> branch and then to reload all packages. In most cases it will probably work
>> fine but it does not know the right packages loading order, does not know
>> changes in the packages structure etc.
>> And some updates cannot be done at all (e.g. https://github.com/pharo-project/
>> pharo/pull/205). So you can expect troubles.
>> With Cargo we can get smoother updating process but trying to maintain it now
>> would be IMHO waste of resources.
>>
>> -- Pavel
>
> If the order is important...
>
> Iceberg models the commits, so it should be possible to start at the
> head and trace back to the commit used to build the image. The
> resulting list of commits could then be loaded in the correct order.
> (I don't know if this would help in the case of PR #205)

heh… no. Order of commits has nothing to do with order of loading packages.
also:
- class initialization has to happen
- migrate changed instances needs to be prepared pre and post change.

while most of the time update packages “just works”, the case of slots for example will not work no matter the loading order, because we need to ensure some pre actions and post actions to happen.

I’m playing with the idea to extend iceberg with the capability of processing some information at package and class level (in package with manifests and in classes with class methods). Like adding #iceLoad, #iceUpdate methods (or #iceUpdateBefore and #iceUpdateAfter) so we can handle this… but this will not happen immediately (in case we decide it worths to have it) :)

>
> Just to add a positive note to the conversation: I'm not very
> knowledgable about git, but it seems to be the best source control tool
> by far (based on my limited experience), and I've seen steady
> improvement in Iceberg since Esteban indicated that it would be the
> basis of source control for Pharo. What I've seen so far makes me think
> that we are going down a good path, even if it is taking longer we would
> like and is causing some pain along the way.

nice!
and yes, this kind of changes take a lot of time… we are always too optimists and when we said “at least 3 months” we should have said double that time… but I’m happy with things as they are starting to fit. And in a couple of months we will be a full speed :)

cheers!
Esteban

>
>
> Cheers,
> Alistair
>

Torsten Bergmann

Re: Initial Feedback on Pharo 7 contribution process

In reply to this post by Guillermo Polito

Hi,

first: thanks you Guille for answering my questions and providing more documentation
on your wiki.

Guille also cared yesterday on addressing the build number problem:
https://github.com/pharo-project/pharo/pull/212

Big thanks!

Meanwhile I wrote a small "contribution" tool which I can have as an in-image utility
that will help me (and maybe others too) with some necessary steps.

It's a customized help topic together with some code using an external
"git" command (because using the command line is tedious)

Maybe some of you may want to try it. To load you need:

Gofer it
smalltalkhubUser: 'TorstenBergmann' project: 'Contribution';
package: 'Contribution-Tool';
load.

and then

#CTPHelpTopic asClass open

It should explain some of the steps necessary to contribute similar to Guilles
wiki page but right from the image. It works best when you have the "WebBrowser"
package loaded from catalog before as then the links really open a webbrowser.

Attached is a screenshot.

There is also an additional tool ("CPTCloneTool run") inside of this package to

- clone the #development branch from your custom fork of the pharo project
into a subdirectory "contribute/pharo-gitusername" of your image directory

- set ttps://github.com/pharo-project/pharo.git automatically as "upstream" remote

- it also adds this local directory to the Iceberg "pharo" repo and enables
the setting to show the system repositories

- and finally opens Iceberg browser

For simplicity it for now uses system: calls with the git command.

So if you use this tool in a clean and fresh image it should bring you
to the point where you can start coding your change and then create a
branch for the bug number using Iceberg.

Use it at your own risk:
=======================
For me it works on Ubuntu, I was able to contribute with this. Have not tried on Mac.
Unfortunately this still crashes the VM on Windows due to a new Iceberg
issue (https://github.com/pharo-vcs/iceberg/issues/438) that need to be fixed.

The repo on STHub is open - so if you want to extend it feel free to do so.

Thx
T.

image.png (167K) Download Attachment

image2.png (141K) Download Attachment

Guillermo Polito

Re: Initial Feedback on Pharo 7 contribution process

On Fri, Aug 18, 2017 at 3:40 PM, Torsten Bergmann <[hidden email]> wrote:

Hi,

first: thanks you Guille for answering my questions and providing more documentation
on your wiki.

Guille also cared yesterday on addressing the build number problem:
https://github.com/pharo-project/pharo/pull/212

Big thanks!

Meanwhile I wrote a small "contribution" tool which I can have as an in-image utility
that will help me (and maybe others too) with some necessary steps.

It's a customized help topic together with some code using an external
"git" command (because using the command line is tedious)

Maybe some of you may want to try it. To load you need:

Gofer it
smalltalkhubUser: 'TorstenBergmann' project: 'Contribution';
package: 'Contribution-Tool';
load.

and then

#CTPHelpTopic asClass open

It should explain some of the steps necessary to contribute similar to Guilles
wiki page but right from the image. It works best when you have the "WebBrowser"
package loaded from catalog before as then the links really open a webbrowser.

Attached is a screenshot.

There is also an additional tool ("CPTCloneTool run") inside of this package to

- clone the #development branch from your custom fork of the pharo project
into a subdirectory "contribute/pharo-gitusername" of your image directory

- set ttps://github.com/pharo-project/pharo.git automatically as "upstream" remote

- it also adds this local directory to the Iceberg "pharo" repo and enables
the setting to show the system repositories

- and finally opens Iceberg browser

Pavel was a week ago or so publishing a script over here that did the same. And I thought it would be good to make it an iceberg plugin. Maybe this too :)

For simplicity it for now uses system: calls with the git command.

So if you use this tool in a clean and fresh image it should bring you
to the point where you can start coding your change and then create a
branch for the bug number using Iceberg.

Use it at your own risk:
=======================
For me it works on Ubuntu, I was able to contribute with this. Have not tried on Mac.
Unfortunately this still crashes the VM on Windows due to a new Iceberg
issue (https://github.com/pharo-vcs/iceberg/issues/438) that need to be fixed.

The repo on STHub is open - so if you want to extend it feel free to do so.

Thx
T.

Tx!

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

Stephane Ducasse-3

Re: Initial Feedback on Pharo 7 contribution process

In reply to this post by Torsten Bergmann

Hi torsten

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