[IMPORTANT] PHARO CONTRIBUTION PROCESS UPDATED! PLEASE READ!

On 17 Jan 2018, at 07:15, Max Leske <[hidden email]> wrote:

Hi Martin,

What I do is

1. update local pharo repository on branch 'development'

2. add repository to Iceberg

3. create branch for phogbugz issue

4. make changes (e.g. load stuff from your project)

5. Note that you will have to handle addition and removal of packages separately:

5.1 addition: click 'add package' 

5.2 removal: click 'remove package'. You will have to commit the removal from the command line, as Iceberg does not currently recognize removals as staged changes.

I usually just make a second commit with the removal before I push everything.

6. Now the changes may not show up. But you can right click on the repository in Iceberg and select 'Synchronize full repository'

7. Select the changes you want to commit

The rest you know, I guess ;)

Cheers,

Max

 

On 16 January 2018 at 20:16:22, Martin Dias ([hidden email]) wrote:

Hi, I followed the guide and everything is good. What I don't know is how to upgrade an external project already integrated in Pharo 7 (Epicea). I have new version 8.2.6.

Cheers, Martín.

On Tue, Jan 9, 2018 at 11:01 AM, Sean P. DeNigris <[hidden email]> wrote:

EstebanLM wrote
>> Mmm. I think this is because your local clone is outdated.
>> It should be fixed with a fetch… from pharo-project, I mean :)

That worked. Thanks. Next problem: Iceberg is showing a massive number of
changes when syncing with pharo fork on the dev branch at the same commit as
the image. There doesn't seem to be a way to collapse the whole tree making
it impossible to find the real changes. I assume it's that known bug where
the first commit will sync the list, but not very user friendly!

-----
Cheers,
Sean
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

On 17 Jan 2018, at 11:45, Denis Kudriashov <[hidden email]> wrote:

Hi

2018-01-17 7:15 GMT+01:00 Max Leske <[hidden email]>:

Hi Martin,

What I do is

1. update local pharo repository on branch 'development'

2. add repository to Iceberg

3. create branch for phogbugz issue

4. make changes (e.g. load stuff from your project)

5. Note that you will have to handle addition and removal of packages separately:

5.1 addition: click 'add package' 

5.2 removal: click 'remove package'. You will have to commit the removal from the command line, as Iceberg does not currently recognize removals as staged changes.

I usually just make a second commit with the removal before I push everything.

6. Now the changes may not show up. But you can right click on the repository in Iceberg and select 'Synchronize full repository'

7. Select the changes you want to commit

I think the 4-th step is the question. 

Epicea in image is managed by Iceberg and hosted in github. How to load new version from external monticello repo? Also there is no ConfigurationOfEpicea in the image.

 

The rest you know, I guess ;)

Cheers,

Max

 

On 16 January 2018 at 20:16:22, Martin Dias ([hidden email]) wrote:

Hi, I followed the guide and everything is good. What I don't know is how to upgrade an external project already integrated in Pharo 7 (Epicea). I have new version 8.2.6.

Cheers, Martín.

On Tue, Jan 9, 2018 at 11:01 AM, Sean P. DeNigris <[hidden email]> wrote:

EstebanLM wrote
>> Mmm. I think this is because your local clone is outdated.
>> It should be fixed with a fetch… from pharo-project, I mean :)

That worked. Thanks. Next problem: Iceberg is showing a massive number of
changes when syncing with pharo fork on the dev branch at the same commit as
the image. There doesn't seem to be a way to collapse the whole tree making
it impossible to find the real changes. I assume it's that known bug where
the first commit will sync the list, but not very user friendly!

-----
Cheers,
Sean
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

On 18 Jan 2018, at 18:39, Stephane Ducasse <[hidden email]> wrote:

Thanks Luke for your feedback
Guillermo and Pablo are working on a new Iceberg model and UI.

May be
we can ask you if you want to give them feedback
and try the new version.
It is important for us that people can contribute.

