[IMPORTANT] PHARO CONTRIBUTION PROCESS UPDATED! PLEASE READ!
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 <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
ah yes⦠this will be starting next build. Esteban
On 14 Dec 2017, at 13:19, Esteban Lorenzano <estebanlm@gmail.com> 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 <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 14 Dec 2017, at 13:19, Esteban Lorenzano <estebanlm@gmail.com> 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 <https://github.com/pharo-project/pharo/wiki/Contribute-a-fix-to-Pharo>
I updated http://pharo.org/contribute-propose-fix <http://pharo.org/contribute-propose-fix> to point to this link. Marcus
Works for me :-) This update will simplify things a lot because as soon as you create a branch from FogBugz issue, the Iceberg does following [1]: - fetches the pharo-project repository - checkouts to the particular commit from which the image was bootstrapped - creates a new branch That means that: - you do not need to keep your fork up-to-date manually - things should be cleaner So as soon as your local repository is created as clone of your fork repository (your fork is origin), you do not need to set push and pull target nor synchronize your fork with pharo-project repository. Esteban will fix me if I'm wrong ;-) [1] see IcePharoCreateBranchFromIssue>>#createBranchNamed: -- Pavel 2017-12-14 13:19 GMT+01:00 Esteban Lorenzano <estebanlm@gmail.com>:
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 Thu, Dec 14, 2017 at 2:34 PM, Pavel Krivanek <pavel.krivanek@gmail.com> wrote:
Works for me :-)
This update will simplify things a lot because as soon as you create a branch from FogBugz issue, the Iceberg does following [1]: - fetches the pharo-project repository - checkouts to the particular commit from which the image was bootstrapped - creates a new branch
That means that: - you do not need to keep your fork up-to-date manually - things should be cleaner
Ahhhhhh it looks like a huge improvement. Because keeping manually our fork was a pain. I will use my super nasty powers and try because I have some pending fixes :)
So as soon as your local repository is created as clone of your fork repository (your fork is origin), you do not need to set push and pull target nor synchronize your fork with pharo-project repository.
Esteban will fix me if I'm wrong ;-)
[1] see IcePharoCreateBranchFromIssue>>#createBranchNamed:
-- Pavel
2017-12-14 13:19 GMT+01:00 Esteban Lorenzano <estebanlm@gmail.com>:
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
Hi Esteban, I had no problems following the process (Ubuntu 16.04, Pharo7.0-32bit-e175bc2.image, fogbugz 20872). :-) I guess that you have already thought of this, but... Is there any reason why we can't just put up a dialog asking for the user's github credentials and fogbugz issue number and then automatically clone the repository, configure the upstream remote and create the issue branch. That would remove most of the remaining manual steps. I realise that it only works for option 1, although where people configure a common pharo-local, it could check for a pre-existing clone and use that one. Cheers, Alistair On 14 December 2017 at 13:19, Esteban Lorenzano <estebanlm@gmail.com> 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 15 Dec 2017, at 17:37, Alistair Grant <akgrant0710@gmail.com> wrote:
Hi Esteban,
I had no problems following the process (Ubuntu 16.04, Pharo7.0-32bit-e175bc2.image, fogbugz 20872). :-)
I guess that you have already thought of this, but... Is there any reason why we can't just put up a dialog asking for the user's github credentials and fogbugz issue number and then automatically clone the repository, configure the upstream remote and create the issue branch. That would remove most of the remaining manual steps.
I realise that it only works for option 1, although where people configure a common pharo-local, it could check for a pre-existing clone and use that one.
"I realiseâ means you tried and it didnât work? because in my tests it worked as good as the first one (I tested on windows), but that may need to be âre-validatedâ :) Esteban
Cheers, Alistair
On 14 December 2017 at 13:19, Esteban Lorenzano <estebanlm@gmail.com> 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
esteban to try the new way. What should I do? Just download a new version or reclone? May be I will refork and reclone to be sure. Stef On Sat, Dec 16, 2017 at 9:05 AM, Esteban Lorenzano <estebanlm@gmail.com> wrote:
On 15 Dec 2017, at 17:37, Alistair Grant <akgrant0710@gmail.com> wrote:
Hi Esteban,
I had no problems following the process (Ubuntu 16.04, Pharo7.0-32bit-e175bc2.image, fogbugz 20872). :-)
I guess that you have already thought of this, but... Is there any reason why we can't just put up a dialog asking for the user's github credentials and fogbugz issue number and then automatically clone the repository, configure the upstream remote and create the issue branch. That would remove most of the remaining manual steps.
I realise that it only works for option 1, although where people configure a common pharo-local, it could check for a pre-existing clone and use that one.
"I realiseâ means you tried and it didnât work? because in my tests it worked as good as the first one (I tested on windows), but that may need to be âre-validatedâ :)
Esteban
Cheers, Alistair
On 14 December 2017 at 13:19, Esteban Lorenzano <estebanlm@gmail.com> 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
download latest image and follow the steps explained here: https://github.com/pharo-project/pharo/wiki/Contribute-a-fix-to-Pharo <https://github.com/pharo-project/pharo/wiki/Contribute-a-fix-to-Pharo> Esteban
On 16 Dec 2017, at 09:07, Stephane Ducasse <stepharo.self@gmail.com> wrote:
esteban
to try the new way. What should I do? Just download a new version or reclone? May be I will refork and reclone to be sure.
Stef
On Sat, Dec 16, 2017 at 9:05 AM, Esteban Lorenzano <estebanlm@gmail.com> wrote:
On 15 Dec 2017, at 17:37, Alistair Grant <akgrant0710@gmail.com> wrote:
Hi Esteban,
I had no problems following the process (Ubuntu 16.04, Pharo7.0-32bit-e175bc2.image, fogbugz 20872). :-)
I guess that you have already thought of this, but... Is there any reason why we can't just put up a dialog asking for the user's github credentials and fogbugz issue number and then automatically clone the repository, configure the upstream remote and create the issue branch. That would remove most of the remaining manual steps.
I realise that it only works for option 1, although where people configure a common pharo-local, it could check for a pre-existing clone and use that one.
"I realiseâ means you tried and it didnât work? because in my tests it worked as good as the first one (I tested on windows), but that may need to be âre-validatedâ :)
Esteban
Cheers, Alistair
On 14 December 2017 at 13:19, Esteban Lorenzano <estebanlm@gmail.com> 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 16 Dec 2017, at 09:15, Esteban Lorenzano <estebanlm@gmail.com> wrote:
download latest image and follow the steps explained here:
https://github.com/pharo-project/pharo/wiki/Contribute-a-fix-to-Pharo <https://github.com/pharo-project/pharo/wiki/Contribute-a-fix-to-Pharo> side note: please do not try to adapt this steps to what you already know. is better if you try this steps âblindlyâ and later you do a synthesis between what you learned and what you know :)
Esteban
Esteban
On 16 Dec 2017, at 09:07, Stephane Ducasse <stepharo.self@gmail.com <mailto:stepharo.self@gmail.com>> wrote:
esteban
to try the new way. What should I do? Just download a new version or reclone? May be I will refork and reclone to be sure.
Stef
On Sat, Dec 16, 2017 at 9:05 AM, Esteban Lorenzano <estebanlm@gmail.com <mailto:estebanlm@gmail.com>> wrote:
On 15 Dec 2017, at 17:37, Alistair Grant <akgrant0710@gmail.com <mailto:akgrant0710@gmail.com>> wrote:
Hi Esteban,
I had no problems following the process (Ubuntu 16.04, Pharo7.0-32bit-e175bc2.image, fogbugz 20872). :-)
I guess that you have already thought of this, but... Is there any reason why we can't just put up a dialog asking for the user's github credentials and fogbugz issue number and then automatically clone the repository, configure the upstream remote and create the issue branch. That would remove most of the remaining manual steps.
I realise that it only works for option 1, although where people configure a common pharo-local, it could check for a pre-existing clone and use that one.
"I realiseâ means you tried and it didnât work? because in my tests it worked as good as the first one (I tested on windows), but that may need to be âre-validatedâ :)
Esteban
Cheers, Alistair
On 14 December 2017 at 13:19, Esteban Lorenzano <estebanlm@gmail.com <mailto:estebanlm@gmail.com>> 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 <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
Yes now I have some pending commits that I do not want to lose so I will fileout them and publish them. Stef On Sat, Dec 16, 2017 at 9:19 AM, Esteban Lorenzano <estebanlm@gmail.com> wrote:
On 16 Dec 2017, at 09:15, Esteban Lorenzano <estebanlm@gmail.com> wrote:
download latest image and follow the steps explained here:
https://github.com/pharo-project/pharo/wiki/Contribute-a-fix-to-Pharo
side note: please do not try to adapt this steps to what you already know. is better if you try this steps âblindlyâ and later you do a synthesis between what you learned and what you know :)
Esteban
Esteban
On 16 Dec 2017, at 09:07, Stephane Ducasse <stepharo.self@gmail.com> wrote:
esteban
to try the new way. What should I do? Just download a new version or reclone? May be I will refork and reclone to be sure.
Stef
On Sat, Dec 16, 2017 at 9:05 AM, Esteban Lorenzano <estebanlm@gmail.com> wrote:
On 15 Dec 2017, at 17:37, Alistair Grant <akgrant0710@gmail.com> wrote:
Hi Esteban,
I had no problems following the process (Ubuntu 16.04, Pharo7.0-32bit-e175bc2.image, fogbugz 20872). :-)
I guess that you have already thought of this, but... Is there any reason why we can't just put up a dialog asking for the user's github credentials and fogbugz issue number and then automatically clone the repository, configure the upstream remote and create the issue branch. That would remove most of the remaining manual steps.
I realise that it only works for option 1, although where people configure a common pharo-local, it could check for a pre-existing clone and use that one.
"I realiseâ means you tried and it didnât work? because in my tests it worked as good as the first one (I tested on windows), but that may need to be âre-validatedâ :)
Esteban
Cheers, Alistair
On 14 December 2017 at 13:19, Esteban Lorenzano <estebanlm@gmail.com> 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
Hi Esteban, On 16 December 2017 at 09:05, Esteban Lorenzano <estebanlm@gmail.com> wrote:
On 15 Dec 2017, at 17:37, Alistair Grant <akgrant0710@gmail.com> wrote:
Hi Esteban,
I had no problems following the process (Ubuntu 16.04, Pharo7.0-32bit-e175bc2.image, fogbugz 20872). :-)
I guess that you have already thought of this, but... Is there any reason why we can't just put up a dialog asking for the user's github credentials and fogbugz issue number and then automatically clone the repository, configure the upstream remote and create the issue branch. That would remove most of the remaining manual steps.
I realise that it only works for option 1, although where people configure a common pharo-local, it could check for a pre-existing clone and use that one.
"I realiseâ means you tried and it didnât work? because in my tests it worked as good as the first one (I tested on windows), but that may need to be âre-validatedâ :)
Esteban
The contribution process works fine (even on linux :-)). The "I realise" paragraph is a comment on my suggestion to try and reduce the number of manual steps required (and is actually wrong). Just to rephrase (and extend) the suggestion, I think we could create a single dialog that currently covers the following steps (from your instructions): 1. Clone a fresh repository, or point to an existing repository. 2. Tell Iceberg about pharo-project 3. Create a new branch from the fogbugz issue Cheers, Alistair
Cheers, Alistair
On 14 December 2017 at 13:19, Esteban Lorenzano <estebanlm@gmail.com> 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 16 Dec 2017, at 09:42, Alistair Grant <akgrant0710@gmail.com> wrote:
Hi Esteban,
On 16 December 2017 at 09:05, Esteban Lorenzano <estebanlm@gmail.com <mailto:estebanlm@gmail.com>> wrote:
On 15 Dec 2017, at 17:37, Alistair Grant <akgrant0710@gmail.com> wrote:
Hi Esteban,
I had no problems following the process (Ubuntu 16.04, Pharo7.0-32bit-e175bc2.image, fogbugz 20872). :-)
I guess that you have already thought of this, but... Is there any reason why we can't just put up a dialog asking for the user's github credentials and fogbugz issue number and then automatically clone the repository, configure the upstream remote and create the issue branch. That would remove most of the remaining manual steps.
I realise that it only works for option 1, although where people configure a common pharo-local, it could check for a pre-existing clone and use that one.
"I realiseâ means you tried and it didnât work? because in my tests it worked as good as the first one (I tested on windows), but that may need to be âre-validatedâ :)
Esteban
The contribution process works fine (even on linux :-)).
The "I realise" paragraph is a comment on my suggestion to try and reduce the number of manual steps required (and is actually wrong). Just to rephrase (and extend) the suggestion, I think we could create a single dialog that currently covers the following steps (from your instructions):
1. Clone a fresh repository, or point to an existing repository. 2. Tell Iceberg about pharo-project 3. Create a new branch from the fogbugz issue
ah, I got lost in translation ;) Esteban
Cheers, Alistair
Cheers, Alistair
On 14 December 2017 at 13:19, Esteban Lorenzano <estebanlm@gmail.com> 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
OK so I restarted everything from scratch: - deleted my fork - reforked - clone pharo again - here is some feedback In the tutorial add /pharo + src in the screenshot Then when I add the local repository I get uncommited changes and I do not understand why? On Sat, Dec 16, 2017 at 9:57 AM, Esteban Lorenzano <estebanlm@gmail.com> wrote:
On 16 Dec 2017, at 09:42, Alistair Grant <akgrant0710@gmail.com> wrote:
Hi Esteban,
On 16 December 2017 at 09:05, Esteban Lorenzano <estebanlm@gmail.com> wrote:
On 15 Dec 2017, at 17:37, Alistair Grant <akgrant0710@gmail.com> wrote:
Hi Esteban,
I had no problems following the process (Ubuntu 16.04, Pharo7.0-32bit-e175bc2.image, fogbugz 20872). :-)
I guess that you have already thought of this, but... Is there any reason why we can't just put up a dialog asking for the user's github credentials and fogbugz issue number and then automatically clone the repository, configure the upstream remote and create the issue branch. That would remove most of the remaining manual steps.
I realise that it only works for option 1, although where people configure a common pharo-local, it could check for a pre-existing clone and use that one.
"I realiseâ means you tried and it didnât work? because in my tests it worked as good as the first one (I tested on windows), but that may need to be âre-validatedâ :)
Esteban
The contribution process works fine (even on linux :-)).
The "I realise" paragraph is a comment on my suggestion to try and reduce the number of manual steps required (and is actually wrong). Just to rephrase (and extend) the suggestion, I think we could create a single dialog that currently covers the following steps (from your instructions):
1. Clone a fresh repository, or point to an existing repository. 2. Tell Iceberg about pharo-project 3. Create a new branch from the fogbugz issue
ah, I got lost in translation ;)
Esteban
Cheers, Alistair
Cheers, Alistair
On 14 December 2017 at 13:19, Esteban Lorenzano <estebanlm@gmail.com> 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
I double clicked and it did a massive amount of stuff and finally told me that it is up to date. On Sat, Dec 16, 2017 at 5:24 PM, Stephane Ducasse <stepharo.self@gmail.com> wrote:
OK so I restarted everything from scratch: - deleted my fork - reforked - clone pharo again - here is some feedback
In the tutorial add /pharo + src in the screenshot
Then when I add the local repository I get uncommited changes and I do not understand why?
On Sat, Dec 16, 2017 at 9:57 AM, Esteban Lorenzano <estebanlm@gmail.com> wrote:
On 16 Dec 2017, at 09:42, Alistair Grant <akgrant0710@gmail.com> wrote:
Hi Esteban,
On 16 December 2017 at 09:05, Esteban Lorenzano <estebanlm@gmail.com> wrote:
On 15 Dec 2017, at 17:37, Alistair Grant <akgrant0710@gmail.com> wrote:
Hi Esteban,
I had no problems following the process (Ubuntu 16.04, Pharo7.0-32bit-e175bc2.image, fogbugz 20872). :-)
I guess that you have already thought of this, but... Is there any reason why we can't just put up a dialog asking for the user's github credentials and fogbugz issue number and then automatically clone the repository, configure the upstream remote and create the issue branch. That would remove most of the remaining manual steps.
I realise that it only works for option 1, although where people configure a common pharo-local, it could check for a pre-existing clone and use that one.
"I realiseâ means you tried and it didnât work? because in my tests it worked as good as the first one (I tested on windows), but that may need to be âre-validatedâ :)
Esteban
The contribution process works fine (even on linux :-)).
The "I realise" paragraph is a comment on my suggestion to try and reduce the number of manual steps required (and is actually wrong). Just to rephrase (and extend) the suggestion, I think we could create a single dialog that currently covers the following steps (from your instructions):
1. Clone a fresh repository, or point to an existing repository. 2. Tell Iceberg about pharo-project 3. Create a new branch from the fogbugz issue
ah, I got lost in translation ;)
Esteban
Cheers, Alistair
Cheers, Alistair
On 14 December 2017 at 13:19, Esteban Lorenzano <estebanlm@gmail.com> 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
In the tutorial: - Put a little heading before "You need to add pharo repository as a remote (git@github.com:pharo-project/pharo.git)." On Sat, Dec 16, 2017 at 5:25 PM, Stephane Ducasse <stepharo.self@gmail.com> wrote:
I double clicked and it did a massive amount of stuff and finally told me that it is up to date.
On Sat, Dec 16, 2017 at 5:24 PM, Stephane Ducasse <stepharo.self@gmail.com> wrote:
OK so I restarted everything from scratch: - deleted my fork - reforked - clone pharo again - here is some feedback
In the tutorial add /pharo + src in the screenshot
Then when I add the local repository I get uncommited changes and I do not understand why?
On Sat, Dec 16, 2017 at 9:57 AM, Esteban Lorenzano <estebanlm@gmail.com> wrote:
On 16 Dec 2017, at 09:42, Alistair Grant <akgrant0710@gmail.com> wrote:
Hi Esteban,
On 16 December 2017 at 09:05, Esteban Lorenzano <estebanlm@gmail.com> wrote:
On 15 Dec 2017, at 17:37, Alistair Grant <akgrant0710@gmail.com> wrote:
Hi Esteban,
I had no problems following the process (Ubuntu 16.04, Pharo7.0-32bit-e175bc2.image, fogbugz 20872). :-)
I guess that you have already thought of this, but... Is there any reason why we can't just put up a dialog asking for the user's github credentials and fogbugz issue number and then automatically clone the repository, configure the upstream remote and create the issue branch. That would remove most of the remaining manual steps.
I realise that it only works for option 1, although where people configure a common pharo-local, it could check for a pre-existing clone and use that one.
"I realiseâ means you tried and it didnât work? because in my tests it worked as good as the first one (I tested on windows), but that may need to be âre-validatedâ :)
Esteban
The contribution process works fine (even on linux :-)).
The "I realise" paragraph is a comment on my suggestion to try and reduce the number of manual steps required (and is actually wrong). Just to rephrase (and extend) the suggestion, I think we could create a single dialog that currently covers the following steps (from your instructions):
1. Clone a fresh repository, or point to an existing repository. 2. Tell Iceberg about pharo-project 3. Create a new branch from the fogbugz issue
ah, I got lost in translation ;)
Esteban
Cheers, Alistair
Cheers, Alistair
On 14 December 2017 at 13:19, Esteban Lorenzano <estebanlm@gmail.com> 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
I did a little pass on the wiki to make the flow clearer On Sat, Dec 16, 2017 at 5:26 PM, Stephane Ducasse <stepharo.self@gmail.com> wrote:
In the tutorial:
- Put a little heading before
"You need to add pharo repository as a remote (git@github.com:pharo-project/pharo.git)."
On Sat, Dec 16, 2017 at 5:25 PM, Stephane Ducasse <stepharo.self@gmail.com> wrote:
I double clicked and it did a massive amount of stuff and finally told me that it is up to date.
On Sat, Dec 16, 2017 at 5:24 PM, Stephane Ducasse <stepharo.self@gmail.com> wrote:
OK so I restarted everything from scratch: - deleted my fork - reforked - clone pharo again - here is some feedback
In the tutorial add /pharo + src in the screenshot
Then when I add the local repository I get uncommited changes and I do not understand why?
On Sat, Dec 16, 2017 at 9:57 AM, Esteban Lorenzano <estebanlm@gmail.com> wrote:
On 16 Dec 2017, at 09:42, Alistair Grant <akgrant0710@gmail.com> wrote:
Hi Esteban,
On 16 December 2017 at 09:05, Esteban Lorenzano <estebanlm@gmail.com> wrote:
On 15 Dec 2017, at 17:37, Alistair Grant <akgrant0710@gmail.com> wrote:
Hi Esteban,
I had no problems following the process (Ubuntu 16.04, Pharo7.0-32bit-e175bc2.image, fogbugz 20872). :-)
I guess that you have already thought of this, but... Is there any reason why we can't just put up a dialog asking for the user's github credentials and fogbugz issue number and then automatically clone the repository, configure the upstream remote and create the issue branch. That would remove most of the remaining manual steps.
I realise that it only works for option 1, although where people configure a common pharo-local, it could check for a pre-existing clone and use that one.
"I realiseâ means you tried and it didnât work? because in my tests it worked as good as the first one (I tested on windows), but that may need to be âre-validatedâ :)
Esteban
The contribution process works fine (even on linux :-)).
The "I realise" paragraph is a comment on my suggestion to try and reduce the number of manual steps required (and is actually wrong). Just to rephrase (and extend) the suggestion, I think we could create a single dialog that currently covers the following steps (from your instructions):
1. Clone a fresh repository, or point to an existing repository. 2. Tell Iceberg about pharo-project 3. Create a new branch from the fogbugz issue
ah, I got lost in translation ;)
Esteban
Cheers, Alistair
Cheers, Alistair
On 14 December 2017 at 13:19, Esteban Lorenzano <estebanlm@gmail.com> 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
I committed my code for issue 20861 and I do not understand what I see I do not understand why I get local changes with empty packages. :( Stef On Sat, Dec 16, 2017 at 5:32 PM, Stephane Ducasse <stepharo.self@gmail.com> wrote:
I did a little pass on the wiki to make the flow clearer
On Sat, Dec 16, 2017 at 5:26 PM, Stephane Ducasse <stepharo.self@gmail.com> wrote:
In the tutorial:
- Put a little heading before
"You need to add pharo repository as a remote (git@github.com:pharo-project/pharo.git)."
On Sat, Dec 16, 2017 at 5:25 PM, Stephane Ducasse <stepharo.self@gmail.com> wrote:
I double clicked and it did a massive amount of stuff and finally told me that it is up to date.
On Sat, Dec 16, 2017 at 5:24 PM, Stephane Ducasse <stepharo.self@gmail.com> wrote:
OK so I restarted everything from scratch: - deleted my fork - reforked - clone pharo again - here is some feedback
In the tutorial add /pharo + src in the screenshot
Then when I add the local repository I get uncommited changes and I do not understand why?
On Sat, Dec 16, 2017 at 9:57 AM, Esteban Lorenzano <estebanlm@gmail.com> wrote:
On 16 Dec 2017, at 09:42, Alistair Grant <akgrant0710@gmail.com> wrote:
Hi Esteban,
On 16 December 2017 at 09:05, Esteban Lorenzano <estebanlm@gmail.com> wrote:
On 15 Dec 2017, at 17:37, Alistair Grant <akgrant0710@gmail.com> wrote:
Hi Esteban,
I had no problems following the process (Ubuntu 16.04, Pharo7.0-32bit-e175bc2.image, fogbugz 20872). :-)
I guess that you have already thought of this, but... Is there any reason why we can't just put up a dialog asking for the user's github credentials and fogbugz issue number and then automatically clone the repository, configure the upstream remote and create the issue branch. That would remove most of the remaining manual steps.
I realise that it only works for option 1, although where people configure a common pharo-local, it could check for a pre-existing clone and use that one.
"I realiseâ means you tried and it didnât work? because in my tests it worked as good as the first one (I tested on windows), but that may need to be âre-validatedâ :)
Esteban
The contribution process works fine (even on linux :-)).
The "I realise" paragraph is a comment on my suggestion to try and reduce the number of manual steps required (and is actually wrong). Just to rephrase (and extend) the suggestion, I think we could create a single dialog that currently covers the following steps (from your instructions):
1. Clone a fresh repository, or point to an existing repository. 2. Tell Iceberg about pharo-project 3. Create a new branch from the fogbugz issue
ah, I got lost in translation ;)
Esteban
Cheers, Alistair
Cheers, Alistair
On 14 December 2017 at 13:19, Esteban Lorenzano <estebanlm@gmail.com> 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
Hi Esteban Now how can I maintain my fork up to date? This is not in the tutorial and to me it was a major problem and a big source of pain. Stef On Sat, Dec 16, 2017 at 5:39 PM, Stephane Ducasse <stepharo.self@gmail.com> wrote:
I committed my code for issue 20861 and I do not understand what I see
I do not understand why I get local changes with empty packages. :(
Stef
On Sat, Dec 16, 2017 at 5:32 PM, Stephane Ducasse <stepharo.self@gmail.com> wrote:
I did a little pass on the wiki to make the flow clearer
On Sat, Dec 16, 2017 at 5:26 PM, Stephane Ducasse <stepharo.self@gmail.com> wrote:
In the tutorial:
- Put a little heading before
"You need to add pharo repository as a remote (git@github.com:pharo-project/pharo.git)."
On Sat, Dec 16, 2017 at 5:25 PM, Stephane Ducasse <stepharo.self@gmail.com> wrote:
I double clicked and it did a massive amount of stuff and finally told me that it is up to date.
On Sat, Dec 16, 2017 at 5:24 PM, Stephane Ducasse <stepharo.self@gmail.com> wrote:
OK so I restarted everything from scratch: - deleted my fork - reforked - clone pharo again - here is some feedback
In the tutorial add /pharo + src in the screenshot
Then when I add the local repository I get uncommited changes and I do not understand why?
On Sat, Dec 16, 2017 at 9:57 AM, Esteban Lorenzano <estebanlm@gmail.com> wrote:
On 16 Dec 2017, at 09:42, Alistair Grant <akgrant0710@gmail.com> wrote:
Hi Esteban,
On 16 December 2017 at 09:05, Esteban Lorenzano <estebanlm@gmail.com> wrote:
On 15 Dec 2017, at 17:37, Alistair Grant <akgrant0710@gmail.com> wrote:
Hi Esteban,
I had no problems following the process (Ubuntu 16.04, Pharo7.0-32bit-e175bc2.image, fogbugz 20872). :-)
I guess that you have already thought of this, but... Is there any reason why we can't just put up a dialog asking for the user's github credentials and fogbugz issue number and then automatically clone the repository, configure the upstream remote and create the issue branch. That would remove most of the remaining manual steps.
I realise that it only works for option 1, although where people configure a common pharo-local, it could check for a pre-existing clone and use that one.
"I realiseâ means you tried and it didnât work? because in my tests it worked as good as the first one (I tested on windows), but that may need to be âre-validatedâ :)
Esteban
The contribution process works fine (even on linux :-)).
The "I realise" paragraph is a comment on my suggestion to try and reduce the number of manual steps required (and is actually wrong). Just to rephrase (and extend) the suggestion, I think we could create a single dialog that currently covers the following steps (from your instructions):
1. Clone a fresh repository, or point to an existing repository. 2. Tell Iceberg about pharo-project 3. Create a new branch from the fogbugz issue
ah, I got lost in translation ;)
Esteban
Cheers, Alistair
Cheers, Alistair
On 14 December 2017 at 13:19, Esteban Lorenzano <estebanlm@gmail.com> 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
I clicked on pharo-project remote and I did fetch. thinking stupidly that it will update my local repo. And I get the following .... and I do not understand whay I get 1965 not published. and I do not Then I siwtched branch and went back to development. and I should be able to now push to my remote. So I tried but I'm totally unsure if this is correct. On Sat, Dec 16, 2017 at 5:55 PM, Stephane Ducasse <stepharo.self@gmail.com> wrote:
Hi Esteban
Now how can I maintain my fork up to date? This is not in the tutorial and to me it was a major problem and a big source of pain. Stef
On Sat, Dec 16, 2017 at 5:39 PM, Stephane Ducasse <stepharo.self@gmail.com> wrote:
I committed my code for issue 20861 and I do not understand what I see
I do not understand why I get local changes with empty packages. :(
Stef
On Sat, Dec 16, 2017 at 5:32 PM, Stephane Ducasse <stepharo.self@gmail.com> wrote:
I did a little pass on the wiki to make the flow clearer
On Sat, Dec 16, 2017 at 5:26 PM, Stephane Ducasse <stepharo.self@gmail.com> wrote:
In the tutorial:
- Put a little heading before
"You need to add pharo repository as a remote (git@github.com:pharo-project/pharo.git)."
On Sat, Dec 16, 2017 at 5:25 PM, Stephane Ducasse <stepharo.self@gmail.com> wrote:
I double clicked and it did a massive amount of stuff and finally told me that it is up to date.
On Sat, Dec 16, 2017 at 5:24 PM, Stephane Ducasse <stepharo.self@gmail.com> wrote:
OK so I restarted everything from scratch: - deleted my fork - reforked - clone pharo again - here is some feedback
In the tutorial add /pharo + src in the screenshot
Then when I add the local repository I get uncommited changes and I do not understand why?
On Sat, Dec 16, 2017 at 9:57 AM, Esteban Lorenzano <estebanlm@gmail.com> wrote:
On 16 Dec 2017, at 09:42, Alistair Grant <akgrant0710@gmail.com> wrote:
Hi Esteban,
On 16 December 2017 at 09:05, Esteban Lorenzano <estebanlm@gmail.com> wrote:
On 15 Dec 2017, at 17:37, Alistair Grant <akgrant0710@gmail.com> wrote:
Hi Esteban,
I had no problems following the process (Ubuntu 16.04, Pharo7.0-32bit-e175bc2.image, fogbugz 20872). :-)
I guess that you have already thought of this, but... Is there any reason why we can't just put up a dialog asking for the user's github credentials and fogbugz issue number and then automatically clone the repository, configure the upstream remote and create the issue branch. That would remove most of the remaining manual steps.
I realise that it only works for option 1, although where people configure a common pharo-local, it could check for a pre-existing clone and use that one.
"I realiseâ means you tried and it didnât work? because in my tests it worked as good as the first one (I tested on windows), but that may need to be âre-validatedâ :)
Esteban
The contribution process works fine (even on linux :-)).
The "I realise" paragraph is a comment on my suggestion to try and reduce the number of manual steps required (and is actually wrong). Just to rephrase (and extend) the suggestion, I think we could create a single dialog that currently covers the following steps (from your instructions):
1. Clone a fresh repository, or point to an existing repository. 2. Tell Iceberg about pharo-project 3. Create a new branch from the fogbugz issue
ah, I got lost in translation ;)
Esteban
Cheers, Alistair
Cheers, Alistair
On 14 December 2017 at 13:19, Esteban Lorenzano <estebanlm@gmail.com> 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 16 Dec 2017, at 17:55, Stephane Ducasse <stepharo.self@gmail.com> wrote:
Hi Esteban
Now how can I maintain my fork up to date?
there is a âsynchronise repositoriesâ option there, at the side of âcreate branch from fogbugzâ.
This is not in the tutorial and to me it was a major problem and a big source of pain.
it is not there because you do not need it. when you âcreate branch from fogbugzâ, it will take your image version and branch from there. Then, when you push to your remote, you will push correctly. There is no need to have syncd the forks to contribute⦠Now, if you do âsynchronise repositoriesâ, it will take what is in pharo-project/pharo/development branch and it will sync that with your pharo/development branch. But again⦠there is no need to do this to contribute. Esteban
Stef
On Sat, Dec 16, 2017 at 5:39 PM, Stephane Ducasse <stepharo.self@gmail.com> wrote:
I committed my code for issue 20861 and I do not understand what I see
I do not understand why I get local changes with empty packages. :(
Stef
On Sat, Dec 16, 2017 at 5:32 PM, Stephane Ducasse <stepharo.self@gmail.com> wrote:
I did a little pass on the wiki to make the flow clearer
On Sat, Dec 16, 2017 at 5:26 PM, Stephane Ducasse <stepharo.self@gmail.com> wrote:
In the tutorial:
- Put a little heading before
"You need to add pharo repository as a remote (git@github.com:pharo-project/pharo.git)."
On Sat, Dec 16, 2017 at 5:25 PM, Stephane Ducasse <stepharo.self@gmail.com> wrote:
I double clicked and it did a massive amount of stuff and finally told me that it is up to date.
On Sat, Dec 16, 2017 at 5:24 PM, Stephane Ducasse <stepharo.self@gmail.com> wrote:
OK so I restarted everything from scratch: - deleted my fork - reforked - clone pharo again - here is some feedback
In the tutorial add /pharo + src in the screenshot
Then when I add the local repository I get uncommited changes and I do not understand why?
On Sat, Dec 16, 2017 at 9:57 AM, Esteban Lorenzano <estebanlm@gmail.com> wrote:
On 16 Dec 2017, at 09:42, Alistair Grant <akgrant0710@gmail.com> wrote:
Hi Esteban,
On 16 December 2017 at 09:05, Esteban Lorenzano <estebanlm@gmail.com> wrote:
On 15 Dec 2017, at 17:37, Alistair Grant <akgrant0710@gmail.com> wrote:
Hi Esteban,
I had no problems following the process (Ubuntu 16.04, Pharo7.0-32bit-e175bc2.image, fogbugz 20872). :-)
I guess that you have already thought of this, but... Is there any reason why we can't just put up a dialog asking for the user's github credentials and fogbugz issue number and then automatically clone the repository, configure the upstream remote and create the issue branch. That would remove most of the remaining manual steps.
I realise that it only works for option 1, although where people configure a common pharo-local, it could check for a pre-existing clone and use that one.
"I realiseâ means you tried and it didnât work? because in my tests it worked as good as the first one (I tested on windows), but that may need to be âre-validatedâ :)
Esteban
The contribution process works fine (even on linux :-)).
The "I realise" paragraph is a comment on my suggestion to try and reduce the number of manual steps required (and is actually wrong). Just to rephrase (and extend) the suggestion, I think we could create a single dialog that currently covers the following steps (from your instructions):
1. Clone a fresh repository, or point to an existing repository. 2. Tell Iceberg about pharo-project 3. Create a new branch from the fogbugz issue
ah, I got lost in translation ;)
Esteban
Cheers, Alistair
Cheers, Alistair
On 14 December 2017 at 13:19, Esteban Lorenzano <estebanlm@gmail.com> 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
Sure I need because I stage my work. So I need something to be integrated to use it. On Sat, Dec 16, 2017 at 6:53 PM, Esteban Lorenzano <estebanlm@gmail.com> wrote:
On 16 Dec 2017, at 17:55, Stephane Ducasse <stepharo.self@gmail.com> wrote:
Hi Esteban
Now how can I maintain my fork up to date?
there is a âsynchronise repositoriesâ option there, at the side of âcreate branch from fogbugzâ.
This is not in the tutorial and to me it was a major problem and a big source of pain.
it is not there because you do not need it. when you âcreate branch from fogbugzâ, it will take your image version and branch from there. Then, when you push to your remote, you will push correctly. There is no need to have syncd the forks to contributeâ¦
Now, if you do âsynchronise repositoriesâ, it will take what is in pharo-project/pharo/development branch and it will sync that with your pharo/development branch. But again⦠there is no need to do this to contribute.
Esteban
Stef
On Sat, Dec 16, 2017 at 5:39 PM, Stephane Ducasse <stepharo.self@gmail.com> wrote:
I committed my code for issue 20861 and I do not understand what I see
I do not understand why I get local changes with empty packages. :(
Stef
On Sat, Dec 16, 2017 at 5:32 PM, Stephane Ducasse <stepharo.self@gmail.com> wrote:
I did a little pass on the wiki to make the flow clearer
On Sat, Dec 16, 2017 at 5:26 PM, Stephane Ducasse <stepharo.self@gmail.com> wrote:
In the tutorial:
- Put a little heading before
"You need to add pharo repository as a remote (git@github.com:pharo-project/pharo.git)."
On Sat, Dec 16, 2017 at 5:25 PM, Stephane Ducasse <stepharo.self@gmail.com> wrote:
I double clicked and it did a massive amount of stuff and finally told me that it is up to date.
On Sat, Dec 16, 2017 at 5:24 PM, Stephane Ducasse <stepharo.self@gmail.com> wrote:
OK so I restarted everything from scratch: - deleted my fork - reforked - clone pharo again - here is some feedback
In the tutorial add /pharo + src in the screenshot
Then when I add the local repository I get uncommited changes and I do not understand why?
On Sat, Dec 16, 2017 at 9:57 AM, Esteban Lorenzano <estebanlm@gmail.com> wrote:
On 16 Dec 2017, at 09:42, Alistair Grant <akgrant0710@gmail.com> wrote:
Hi Esteban,
On 16 December 2017 at 09:05, Esteban Lorenzano <estebanlm@gmail.com> wrote:
On 15 Dec 2017, at 17:37, Alistair Grant <akgrant0710@gmail.com> wrote:
Hi Esteban,
I had no problems following the process (Ubuntu 16.04, Pharo7.0-32bit-e175bc2.image, fogbugz 20872). :-)
I guess that you have already thought of this, but... Is there any reason why we can't just put up a dialog asking for the user's github credentials and fogbugz issue number and then automatically clone the repository, configure the upstream remote and create the issue branch. That would remove most of the remaining manual steps.
I realise that it only works for option 1, although where people configure a common pharo-local, it could check for a pre-existing clone and use that one.
"I realiseâ means you tried and it didnât work? because in my tests it worked as good as the first one (I tested on windows), but that may need to be âre-validatedâ :)
Esteban
The contribution process works fine (even on linux :-)).
The "I realise" paragraph is a comment on my suggestion to try and reduce the number of manual steps required (and is actually wrong). Just to rephrase (and extend) the suggestion, I think we could create a single dialog that currently covers the following steps (from your instructions):
1. Clone a fresh repository, or point to an existing repository. 2. Tell Iceberg about pharo-project 3. Create a new branch from the fogbugz issue
ah, I got lost in translation ;)
Esteban
Cheers, Alistair
Cheers, Alistair
On 14 December 2017 at 13:19, Esteban Lorenzano <estebanlm@gmail.com> 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
BTW I do not understand why I have changes that I do not do in my image it displays the changes with a dot and the end. And also I do not get why the class comment get changed when I do not do anything. Do you experience the same? BTW I did the pull from pharo and push to my fork by hand to synchronise. So I will try the synchronise menu item. I saw it but did not dare to use it. On Sat, Dec 16, 2017 at 9:48 PM, Stephane Ducasse <stepharo.self@gmail.com> wrote:
Sure I need because I stage my work. So I need something to be integrated to use it.
On Sat, Dec 16, 2017 at 6:53 PM, Esteban Lorenzano <estebanlm@gmail.com> wrote:
On 16 Dec 2017, at 17:55, Stephane Ducasse <stepharo.self@gmail.com> wrote:
Hi Esteban
Now how can I maintain my fork up to date?
there is a âsynchronise repositoriesâ option there, at the side of âcreate branch from fogbugzâ.
This is not in the tutorial and to me it was a major problem and a big source of pain.
it is not there because you do not need it. when you âcreate branch from fogbugzâ, it will take your image version and branch from there. Then, when you push to your remote, you will push correctly. There is no need to have syncd the forks to contributeâ¦
Now, if you do âsynchronise repositoriesâ, it will take what is in pharo-project/pharo/development branch and it will sync that with your pharo/development branch. But again⦠there is no need to do this to contribute.
Esteban
Stef
On Sat, Dec 16, 2017 at 5:39 PM, Stephane Ducasse <stepharo.self@gmail.com> wrote:
I committed my code for issue 20861 and I do not understand what I see
I do not understand why I get local changes with empty packages. :(
Stef
On Sat, Dec 16, 2017 at 5:32 PM, Stephane Ducasse <stepharo.self@gmail.com> wrote:
I did a little pass on the wiki to make the flow clearer
On Sat, Dec 16, 2017 at 5:26 PM, Stephane Ducasse <stepharo.self@gmail.com> wrote:
In the tutorial:
- Put a little heading before
"You need to add pharo repository as a remote (git@github.com:pharo-project/pharo.git)."
On Sat, Dec 16, 2017 at 5:25 PM, Stephane Ducasse <stepharo.self@gmail.com> wrote:
I double clicked and it did a massive amount of stuff and finally told me that it is up to date.
On Sat, Dec 16, 2017 at 5:24 PM, Stephane Ducasse <stepharo.self@gmail.com> wrote:
OK so I restarted everything from scratch: - deleted my fork - reforked - clone pharo again - here is some feedback
In the tutorial add /pharo + src in the screenshot
Then when I add the local repository I get uncommited changes and I do not understand why?
On Sat, Dec 16, 2017 at 9:57 AM, Esteban Lorenzano <estebanlm@gmail.com> wrote:
On 16 Dec 2017, at 09:42, Alistair Grant <akgrant0710@gmail.com> wrote:
Hi Esteban,
On 16 December 2017 at 09:05, Esteban Lorenzano <estebanlm@gmail.com> wrote:
On 15 Dec 2017, at 17:37, Alistair Grant <akgrant0710@gmail.com> wrote:
Hi Esteban,
I had no problems following the process (Ubuntu 16.04, Pharo7.0-32bit-e175bc2.image, fogbugz 20872). :-)
I guess that you have already thought of this, but... Is there any reason why we can't just put up a dialog asking for the user's github credentials and fogbugz issue number and then automatically clone the repository, configure the upstream remote and create the issue branch. That would remove most of the remaining manual steps.
I realise that it only works for option 1, although where people configure a common pharo-local, it could check for a pre-existing clone and use that one.
"I realiseâ means you tried and it didnât work? because in my tests it worked as good as the first one (I tested on windows), but that may need to be âre-validatedâ :)
Esteban
The contribution process works fine (even on linux :-)).
The "I realise" paragraph is a comment on my suggestion to try and reduce the number of manual steps required (and is actually wrong). Just to rephrase (and extend) the suggestion, I think we could create a single dialog that currently covers the following steps (from your instructions):
1. Clone a fresh repository, or point to an existing repository. 2. Tell Iceberg about pharo-project 3. Create a new branch from the fogbugz issue
ah, I got lost in translation ;)
Esteban
Cheers, Alistair
Cheers, Alistair
On 14 December 2017 at 13:19, Esteban Lorenzano <estebanlm@gmail.com> 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
Hi. I try to start from scratch. I made changes and then after synchronisation I close the window without committing. And now pharo repo is not dirty anymore and I do not see any changes with new sync request. Full sync helps but now there are other changes which I did not do. 2017-12-16 21:50 GMT+01:00 Stephane Ducasse <stepharo.self@gmail.com>:
BTW I do not understand why I have changes that I do not do in my image it displays the changes with a dot and the end.
And also I do not get why the class comment get changed when I do not do anything. Do you experience the same?
BTW I did the pull from pharo and push to my fork by hand to synchronise. So I will try the synchronise menu item. I saw it but did not dare to use it.
On Sat, Dec 16, 2017 at 9:48 PM, Stephane Ducasse <stepharo.self@gmail.com> wrote:
Sure I need because I stage my work. So I need something to be integrated to use it.
On Sat, Dec 16, 2017 at 6:53 PM, Esteban Lorenzano <estebanlm@gmail.com> wrote:
On 16 Dec 2017, at 17:55, Stephane Ducasse <stepharo.self@gmail.com>
wrote:
Hi Esteban
Now how can I maintain my fork up to date?
there is a âsynchronise repositoriesâ option there, at the side of âcreate branch from fogbugzâ.
This is not in the tutorial and to me it was a major problem and a big source of pain.
it is not there because you do not need it. when you âcreate branch from fogbugzâ, it will take your image version and branch from there. Then, when you push to your remote, you will push correctly. There is no need to have syncd the forks to contributeâ¦
Now, if you do âsynchronise repositoriesâ, it will take what is in pharo-project/pharo/development branch and it will sync that with your pharo/development branch. But again⦠there is no need to do this to contribute.
Esteban
Stef
On Sat, Dec 16, 2017 at 5:39 PM, Stephane Ducasse <stepharo.self@gmail.com> wrote:
I committed my code for issue 20861 and I do not understand what I see
I do not understand why I get local changes with empty packages. :(
Stef
On Sat, Dec 16, 2017 at 5:32 PM, Stephane Ducasse <stepharo.self@gmail.com> wrote:
I did a little pass on the wiki to make the flow clearer
On Sat, Dec 16, 2017 at 5:26 PM, Stephane Ducasse <stepharo.self@gmail.com> wrote:
In the tutorial:
- Put a little heading before
"You need to add pharo repository as a remote (git@github.com:pharo-project/pharo.git)."
On Sat, Dec 16, 2017 at 5:25 PM, Stephane Ducasse <stepharo.self@gmail.com> wrote:
I double clicked and it did a massive amount of stuff and finally told me that it is up to date.
On Sat, Dec 16, 2017 at 5:24 PM, Stephane Ducasse <stepharo.self@gmail.com> wrote:
OK so I restarted everything from scratch: - deleted my fork - reforked - clone pharo again - here is some feedback
In the tutorial add /pharo + src in the screenshot
Then when I add the local repository I get uncommited changes and I do not understand why?
On Sat, Dec 16, 2017 at 9:57 AM, Esteban Lorenzano < estebanlm@gmail.com> wrote:
On 16 Dec 2017, at 09:42, Alistair Grant <akgrant0710@gmail.com>
wrote:
Hi Esteban,
On 16 December 2017 at 09:05, Esteban Lorenzano <
estebanlm@gmail.com> wrote:
On 15 Dec 2017, at 17:37, Alistair Grant <akgrant0710@gmail.com>
wrote:
Hi Esteban,
I had no problems following the process (Ubuntu 16.04, Pharo7.0-32bit-e175bc2.image, fogbugz 20872). :-)
I guess that you have already thought of this, but... Is there
any
reason why we can't just put up a dialog asking for the user's github credentials and fogbugz issue number and then automatically clone the repository, configure the upstream remote and create the issue branch. That would remove most of the remaining manual steps.
I realise that it only works for option 1, although where people configure a common pharo-local, it could check for a pre-existing clone and use that one.
"I realiseâ means you tried and it didnât work? because in my tests it worked as good as the first one (I tested on windows), but that may need to be âre-validatedâ :)
Esteban
The contribution process works fine (even on linux :-)).
The "I realise" paragraph is a comment on my suggestion to try and reduce the number of manual steps required (and is actually wrong). Just to rephrase (and extend) the suggestion, I think we could create a single dialog that currently covers the following steps (from your instructions):
1. Clone a fresh repository, or point to an existing repository. 2. Tell Iceberg about pharo-project 3. Create a new branch from the fogbugz issue
ah, I got lost in translation ;)
Esteban
Cheers, Alistair
Cheers, Alistair
On 14 December 2017 at 13:19, Esteban Lorenzano < estebanlm@gmail.com> 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 16 Dec 2017, at 17:39, Stephane Ducasse <stepharo.self@gmail.com> wrote:
I committed my code for issue 20861 and I do not understand what I see
I do not understand why I get local changes with empty packages. :(
thatâs a bug: there are no changes to commit (which is correct), but the refresh lets there the original packages. It is in the todo to correct this :)
Stef
On Sat, Dec 16, 2017 at 5:32 PM, Stephane Ducasse <stepharo.self@gmail.com> wrote:
I did a little pass on the wiki to make the flow clearer
On Sat, Dec 16, 2017 at 5:26 PM, Stephane Ducasse <stepharo.self@gmail.com> wrote:
In the tutorial:
- Put a little heading before
"You need to add pharo repository as a remote (git@github.com:pharo-project/pharo.git)."
On Sat, Dec 16, 2017 at 5:25 PM, Stephane Ducasse <stepharo.self@gmail.com> wrote:
I double clicked and it did a massive amount of stuff and finally told me that it is up to date.
On Sat, Dec 16, 2017 at 5:24 PM, Stephane Ducasse <stepharo.self@gmail.com> wrote:
OK so I restarted everything from scratch: - deleted my fork - reforked - clone pharo again - here is some feedback
In the tutorial add /pharo + src in the screenshot
Then when I add the local repository I get uncommited changes and I do not understand why?
On Sat, Dec 16, 2017 at 9:57 AM, Esteban Lorenzano <estebanlm@gmail.com> wrote:
On 16 Dec 2017, at 09:42, Alistair Grant <akgrant0710@gmail.com> wrote:
Hi Esteban,
On 16 December 2017 at 09:05, Esteban Lorenzano <estebanlm@gmail.com> wrote:
On 15 Dec 2017, at 17:37, Alistair Grant <akgrant0710@gmail.com> wrote:
Hi Esteban,
I had no problems following the process (Ubuntu 16.04, Pharo7.0-32bit-e175bc2.image, fogbugz 20872). :-)
I guess that you have already thought of this, but... Is there any reason why we can't just put up a dialog asking for the user's github credentials and fogbugz issue number and then automatically clone the repository, configure the upstream remote and create the issue branch. That would remove most of the remaining manual steps.
I realise that it only works for option 1, although where people configure a common pharo-local, it could check for a pre-existing clone and use that one.
"I realiseâ means you tried and it didnât work? because in my tests it worked as good as the first one (I tested on windows), but that may need to be âre-validatedâ :)
Esteban
The contribution process works fine (even on linux :-)).
The "I realise" paragraph is a comment on my suggestion to try and reduce the number of manual steps required (and is actually wrong). Just to rephrase (and extend) the suggestion, I think we could create a single dialog that currently covers the following steps (from your instructions):
1. Clone a fresh repository, or point to an existing repository. 2. Tell Iceberg about pharo-project 3. Create a new branch from the fogbugz issue
ah, I got lost in translation ;)
Esteban
Cheers, Alistair
Cheers, Alistair
On 14 December 2017 at 13:19, Esteban Lorenzano <estebanlm@gmail.com> 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
<Screen Shot 2017-12-16 at 17.37.50.png>
On 16 Dec 2017, at 17:32, Stephane Ducasse <stepharo.self@gmail.com> wrote:
I did a little pass on the wiki to make the flow clearer
cool! :)
On Sat, Dec 16, 2017 at 5:26 PM, Stephane Ducasse <stepharo.self@gmail.com> wrote:
In the tutorial:
- Put a little heading before
"You need to add pharo repository as a remote (git@github.com:pharo-project/pharo.git)."
On Sat, Dec 16, 2017 at 5:25 PM, Stephane Ducasse <stepharo.self@gmail.com> wrote:
I double clicked and it did a massive amount of stuff and finally told me that it is up to date.
On Sat, Dec 16, 2017 at 5:24 PM, Stephane Ducasse <stepharo.self@gmail.com> wrote:
OK so I restarted everything from scratch: - deleted my fork - reforked - clone pharo again - here is some feedback
In the tutorial add /pharo + src in the screenshot
Then when I add the local repository I get uncommited changes and I do not understand why?
On Sat, Dec 16, 2017 at 9:57 AM, Esteban Lorenzano <estebanlm@gmail.com> wrote:
On 16 Dec 2017, at 09:42, Alistair Grant <akgrant0710@gmail.com> wrote:
Hi Esteban,
On 16 December 2017 at 09:05, Esteban Lorenzano <estebanlm@gmail.com> wrote:
On 15 Dec 2017, at 17:37, Alistair Grant <akgrant0710@gmail.com> wrote:
Hi Esteban,
I had no problems following the process (Ubuntu 16.04, Pharo7.0-32bit-e175bc2.image, fogbugz 20872). :-)
I guess that you have already thought of this, but... Is there any reason why we can't just put up a dialog asking for the user's github credentials and fogbugz issue number and then automatically clone the repository, configure the upstream remote and create the issue branch. That would remove most of the remaining manual steps.
I realise that it only works for option 1, although where people configure a common pharo-local, it could check for a pre-existing clone and use that one.
"I realiseâ means you tried and it didnât work? because in my tests it worked as good as the first one (I tested on windows), but that may need to be âre-validatedâ :)
Esteban
The contribution process works fine (even on linux :-)).
The "I realise" paragraph is a comment on my suggestion to try and reduce the number of manual steps required (and is actually wrong). Just to rephrase (and extend) the suggestion, I think we could create a single dialog that currently covers the following steps (from your instructions):
1. Clone a fresh repository, or point to an existing repository. 2. Tell Iceberg about pharo-project 3. Create a new branch from the fogbugz issue
ah, I got lost in translation ;)
Esteban
Cheers, Alistair
Cheers, Alistair
On 14 December 2017 at 13:19, Esteban Lorenzano <estebanlm@gmail.com> 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 16 Dec 2017, at 17:24, Stephane Ducasse <stepharo.self@gmail.com> wrote:
OK so I restarted everything from scratch: - deleted my fork - reforked - clone pharo again - here is some feedback
In the tutorial add /pharo + src in the screenshot
Then when I add the local repository I get uncommited changes and I do not understand why?
this is also a bug (or something I still do not fully understand why it happens). This needs to be corrected with the new UI Esteban
On Sat, Dec 16, 2017 at 9:57 AM, Esteban Lorenzano <estebanlm@gmail.com> wrote:
On 16 Dec 2017, at 09:42, Alistair Grant <akgrant0710@gmail.com> wrote:
Hi Esteban,
On 16 December 2017 at 09:05, Esteban Lorenzano <estebanlm@gmail.com> wrote:
On 15 Dec 2017, at 17:37, Alistair Grant <akgrant0710@gmail.com> wrote:
Hi Esteban,
I had no problems following the process (Ubuntu 16.04, Pharo7.0-32bit-e175bc2.image, fogbugz 20872). :-)
I guess that you have already thought of this, but... Is there any reason why we can't just put up a dialog asking for the user's github credentials and fogbugz issue number and then automatically clone the repository, configure the upstream remote and create the issue branch. That would remove most of the remaining manual steps.
I realise that it only works for option 1, although where people configure a common pharo-local, it could check for a pre-existing clone and use that one.
"I realiseâ means you tried and it didnât work? because in my tests it worked as good as the first one (I tested on windows), but that may need to be âre-validatedâ :)
Esteban
The contribution process works fine (even on linux :-)).
The "I realise" paragraph is a comment on my suggestion to try and reduce the number of manual steps required (and is actually wrong). Just to rephrase (and extend) the suggestion, I think we could create a single dialog that currently covers the following steps (from your instructions):
1. Clone a fresh repository, or point to an existing repository. 2. Tell Iceberg about pharo-project 3. Create a new branch from the fogbugz issue
ah, I got lost in translation ;)
Esteban
Cheers, Alistair
Cheers, Alistair
On 14 December 2017 at 13:19, Esteban Lorenzano <estebanlm@gmail.com> 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
<Screen Shot 2017-12-16 at 17.23.53.png>
Cumbersome was not the first adjective that came to me mind :) but you know it :) On Thu, Dec 14, 2017 at 1:19 PM, Esteban Lorenzano <estebanlm@gmail.com> 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 14 December 2017 at 20:19, Esteban Lorenzano <estebanlm@gmail.com> 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
Using https://github.com/pharo-project/pharo/wiki/Contribute-a-fix-to-Pharo with my pharo branch "22 commits behind pharo-project:master" https://github.com/bencoman/pharo/tree/master
From PharoLauncher, I created fresh latest image from Pharo-7.0.0-alpha.build.408.sha.5369e34.arch.64bit (btw, download took about 30 seconds which was reasonably good) Opened image WorldMenu > Iceberg Iceberg > Clone Repository Remote URL = git@github.com:bencoman/pharo.git Local Directory (default) = /home/ben/Pharo/images/FastTable-Pharo-7.0.0-alpha.build.402.sha.d5d4c99.arch.64bit-01/pharo-local/iceberg Code subdirectory = src <Create Repository>
A bit disconcerting that for about 1.5 minutes the UI is frozen, but eventually "pharo" entry appears in IceBerg with... Name = *pharo Current branch = master Loaded version = fc92bbe (7 July 2017) Status = uncommitted changes Right-clicked on *pharo > Synchronise repository up popped dialog "Synchronising" on tab [Commit your changes] with about 800 changes with all items ticked. (btw, I clicked <Refresh Tree> all the changes are unticked, and only the three toplevel items GT-Spotter, Kernel & Reflectivity are ticked. Is that ideal? What is the typical use case of that button. Anyway, I close the dialog, and again right-click on *pharo > Synchronise repository) (btw, reviewing change here is nice.) A bit disconcerting that buttons <Commit onto master> and <Commit and push onto master> are both disabled so there is no action I can do from this default, so I proceed to [Push] tab. I'm feel unsure whether there should be some item listed under "New local commits to be published" (there are none) but pushing <Publish all> seems the only thing possible, so I do that. That seems to complete after 10 seconds, but still status = "Uncommitted changes" in the main Iceberg window. Opening a new IceBerg window shows the same thing. So what more do I need to do to get my Pharo repo "Up to date" ? cheers -ben
On 5 January 2018 at 14:56, Ben Coman <btc@openinworld.com> wrote:
On 14 December 2017 at 20:19, Esteban Lorenzano <estebanlm@gmail.com> 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
Using https://github.com/pharo-project/pharo/wiki/ Contribute-a-fix-to-Pharo with my pharo branch "22 commits behind pharo-project:master" https://github.com/bencoman/pharo/tree/master
<snip>
A bit disconcerting that buttons <Commit onto master> and <Commit and push onto master> are both disabled so there is no action I can do from this default, so I proceed to [Push] tab.
Thanks to Esteban's help, I learnt that you have to enter a commit message before the buttons are enabled (duh me!) Now given the Iceberg trouble with Ubuntu 64bit, I reverted to 32 bit and followed the wiki Contribute-a-fix-to-Pharo as closely as I could... $ mkdir -p ~/dev/Pharo/Contribute && cd ~/dev/Pharo/Contribute $ wget -O- get.pharo.org/70+vm | bash $ ./pharo-ui Pharo.image On github, I deleted my existing fork and reforked from pharo-project/pharo. My SSH keys were previously set up... $ ls -1 ~/.ssh id_rsa id_rsa.pub known_hosts $ $ ssh -T git@github.com Hi bencoman! You've successfully authenticated, but GitHub does not provide shell access. In Pharo... World menu > Iceberg > Clone Repository Remote URL = git@github.com:bencoman/pharo.git Local Directory (default) = /home/ben/dev/Pharo/Contribute/pharo-local/iceberg Code subdirectory = src Clicked <Create Repository> Interesting that the created row "pharo" repository now defaults to the "development" branch. Previously it was defaulting to the "master" branch and part of my difficulty was trying to get onto the "up to date" development branch. This pharo "development" branch status has "uncommitted changes" so right-clicked "pharo" > Synchronise repository. The dialog that came up shows an empty "Local changes" tab. Because it didn't feel right to create a commit for empty changes, I was momentarily confused by this since this dialog covered the parent window where the repo status had changed to "up to date". Yay! [btw, Would it be possible (i.e. make sense) to avoid bringing up this dialog when there are empty changes and just display an #inform: message "No changes" ?] Clicked on [Remotes] tab > Add remote Remote name = pharo-project Remote url = git@github.com:pharo-project/pharo.git Right clicked "pharo" > Pharo > Create new branch from Fogbugz issue... 20937 clicked <Create> Great! the main Iceberg window shows I've changed to that branch and its up to date. Made some changes. Right clicked on "pharo" > Synchronise... Entered commit comment and clicked <Commit onto 20937...> Clicked on [Push] tab > Publish all Github shows my commit. Yay! I can see it here... https://github.com/bencoman/pharo/network Now this is not complete but at the point where I'm seeking advise on how to approach the next step. Following the philosophy that PRs are not just for finished code but a good way to seek collaboration, back in Pharo... rightclicked on "pharo > Github > Create pull request... entered username & password The dialog defaults for "New pull request" looked okay, so clicked <Create a pull request> And I can see my PR here... https://github.com/pharo-project/pharo/pull/657 Yay! Finally cracked it. The start of my first Pharo 7 contribution. I very much like this new workflow. thx esteban. A couple of things would make it even smoother. a. An option to save details of my personal fork to auto-fill the Create Repository dialog fields in a fresh image anywhere on my system. b. An menu item or button to auto-fill the pharo-project remote. Now hopefully someone familiar with FastTable can review my PR and discuss options to implement the next step for horizontal scrolling. cheers -ben
Hi Ben, On 8 January 2018 at 17:34, Ben Coman <btc@openinworld.com> wrote:
[ snip ]
A couple of things would make it even smoother. a. An option to save details of my personal fork to auto-fill the Create Repository dialog fields in a fresh image anywhere on my system. b. An menu item or button to auto-fill the pharo-project remote.
This is the script I used last time to reduce the number of manual steps. I haven't had a chance to validate it properly, but hopefully it will help. Run this in a clean image... | username pharoRepository | Author fullName: '<YourName>'. username := '<YourGitUsername>'. pharoRepository := (IceRepositoryCreator new remote: (IceRemote url: 'git@github.com:', username, '/pharo.git'); subdirectory: 'src'; createRepository) register. pharoRepository addRemote: (IceRemote name: 'pharo-project' url: 'git@github.com:pharo-project/pharo.git'). (IcePharoCreateBranchFromIssue on: pharoRepository) execute. 'Loaded pharo-core' inspect.
Now hopefully someone familiar with FastTable can review my PR and discuss options to implement the next step for horizontal scrolling.
cheers -ben
On 8 Jan 2018, at 17:57, Alistair Grant <akgrant0710@gmail.com> wrote:
Hi Ben,
On 8 January 2018 at 17:34, Ben Coman <btc@openinworld.com> wrote:
[ snip ]
A couple of things would make it even smoother. a. An option to save details of my personal fork to auto-fill the Create Repository dialog fields in a fresh image anywhere on my system. b. An menu item or button to auto-fill the pharo-project remote.
this is done usually through startup actions. for example, I have: StartupPreferencesLoader default executeAtomicItems: { StartupAction name: 'Iceberg' code: [ Iceberg enableMetacelloIntegration: true. IceRepository shareRepositoriesBetweenImages: true; sharedRepositoriesLocationString: '/Users/esteban/Dev/Repository'. (IceRepositoryCreator new location: '/Users/esteban/Dev/Repository/pharo-project/pharo' asFileReference; subdirectory: 'src'; createRepository) register ] runOnce: true. }. (you put that in an âiceberg.st <http://iceberg.st/>â in /Users/esteban/Library/Preferences/pharo/7.0 (or the equivalent for your platform, that you can find executing FileLocator preferences fullName) Esteban
This is the script I used last time to reduce the number of manual steps. I haven't had a chance to validate it properly, but hopefully it will help. Run this in a clean imageâ¦
| username pharoRepository |
Author fullName: '<YourName>'.
username := '<YourGitUsername>'.
pharoRepository := (IceRepositoryCreator new remote: (IceRemote url: 'git@github.com:', username, '/pharo.git'); subdirectory: 'src'; createRepository) register. pharoRepository addRemote: (IceRemote name: 'pharo-project' url: 'git@github.com:pharo-project/pharo.git'). (IcePharoCreateBranchFromIssue on: pharoRepository) execute.
'Loaded pharo-core' inspect.
Now hopefully someone familiar with FastTable can review my PR and discuss options to implement the next step for horizontal scrolling.
cheers -ben
EstebanLM wrote
PLEASE, PLEASE, PLEASE⦠take a moment to read and try the document.
I added my local pharo fork clone and got the red Morphic square of death in Iceberg. Closing and restarting Iceberg failed with: "LGit_GIT_ENOTFOUND: Object not found - no match for id (b98b37b641381ac07906c020bbc8b4675ed4027b)" Image ----- Pharo7.0alpha Build information: Pharo-7.0+alpha.build.414.sha.53eba9479e615417df06b782fc663e9a9407a404 (32 Bit) Unnamed Virtual Machine --------------- ~/Documents/Pharo/vms/70-x86/Pharo.app/Contents/MacOS/Pharo CoInterpreter VMMaker.oscog-eem.2265 uuid: 76b62109-629a-4c39-9641-67b53321df9a Aug 27 2017 StackToRegisterMappingCogit VMMaker.oscog-eem.2262 uuid: 8b531242-de02-48aa-b418-8d2dde0bec6c Aug 27 2017 VM: 201708271955 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ Date: Sun Aug 27 21:55:26 2017 +0200 $ Plugins: 201708271955 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ Mac OS X built on Aug 27 2017 20:27:09 UTC Compiler: 4.2.1 Compatible Apple LLVM 6.1.0 (clang-602.0.53) VMMaker versionString VM: 201708271955 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ Date: Sun Aug 27 21:55:26 2017 +0200 $ Plugins: 201708271955 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ CoInterpreter VMMaker.oscog-eem.2265 uuid: 76b62109-629a-4c39-9641-67b53321df9a Aug 27 2017 StackToRegisterMappingCogit VMMaker.oscog-eem.2262 uuid: 8b531242-de02-48aa-b418-8d2dde0bec6c Aug 27 2017 Operating System/Hardware ------------------------- Mac OS 1013.2 intel ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
Hi Sean, On 9 January 2018 at 05:00, Sean P. DeNigris <sean@clipperadams.com> wrote:
EstebanLM wrote
PLEASE, PLEASE, PLEASE⦠take a moment to read and try the document.
I added my local pharo fork clone and got the red Morphic square of death in Iceberg. Closing and restarting Iceberg failed with: "LGit_GIT_ENOTFOUND: Object not found - no match for id (b98b37b641381ac07906c020bbc8b4675ed4027b)"
I'm getting the LGit_GIT_ENOTFOUND when I load a clean image. The id appears to be the commit id from a different repository (in my case it happens to be the repository directly under the one with the error). I haven't looked in to this further yet, but the short term workaround is to reload all the packages in the repository with the error. Cheers, Alistair
Image ----- Pharo7.0alpha Build information: Pharo-7.0+alpha.build.414.sha.53eba9479e615417df06b782fc663e9a9407a404 (32 Bit) Unnamed
Virtual Machine --------------- ~/Documents/Pharo/vms/70-x86/Pharo.app/Contents/MacOS/Pharo CoInterpreter VMMaker.oscog-eem.2265 uuid: 76b62109-629a-4c39-9641-67b53321df9a Aug 27 2017 StackToRegisterMappingCogit VMMaker.oscog-eem.2262 uuid: 8b531242-de02-48aa-b418-8d2dde0bec6c Aug 27 2017 VM: 201708271955 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ Date: Sun Aug 27 21:55:26 2017 +0200 $ Plugins: 201708271955 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $
Mac OS X built on Aug 27 2017 20:27:09 UTC Compiler: 4.2.1 Compatible Apple LLVM 6.1.0 (clang-602.0.53) VMMaker versionString VM: 201708271955 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ Date: Sun Aug 27 21:55:26 2017 +0200 $ Plugins: 201708271955 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ CoInterpreter VMMaker.oscog-eem.2265 uuid: 76b62109-629a-4c39-9641-67b53321df9a Aug 27 2017 StackToRegisterMappingCogit VMMaker.oscog-eem.2262 uuid: 8b531242-de02-48aa-b418-8d2dde0bec6c Aug 27 2017
Operating System/Hardware ------------------------- Mac OS 1013.2 intel
----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
On 9 Jan 2018, at 08:22, Alistair Grant <akgrant0710@gmail.com> wrote:
Hi Sean,
On 9 January 2018 at 05:00, Sean P. DeNigris <sean@clipperadams.com> wrote:
EstebanLM wrote
PLEASE, PLEASE, PLEASE⦠take a moment to read and try the document.
I added my local pharo fork clone and got the red Morphic square of death in Iceberg. Closing and restarting Iceberg failed with: "LGit_GIT_ENOTFOUND: Object not found - no match for id (b98b37b641381ac07906c020bbc8b4675ed4027b)"
I'm getting the LGit_GIT_ENOTFOUND when I load a clean image. The id appears to be the commit id from a different repository (in my case it happens to be the repository directly under the one with the error).
Mmm. I think this is because your local clone is outdated. It should be fixed with a fetch. Esteban
I haven't looked in to this further yet, but the short term workaround is to reload all the packages in the repository with the error.
Cheers, Alistair
Image ----- Pharo7.0alpha Build information: Pharo-7.0+alpha.build.414.sha.53eba9479e615417df06b782fc663e9a9407a404 (32 Bit) Unnamed
Virtual Machine --------------- ~/Documents/Pharo/vms/70-x86/Pharo.app/Contents/MacOS/Pharo CoInterpreter VMMaker.oscog-eem.2265 uuid: 76b62109-629a-4c39-9641-67b53321df9a Aug 27 2017 StackToRegisterMappingCogit VMMaker.oscog-eem.2262 uuid: 8b531242-de02-48aa-b418-8d2dde0bec6c Aug 27 2017 VM: 201708271955 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ Date: Sun Aug 27 21:55:26 2017 +0200 $ Plugins: 201708271955 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $
Mac OS X built on Aug 27 2017 20:27:09 UTC Compiler: 4.2.1 Compatible Apple LLVM 6.1.0 (clang-602.0.53) VMMaker versionString VM: 201708271955 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ Date: Sun Aug 27 21:55:26 2017 +0200 $ Plugins: 201708271955 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ CoInterpreter VMMaker.oscog-eem.2265 uuid: 76b62109-629a-4c39-9641-67b53321df9a Aug 27 2017 StackToRegisterMappingCogit VMMaker.oscog-eem.2262 uuid: 8b531242-de02-48aa-b418-8d2dde0bec6c Aug 27 2017
Operating System/Hardware ------------------------- Mac OS 1013.2 intel
----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
On 9 Jan 2018, at 09:30, Esteban Lorenzano <estebanlm@gmail.com> wrote:
On 9 Jan 2018, at 08:22, Alistair Grant <akgrant0710@gmail.com> wrote:
Hi Sean,
On 9 January 2018 at 05:00, Sean P. DeNigris <sean@clipperadams.com> wrote:
EstebanLM wrote
PLEASE, PLEASE, PLEASE⦠take a moment to read and try the document.
I added my local pharo fork clone and got the red Morphic square of death in Iceberg. Closing and restarting Iceberg failed with: "LGit_GIT_ENOTFOUND: Object not found - no match for id (b98b37b641381ac07906c020bbc8b4675ed4027b)"
I'm getting the LGit_GIT_ENOTFOUND when I load a clean image. The id appears to be the commit id from a different repository (in my case it happens to be the repository directly under the one with the error).
Mmm. I think this is because your local clone is outdated. It should be fixed with a fetch.
a fetch from pharo-project, I mean :)
Esteban
I haven't looked in to this further yet, but the short term workaround is to reload all the packages in the repository with the error.
Cheers, Alistair
Image ----- Pharo7.0alpha Build information: Pharo-7.0+alpha.build.414.sha.53eba9479e615417df06b782fc663e9a9407a404 (32 Bit) Unnamed
Virtual Machine --------------- ~/Documents/Pharo/vms/70-x86/Pharo.app/Contents/MacOS/Pharo CoInterpreter VMMaker.oscog-eem.2265 uuid: 76b62109-629a-4c39-9641-67b53321df9a Aug 27 2017 StackToRegisterMappingCogit VMMaker.oscog-eem.2262 uuid: 8b531242-de02-48aa-b418-8d2dde0bec6c Aug 27 2017 VM: 201708271955 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ Date: Sun Aug 27 21:55:26 2017 +0200 $ Plugins: 201708271955 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $
Mac OS X built on Aug 27 2017 20:27:09 UTC Compiler: 4.2.1 Compatible Apple LLVM 6.1.0 (clang-602.0.53) VMMaker versionString VM: 201708271955 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ Date: Sun Aug 27 21:55:26 2017 +0200 $ Plugins: 201708271955 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ CoInterpreter VMMaker.oscog-eem.2265 uuid: 76b62109-629a-4c39-9641-67b53321df9a Aug 27 2017 StackToRegisterMappingCogit VMMaker.oscog-eem.2262 uuid: 8b531242-de02-48aa-b418-8d2dde0bec6c Aug 27 2017
Operating System/Hardware ------------------------- Mac OS 1013.2 intel
----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
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
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 <sean@clipperadams.com> 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
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 (tinchodias@gmail.com) 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 <sean@clipperadams.com> 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 07:15, Max Leske <maxleske@gmail.com> 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
yep, thatâs pretty much the process in that case :)
The rest you know, I guess ;)
Cheers, Max
On 16 January 2018 at 20:16:22, Martin Dias (tinchodias@gmail.com <mailto:tinchodias@gmail.com>) 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 <sean@clipperadams.com <mailto:sean@clipperadams.com>> 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 <http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html>
Hi 2018-01-17 7:15 GMT+01:00 Max Leske <maxleske@gmail.com>:
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 (tinchodias@gmail.com) 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 <sean@clipperadams.com> 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
Hi,
On 17 Jan 2018, at 11:45, Denis Kudriashov <dionisiydk@gmail.com> wrote:
Hi
2018-01-17 7:15 GMT+01:00 Max Leske <maxleske@gmail.com <mailto:maxleske@gmail.com>>: 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.
Epicea is also integrated on Pharo, and as Fuel or GT, they are managed outside. So, what you do is: - load new version of Epicea (that will be apply the changes) using a regular baseline or configuration of package by package, from Martinâs repository. - you add and remove new/removed packages AND you modify BaselineOfIDE (or the one where Epicea is declared) than you are ok to use âSync full changesâ as Max said. cheers, Esteban
The rest you know, I guess ;)
Cheers, Max
On 16 January 2018 at 20:16:22, Martin Dias (tinchodias@gmail.com <mailto:tinchodias@gmail.com>) 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 <sean@clipperadams.com <mailto:sean@clipperadams.com>> 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 <http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html>
Hi Esteban, On 9 January 2018 at 09:30, Esteban Lorenzano <estebanlm@gmail.com> wrote:
On 9 Jan 2018, at 08:22, Alistair Grant <akgrant0710@gmail.com> wrote:
Hi Sean,
On 9 January 2018 at 05:00, Sean P. DeNigris <sean@clipperadams.com> wrote:
EstebanLM wrote
PLEASE, PLEASE, PLEASE⦠take a moment to read and try the document.
I added my local pharo fork clone and got the red Morphic square of death in Iceberg. Closing and restarting Iceberg failed with: "LGit_GIT_ENOTFOUND: Object not found - no match for id (b98b37b641381ac07906c020bbc8b4675ed4027b)"
I'm getting the LGit_GIT_ENOTFOUND when I load a clean image. The id appears to be the commit id from a different repository (in my case it happens to be the repository directly under the one with the error).
Mmm. I think this is because your local clone is outdated. It should be fixed with a fetch.
Esteban
In my case it's because I have one package stored in two repositories. Oops. When the IceLoadedCode>>computeReferenceCommit is called it eventually calls MCWorkingCopy class>>forPackage: which then finds the package in the registry, but gets the package from the other repository. Cheers, Alistair
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 <estebanlm@gmail.com> 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
Max, Esteban, Denis: Thanks! it worked: https://github.com/pharo- project/pharo/pull/690 I didn't have to add or remove packages as in step 5, but I did have to 'Synchronize full repository' as in step 6. Luke, this is offtopic, but here is a brief guide to use epicea after you lost changes: 1. reopen the image and select "Code Changes" from the world menu > tools. 2. click on left side items: they are change log files. 3. look at the logged changes on right side: the most recent ones are on top. 4. you can select a single or multiple changes, right click and "apply". Also there is a button "Filters" with options that can help you to remove from the view changes you don't want to see. BTW, the "apply" of multiple changes will work better after the PR is merged. MartÃn On Wed, Jan 17, 2018 at 8:20 AM, Luke Gorrie <luke@snabb.co> 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 <estebanlm@gmail.com> 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
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 <luke@snabb.co> 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 <estebanlm@gmail.com> 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
hi :)
On 18 Jan 2018, at 18:39, Stephane Ducasse <stepharo.self@gmail.com> 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 :)
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 <luke@snabb.co> 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 <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 <estebanlm@gmail.com> 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
Is there a summary what and why the model changed? Iâm really interested as you know. And I can tell that there are still things very fishy in the whole process. Norbert
Am 19.01.2018 um 08:39 schrieb Esteban Lorenzano <estebanlm@gmail.com>:
hi :)
On 18 Jan 2018, at 18:39, Stephane Ducasse <stepharo.self@gmail.com <mailto:stepharo.self@gmail.com>> 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 :)
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 <luke@snabb.co <mailto:luke@snabb.co>> 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 <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 <estebanlm@gmail.com <mailto:estebanlm@gmail.com>> 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 <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
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 10:17, Luke Gorrie <luke@snabb.co> 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.*
because you are mixing âcontribute to pharoâ with âbuilding the VM in another platformâ :) the image itself (hence, the pharo process) does not has anything to do with using NixOS as target platform. In this last effort (that I salute), you are basically by your own⦠nevertheless, I have to point: - there are proper source for the VM: https://github.com/OpenSmalltalk/opensmalltalk-vm <https://github.com/OpenSmalltalk/opensmalltalk-vm> (releases is another point, but you can take the Cog branch as âstableâ. This has all sources you need to compile the VM. I have no idea how packaging for NixOS works, but I guess you can adapt from there. - once VM is built, the Pharo image will run⦠you do not have to build an image for being able to use it. Now, if you want to do it, here: https://github.com/pharo-project/pharo <https://github.com/pharo-project/pharo> are âproperâ Pharo sources along with the way to bootstrap. We are doing that in linux and macOS every day, so is a proven script that works. Again no idea how to do it on NixOS, but again, no idea why you care. - once you have all that working, for *your own sources*: use monticello or iceberg, the one you prefer. - for contribute to pharo, follow the process pointed. cheers! Esteban ps: but all you describe as problematic has *nothing* to do with pharo process but with your building of the VM (and probably the image) in macOS.
Thanks Esteban. It's a relief to know that eveything is my fault. Have a nice life... On 19 January 2018 at 10:28, Esteban Lorenzano <estebanlm@gmail.com> wrote:
On 19 Jan 2018, at 10:17, Luke Gorrie <luke@snabb.co> 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.*
because you are mixing âcontribute to pharoâ with âbuilding the VM in another platformâ :) the image itself (hence, the pharo process) does not has anything to do with using NixOS as target platform. In this last effort (that I salute), you are basically by your own⦠nevertheless, I have to point:
- there are proper source for the VM: https://github.com/ OpenSmalltalk/opensmalltalk-vm (releases is another point, but you can take the Cog branch as âstableâ. This has all sources you need to compile the VM. I have no idea how packaging for NixOS works, but I guess you can adapt from there. - once VM is built, the Pharo image will run⦠you do not have to build an image for being able to use it. Now, if you want to do it, here: https://github.com/pharo-project/pharo are âproperâ Pharo sources along with the way to bootstrap. We are doing that in linux and macOS every day, so is a proven script that works. Again no idea how to do it on NixOS, but again, no idea why you care. - once you have all that working, for *your own sources*: use monticello or iceberg, the one you prefer. - for contribute to pharo, follow the process pointed.
cheers! Esteban
ps: but all you describe as problematic has *nothing* to do with pharo process but with your building of the VM (and probably the image) in macOS.
Hi Luke, On 19 January 2018 at 10:39, Luke Gorrie <luke@snabb.co> wrote:
Thanks Esteban. It's a relief to know that eveything is my fault.
Have a nice life...
I think you're reading this more negatively than intended. Esteban's point was that when he refers to the pharo contribution process he only means contributing to the image, and that there's no formal (Pharo) process for the VM (there is the vm-dev mailing list, of course). Cheers, Alistair
On 19 January 2018 at 10:28, Esteban Lorenzano <estebanlm@gmail.com> wrote:
On 19 Jan 2018, at 10:17, Luke Gorrie <luke@snabb.co> 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.*
because you are mixing âcontribute to pharoâ with âbuilding the VM in another platformâ :) the image itself (hence, the pharo process) does not has anything to do with using NixOS as target platform. In this last effort (that I salute), you are basically by your own⦠nevertheless, I have to point:
- there are proper source for the VM: https://github.com/OpenSmalltalk/opensmalltalk-vm (releases is another point, but you can take the Cog branch as âstableâ. This has all sources you need to compile the VM. I have no idea how packaging for NixOS works, but I guess you can adapt from there. - once VM is built, the Pharo image will run⦠you do not have to build an image for being able to use it. Now, if you want to do it, here: https://github.com/pharo-project/pharo are âproperâ Pharo sources along with the way to bootstrap. We are doing that in linux and macOS every day, so is a proven script that works. Again no idea how to do it on NixOS, but again, no idea why you care. - once you have all that working, for *your own sources*: use monticello or iceberg, the one you prefer. - for contribute to pharo, follow the process pointed.
cheers! Esteban
ps: but all you describe as problematic has *nothing* to do with pharo process but with your building of the VM (and probably the image) in macOS.
On 19 Jan 2018, at 10:53, Alistair Grant <akgrant0710@gmail.com> wrote:
Hi Luke,
On 19 January 2018 at 10:39, Luke Gorrie <luke@snabb.co> wrote:
Thanks Esteban. It's a relief to know that eveything is my fault.
Have a nice life...
I think you're reading this more negatively than intended.
Esteban's point was that when he refers to the pharo contribution process he only means contributing to the image, and that there's no formal (Pharo) process for the VM (there is the vm-dev mailing list, of course).
:( I do not understand where I say it was your fault. As Alistair said, I was pointing you are talking about something that may be problematic, but is not part of the regular pharo process. then I pointed you to the official vm sources and the official pharo sources (different things) both of them with instructions that work on how to build (but not on NixOS, but as you said, currently is not a supported platform). So, as I said⦠your problems are *not* related to the contribution to pharo but to the particularities of what you are doing. the mail where you are are answering was about contributing changes to pharo, hence not related to your problems. I remain: process to contribute to pharo is not the point of problem here. And figure out where the problems come from is the first step to fix them (and again, I *pointed* where your problems come, according your description: the VM building). Esteban
Cheers, Alistair
On 19 January 2018 at 10:28, Esteban Lorenzano <estebanlm@gmail.com> wrote:
On 19 Jan 2018, at 10:17, Luke Gorrie <luke@snabb.co> 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.*
because you are mixing âcontribute to pharoâ with âbuilding the VM in another platformâ :) the image itself (hence, the pharo process) does not has anything to do with using NixOS as target platform. In this last effort (that I salute), you are basically by your own⦠nevertheless, I have to point:
- there are proper source for the VM: https://github.com/OpenSmalltalk/opensmalltalk-vm (releases is another point, but you can take the Cog branch as âstableâ. This has all sources you need to compile the VM. I have no idea how packaging for NixOS works, but I guess you can adapt from there. - once VM is built, the Pharo image will run⦠you do not have to build an image for being able to use it. Now, if you want to do it, here: https://github.com/pharo-project/pharo are âproperâ Pharo sources along with the way to bootstrap. We are doing that in linux and macOS every day, so is a proven script that works. Again no idea how to do it on NixOS, but again, no idea why you care. - once you have all that working, for *your own sources*: use monticello or iceberg, the one you prefer. - for contribute to pharo, follow the process pointed.
cheers! Esteban
ps: but all you describe as problematic has *nothing* to do with pharo process but with your building of the VM (and probably the image) in macOS.
Hi Luke, On 19 January 2018 at 10:17, Luke Gorrie <luke@snabb.co> 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,
Are you building 32 or 64 bit VMs? My experience has been that 64 bit VMs on linux have problems with libgit2. If you can use 32 bit VMs for now you might get better stability. I'm currently running: 5.0-201801110739 Thursday 11 January 09:30:12 CET 2018 gcc 4.8.5 [Production Spur VM] CoInterpreter VMMaker.oscog-eem.2302 uuid: 55ec8f63-cdbe-4e79-8f22-48fdea585b88 Jan 11 2018 StackToRegisterMappingCogit VMMaker.oscog-eem.2302 uuid: 55ec8f63-cdbe-4e79-8f22-48fdea585b88 Jan 11 2018 VM: 201801110739 alistair@alistair-xps13:snap/pharo-snap/pharo-vm/opensmalltalk-vm $ Date: Wed Jan 10 23:39:30 2018 -0800 $ Plugins: 201801110739 alistair@alistair-xps13:snap/pharo-snap/pharo-vm/opensmalltalk-vm $ Linux b07d7880072c 4.13.0-26-generic #29~16.04.2-Ubuntu SMP Tue Jan 9 22:00:44 UTC 2018 i686 i686 i686 GNU/Linux plugin path: /snap/core/3748/lib/i386-linux-gnu/ [default: /snap/core/3748/lib/i386-linux-gnu/] without any problems. I've tried looking at the libgit2 issue in a debug vm, but (with my meagre skills): - the memory corruption isn't consistent, i.e. the crash occurs in different places on multiple runs - the crash doesn't occur until sometime after the corruption :-( HTH, Alistair
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.*
Luke Gorrie <luke@snabb.co> wrote:
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.
Isn't nix supported by travis? I suppose that means that you should be able to automatically build a variant of opensmalltalk I have absolutely no idea how much work that would be though. Stephan
On Fri, Jan 19, 2018 at 8:39 AM, Esteban Lorenzano <estebanlm@gmail.com> wrote:
hi :)
On 18 Jan 2018, at 18:39, Stephane Ducasse <stepharo.self@gmail.com> 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 <luke@snabb.co> 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 <estebanlm@gmail.com> 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 13:00, Stephane Ducasse <stepharo.self@gmail.com> wrote:
On Fri, Jan 19, 2018 at 8:39 AM, Esteban Lorenzano <estebanlm@gmail.com <mailto:estebanlm@gmail.com>> wrote:
hi :)
On 18 Jan 2018, at 18:39, Stephane Ducasse <stepharo.self@gmail.com> 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.
I know.
If we do not try something else we will not have feedback.
Iâm working on simplifying/fixing the UI. But is a permanent work, not something that can be done in short time :( Esteban
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 <luke@snabb.co> 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 <estebanlm@gmail.com> 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
2018-01-19 8:39 GMT+01:00 Esteban Lorenzano <estebanlm@gmail.com>:
hi :)
On 18 Jan 2018, at 18:39, Stephane Ducasse <stepharo.self@gmail.com> 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 ;) )
I use github desktop and I am very like it. But also I do not have problems with Iceberg process (if not count bugs)
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 :)
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 <luke@snabb.co> 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 <estebanlm@gmail.com> 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
participants (13)
-
Alistair Grant -
Ben Coman -
Denis Kudriashov -
Esteban Lorenzano -
Luke Gorrie -
Marcus Denker -
Martin Dias -
Max Leske -
Norbert Hartl -
Pavel Krivanek -
Sean P. DeNigris -
Stephan Eggermont -
Stephane Ducasse