Smalltalk › Pharo › Pharo Smalltalk Developers

Contribution scheme confusing ...

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

11 messages Options

Torsten Bergmann

Contribution scheme confusing ...

We are in a transition to use more and more ConfigurationOfxxxx
to manage packages included in Pharo 5.

But neither the new help topic "How to contribute to Pharo base code"
nor the link it points to http://pharo.org/contribute-propose-fix reflects this.

Also - how do I know which code has to be managed by a Configuration
and where is the original repo if so.

How will I submit a fix that includes code to change both: somthing that is managed
vai config and something that is a change on a regular slice managed package...

Also:
I did a simple fix on NautilusGroupAutoBuilder package - there is
a ConfigurationOfNautilusGroupAutoBuilder. But is it managed internally
or externally now?

Thanks
T.

stepharo

Re: Contribution scheme confusing ...

Yes we know.
Now we are full.
Sorry I cannot clone ourselves. Else I would do it.
Stef

Le 16/9/15 22:17, Torsten Bergmann a écrit :

> We are in a transition to use more and more ConfigurationOfxxxx
> to manage packages included in Pharo 5.
>
> But neither the new help topic "How to contribute to Pharo base code"
> nor the link it points to http://pharo.org/contribute-propose-fix reflects this.
>
> Also - how do I know which code has to be managed by a Configuration
> and where is the original repo if so.
>
> How will I submit a fix that includes code to change both: somthing that is managed
> vai config and something that is a change on a regular slice managed package...
>
> Also:
> I did a simple fix on NautilusGroupAutoBuilder package - there is
> a ConfigurationOfNautilusGroupAutoBuilder. But is it managed internally
> or externally now?
>
> Thanks
> T.
>
>

Marcus Denker-4

Re: Contribution scheme confusing ...

In reply to this post by Torsten Bergmann

> On 16 Sep 2015, at 22:17, Torsten Bergmann <[hidden email]> wrote:
>
> We are in a transition to use more and more ConfigurationOfxxxx
> to manage packages included in Pharo 5.
>

Yes, and it is a mess.

> But neither the new help topic "How to contribute to Pharo base code"
> nor the link it points to http://pharo.org/contribute-propose-fix reflects this.
>

Yes, I will put it on my TODO to update it.

> Also - how do I know which code has to be managed by a Configuration
> and where is the original repo if so.
>
> How will I submit a fix that includes code to change both: somthing that is managed
> vai config and something that is a change on a regular slice managed package...
>
> Also:
> I did a simple fix on NautilusGroupAutoBuilder package - there is
> a ConfigurationOfNautilusGroupAutoBuilder. But is it managed internally
> or externally now?
>

Even I can not tell you.

Marcus

Marcus Denker-4

Re: Contribution scheme confusing ...

>>
>> Also:
>> I did a simple fix on NautilusGroupAutoBuilder package - there is
>> a ConfigurationOfNautilusGroupAutoBuilder. But is it managed internally
>> or externally now?
>>
> Even I can not tell you.
>

I think the rule we should adopt: if there is a dedicated repository defined in the image for a package, people should commit
there. If there is non (just the inbox), then this should be used (with the Slice mechanism).

The repositories in the image should be already up to date, I think.

Marcus

Tudor Girba-2

Re: Contribution scheme confusing ...

Exactly!

This is the cheapest way to document the process. We could even try to automatically remove the inbox if there is another repository associated with a package. What do you think?

Cheers,

Doru

On Thu, Sep 17, 2015 at 3:40 PM, Marcus Denker <[hidden email]> wrote:

>>
>> Also:
>> I did a simple fix on NautilusGroupAutoBuilder package - there is
>> a ConfigurationOfNautilusGroupAutoBuilder. But is it managed internally
>> or externally now?
>>
> Even I can not tell you.
>

I think the rule we should adopt: if there is a dedicated repository defined in the image for a package, people should commit
there. If there is non (just the inbox), then this should be used (with the Slice mechanism).

The repositories in the image should be already up to date, I think.

Marcus

www.tudorgirba.com

"Every thing has its own flow"

Torsten Bergmann

Re: Contribution scheme confusing ...

In reply to this post by Marcus Denker-4

Hi Marcus,

Could work - but is a fragile rule. We should document it somewhere.

What about providing this info directly in the image. Alexandre has already added a help topic on how
to contribute (but yet only for the slice process).