Stef

On Wed, Jan 17, 2018 at 12:20 PM, Luke Gorrie <[hidden email]> wrote:

Just one data point...

I am completely overwhelmed by all of the different ways to manage source
code in the Pharo universe. I would love to contribute to upstream but this
seems way out of reach: I'm not even managing to keep track of the code in
my own home directory properly yet.

Just now I am looking at upstream code that should be fixed: CairoLibrary
unix32ModuleName and unix64ModuleName are giving higher priority to guessed
hard-coded paths than to LD_LIBRARY_PATH and this is backwards i.e. the
carefully selected paths a user supplies with LD_LIBRARY_PATH should come
first (imho.)

On the one hand it would be fine to dive into the upstream contribution
process to work out how to do this. On the other hand I am still trying to
master tools like Epica to recover useful code that I have written and lost
track of when images crash and get rebuilt etc. I really need to get this
under control before spending time learning Iceberg, FogBugz, etc.

On 14 December 2017 at 13:19, Esteban Lorenzano <[hidden email]> wrote:

Hi!

I’m working on simplifying the contribution process, after collecting
opinions/experiences last couple of months.
As you know, Pharo contribution process is still WIP and we aim to have it
as smooth as possible for Pharo 7.0 release. Now, after observe the idea of
the “system repositories” was a bad idea because it introduced extra and non
standard “path” to contribution, I managed to remove that to reestablish
“the regular way”: you will now need to add pharo repository just as any
other repository you add, by cloning or adding local repository.

I took Guille’s doc and moved it to pharo project (it does not has sense
to have it living in a contributor’s repository when is so important). You
can find it here:

https://github.com/pharo-project/pharo/wiki/Contribute-a-fix-to-Pharo

This document is also updated to reveal this new process, please read it.

How to update your startup scripts?
Some people has added startup scripts to easy the first part of
contribution. Instead enabling system repositories, etc. you now need to
replace that with this:

(IceRepositoryCreator new
location: '/path/to/pharo-project/pharo' asFileReference;
subdirectory: 'src';
createRepository)
register

PLEASE, PLEASE, PLEASE… take a moment to read and try the document. Is
very important that document reflects new process and works reliable in
different scenarios (I validated it on macOS and Windows, and assumed it
worked fine on linux but you know… bad assumptions is the base of failure ;)
)

I’m eager to hear your feedback and continue enhancing the process.

(yes, Stef, I know UI is still cumbersome… I’m working on that :) )

cheers!
Esteban

On 19 Jan 2018, at 10:17, Luke Gorrie <[hidden email]> wrote:

Hi Esteban,

I am really happy that everything is working so well for you and I hope that other people are having a similar experience.

For me it's another story. I'm on an unsupported platform (NixOS Linux), I'm building the VM from random git commits because the source releases are all antiquated, Iceberg segfaults the moment I start it, and epica+monticello+metacello+iceberg+fogbugz+jenkins feels like a series of obstacles between me and maintaining my application.

The way I am coping is to scale back my ambitions. I spent a lot of time making a complete packaging for NixOS but without proper source releases from upstream that was too much work so I abandoned it. I take the non-reproducible builds from Jenkins and import them as binary-blobs into the build environment that I actually want to use. I accumulate fixes as changesets in a patches/ directory instead of sending them upstream.

To me it's a slap in the face when you tell me that it's so simple, there is only one true way to contribute to Pharo, and the first step of that procedure is to *install a binary that is not compatible with my Linux distribution.*

On 19 Jan 2018, at 13:00, Stephane Ducasse <[hidden email]> wrote:

On Fri, Jan 19, 2018 at 8:39 AM, Esteban Lorenzano <[hidden email]> wrote:

hi :)

On 18 Jan 2018, at 18:39, Stephane Ducasse <[hidden email]> wrote:

Thanks Luke for your feedback
Guillermo and Pablo are working on a new Iceberg model and UI.


