In the tutorial:

- Put a little heading before

"You need to add pharo repository as a remote
([email protected]:pharo-project/pharo.git)."

On Sat, Dec 16, 2017 at 5:25 PM, Stephane Ducasse
<[email protected]> 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
> <[email protected]> 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 <[email protected]> 
>> wrote:
>>>
>>>
>>> On 16 Dec 2017, at 09:42, Alistair Grant <[email protected]> wrote:
>>>
>>> Hi Esteban,
>>>
>>> On 16 December 2017 at 09:05, Esteban Lorenzano <[email protected]> wrote:
>>>
>>>
>>>
>>> On 15 Dec 2017, at 17:37, Alistair Grant <[email protected]> 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 <[email protected]> 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
>>>
>>>

Reply via email to