I changed it so we can have the differences of config managed ones described as well and
we can list the configs there. See the attached changeset that you can file in into the latest
Pharo5.0 Latest update: #50329

File in and check "How to contribute to Pharo base code" topic in Help -> Help Browser

I guess this would be more clear to us and the users and we can simply point to
the help info is someone asks. And look up ourself when we forgot.

Thx
T.

> Gesendet: Donnerstag, 17. September 2015 um 15:40 Uhr
> Von: "Marcus Denker" <[hidden email]>
> An: "Pharo Development List" <[hidden email]>
> Betreff: Re: [Pharo-dev] Contribution scheme confusing ...
>
> >>
> >> Also:
> >> I did a simple fix on NautilusGroupAutoBuilder package - there is
> >> a ConfigurationOfNautilusGroupAutoBuilder. But is it managed internally
> >> or externally now?
> >>
> > Even I can not tell you.
> >
>
> I think the rule we should adopt: if there is a dedicated repository defined in the image for a package, people should commit
> there. If there is non (just the inbox), then this should be used (with the Slice mechanism).
>
> The repositories in the image should be already up to date, I think.
>
> Marcus
>
>
>

HowToContributeHelp class.TorstenBergmann.cs (2K) Download Attachment

Ben Coman

Re: Contribution scheme confusing ...

In reply to this post by Marcus Denker-4

On Thu, Sep 17, 2015 at 9:40 PM, Marcus Denker <[hidden email]> wrote:

>>>
>>> Also:
>>> I did a simple fix on NautilusGroupAutoBuilder package - there is
>>> a ConfigurationOfNautilusGroupAutoBuilder. But is it managed internally
>>> or externally now?
>>>
>> Even I can not tell you.
>>
>
> I think the rule we should adopt: if there is a dedicated repository defined in the image for a package, people should commit
> there. If there is non (just the inbox), then this should be used (with the Slice mechanism).
>
> The repositories in the image should be already up to date, I think.
>
> Marcus
>
>

How would the CI monkey work with Configurations from other repositories?

My workflow for reviewing a submitted fix (e.g. for issue 11111) is
to open the Pharo5Inbox repository and filter on the issue number,
which leaves the SLICE-Issue-11111 as the only item. Having to
discover where fixes are scattered makes it harder to review fixes,
and they will get less review Now if the Inbox contained
ConfigurationofXyz-Issue-11111, it would be simple to identify what
needs to be reviewed. This might even help the CI monkey to pick up
Configurations for testing.

btw, it would be cool if a package loaded by a Configuration becomes
dirty, then the Configuration also becomes dirty, or is otherwise
flagged somehow.

cheers -ben

Marcus Denker-4

Re: Contribution scheme confusing ...

>>
>> I think the rule we should adopt: if there is a dedicated repository defined in the image for a package, people should commit
>> there. If there is non (just the inbox), then this should be used (with the Slice mechanism).
>>
>> The repositories in the image should be already up to date, I think.
>>
>> Marcus
>>
>>
>
> How would the CI monkey work with Configurations from other repositories?
>

I does the check the same as for slices. (Which is great).

What is a bit harder is reviewing the changes. But as the idea of external packages is that
there is a maintainer, I actually just trust them: A configuration where the tests go trough
I integrate without looking at it, as that is the job of the maintainer that created the Config.

Marcus

EstebanLM

Re: Contribution scheme confusing ...

> On 19 Sep 2015, at 10:39, Marcus Denker <[hidden email]> wrote:
>
>
>>>
>>> I think the rule we should adopt: if there is a dedicated repository defined in the image for a package, people should commit
>>> there. If there is non (just the inbox), then this should be used (with the Slice mechanism).
>>>
>>> The repositories in the image should be already up to date, I think.
>>>
>>> Marcus
>>>
>>>
>>
>> How would the CI monkey work with Configurations from other repositories?
>>
> I does the check the same as for slices. (Which is great).

but the configuration needs to be copied into the inbox, of course :)

>
> What is a bit harder is reviewing the changes. But as the idea of external packages is that
> there is a maintainer, I actually just trust them: A configuration where the tests go trough
> I integrate without looking at it, as that is the job of the maintainer that created the Config.

exactly.
the idea is to have maintainers for configurations, then relieving a bit the work of the integrator.
that’s what happens with GTools, Zinc, etc.