Model is done, we will integrate it as 0.7 version.
UI… is harder. We could do a simple UI that allows just ONE path but at the
end, no one will use it, because almost no use-case follows that. Believe
me, I made a research on that… and if you do not believe me, go and try
github desktop, which basically does that (and nobody uses it ;) )

true story: actually the UI of iceberg was pretty simple when we started. It
became the mess it is now just adding what people asked to have.
but also true story: it *is* a mess, so we have to get it right before
release of Pharo7 :)

Esteban there are central problems in Iceberg current UI.

If we do not try something else we will not have feedback.

May be
we can ask you if you want to give them feedback
and try the new version.
It is important for us that people can contribute.

Stef

On Wed, Jan 17, 2018 at 12:20 PM, Luke Gorrie <[hidden email]> wrote:

Just one data point...

I am completely overwhelmed by all of the different ways to manage source
code in the Pharo universe. I would love to contribute to upstream but this
seems way out of reach: I'm not even managing to keep track of the code in
my own home directory properly yet.


there are just two ways:

- iceberg
- monticello

compare with the amount of ways you have in other languages.
you can use either way you want to keep yours sources.

but to contribute to Pharo there is just *one* way, following this
instructions:
https://github.com/pharo-project/pharo/wiki/Contribute-a-fix-to-Pharo

people has reported this version is a lot easier than previous ones (and is
not much different on how to contribute to other languages) but we are still
looking for ways to simplify it (I want to test github issue tracker soon,
for example, to enhance communication that today is broken in two parts… and
honest reality check: people finds easier to discuss on github over the PR
than over fogbugz).

Just now I am looking at upstream code that should be fixed: CairoLibrary
unix32ModuleName and unix64ModuleName are giving higher priority to guessed
hard-coded paths than to LD_LIBRARY_PATH and this is backwards i.e. the
carefully selected paths a user supplies with LD_LIBRARY_PATH should come
first (imho.)


follow the contribution instructions ;)

On the one hand it would be fine to dive into the upstream contribution
process to work out how to do this. On the other hand I am still trying to
master tools like Epica to recover useful code that I have written and lost
track of when images crash and get rebuilt etc. I really need to get this
under control before spending time learning Iceberg, FogBugz, etc.


well… not so much to say here. My only advice is to save often you image,
when you are working with things that you know may crash the VM (like using
FFI).

cheers!
Esteban





On 14 December 2017 at 13:19, Esteban Lorenzano <[hidden email]> wrote:


Hi!

I’m working on simplifying the contribution process, after collecting
opinions/experiences last couple of months.
As you know, Pharo contribution process is still WIP and we aim to have it
as smooth as possible for Pharo 7.0 release. Now, after observe the idea of
the “system repositories” was a bad idea because it introduced extra and non
standard “path” to contribution, I managed to remove that to reestablish
“the regular way”: you will now need to add pharo repository just as any
other repository you add, by cloning or adding local repository.

I took Guille’s doc and moved it to pharo project (it does not has sense
to have it living in a contributor’s repository when is so important). You
can find it here:

https://github.com/pharo-project/pharo/wiki/Contribute-a-fix-to-Pharo

This document is also updated to reveal this new process, please read it.

How to update your startup scripts?
Some people has added startup scripts to easy the first part of
contribution. Instead enabling system repositories, etc. you now need to
replace that with this:

(IceRepositoryCreator new
location: '/path/to/pharo-project/pharo' asFileReference;
subdirectory: 'src';
createRepository)
register

PLEASE, PLEASE, PLEASE… take a moment to read and try the document. Is
very important that document reflects new process and works reliable in
different scenarios (I validated it on macOS and Windows, and assumed it
worked fine on linux but you know… bad assumptions is the base of failure ;)
)

I’m eager to hear your feedback and continue enhancing the process.

(yes, Stef, I know UI is still cumbersome… I’m working on that :) )

cheers!
Esteban