Anyway… I want to do a “configuration diff” to be able to check what a new configuration will bring… is not so hard, but you know… time time time :)

what we are still struggling is with the best way to inform those changes. Because having a commit report that says “Update GTools”, does not says a lot about the bugs fixed upstream :)

Esteban

>
> Marcus

Marcus Denker-4

Re: Contribution scheme confusing ...

In reply to this post by Torsten Bergmann

Yes, this is good to put it in the image… I will update the website later, too.

can you make an issue?

> On 17 Sep 2015, at 17:35, Torsten Bergmann <[hidden email]> wrote:
>
> Hi Marcus,
>
> Could work - but is a fragile rule. We should document it somewhere.
>
> What about providing this info directly in the image. Alexandre has already added a help topic on how
> to contribute (but yet only for the slice process).
>
> I changed it so we can have the differences of config managed ones described as well and
> we can list the configs there. See the attached changeset that you can file in into the latest
> Pharo5.0 Latest update: #50329
>
> File in and check "How to contribute to Pharo base code" topic in Help -> Help Browser
>
> I guess this would be more clear to us and the users and we can simply point to
> the help info is someone asks. And look up ourself when we forgot.
>
> Thx
> T.
>
>> Gesendet: Donnerstag, 17. September 2015 um 15:40 Uhr
>> Von: "Marcus Denker" <[hidden email]>
>> An: "Pharo Development List" <[hidden email]>
>> Betreff: Re: [Pharo-dev] Contribution scheme confusing ...
>>
>>>>
>>>> Also:
>>>> I did a simple fix on NautilusGroupAutoBuilder package - there is
>>>> a ConfigurationOfNautilusGroupAutoBuilder. But is it managed internally
>>>> or externally now?
>>>>
>>> Even I can not tell you.
>>>
>>
>> I think the rule we should adopt: if there is a dedicated repository defined in the image for a package, people should commit
>> there. If there is non (just the inbox), then this should be used (with the Slice mechanism).
>>
>> The repositories in the image should be already up to date, I think.
>>
>> Marcus
>>
>>
> <HowToContributeHelp class.TorstenBergmann.cs>

Torsten Bergmann

Re: Contribution scheme confusing ...

https://pharo.fogbugz.com/f/cases/16611

> Gesendet: Sonntag, 20. September 2015 um 16:30 Uhr
> Von: "Marcus Denker" <[hidden email]>
> An: "Pharo Development List" <[hidden email]>
> Betreff: Re: [Pharo-dev] Contribution scheme confusing ...
>
> Yes, this is good to put it in the image… I will update the website later, too.
>
> can you make an issue?
>
> > On 17 Sep 2015, at 17:35, Torsten Bergmann <[hidden email]> wrote:
> >
> > Hi Marcus,
> >
> > Could work - but is a fragile rule. We should document it somewhere.
> >
> > What about providing this info directly in the image. Alexandre has already added a help topic on how
> > to contribute (but yet only for the slice process).
> >
> > I changed it so we can have the differences of config managed ones described as well and
> > we can list the configs there. See the attached changeset that you can file in into the latest
> > Pharo5.0 Latest update: #50329
> >
> > File in and check "How to contribute to Pharo base code" topic in Help -> Help Browser
> >
> > I guess this would be more clear to us and the users and we can simply point to
> > the help info is someone asks. And look up ourself when we forgot.
> >
> > Thx
> > T.
> >
> >> Gesendet: Donnerstag, 17. September 2015 um 15:40 Uhr
> >> Von: "Marcus Denker" <[hidden email]>
> >> An: "Pharo Development List" <[hidden email]>
> >> Betreff: Re: [Pharo-dev] Contribution scheme confusing ...
> >>
> >>>>
> >>>> Also:
> >>>> I did a simple fix on NautilusGroupAutoBuilder package - there is
> >>>> a ConfigurationOfNautilusGroupAutoBuilder. But is it managed internally
> >>>> or externally now?
> >>>>
> >>> Even I can not tell you.
> >>>
> >>
> >> I think the rule we should adopt: if there is a dedicated repository defined in the image for a package, people should commit
> >> there. If there is non (just the inbox), then this should be used (with the Slice mechanism).
> >>
> >> The repositories in the image should be already up to date, I think.
> >>
> >> Marcus
> >>
> >>
> > <HowToContributeHelp class.TorstenBergmann.cs>
>
>
>