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.
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.
On 16 Sep 2015, at 22:17, Torsten Bergmann <astares@gmx.de> 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
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
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 <marcus.denker@inria.fr> 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"
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" <marcus.denker@inria.fr> An: "Pharo Development List" <pharo-dev@lists.pharo.org> 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
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 <astares@gmx.de> 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" <marcus.denker@inria.fr> An: "Pharo Development List" <pharo-dev@lists.pharo.org> 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>
https://pharo.fogbugz.com/f/cases/16611
Gesendet: Sonntag, 20. September 2015 um 16:30 Uhr Von: "Marcus Denker" <marcus.denker@inria.fr> An: "Pharo Development List" <pharo-dev@lists.pharo.org> 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 <astares@gmx.de> 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" <marcus.denker@inria.fr> An: "Pharo Development List" <pharo-dev@lists.pharo.org> 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>
On Thu, Sep 17, 2015 at 9:40 PM, Marcus Denker <marcus.denker@inria.fr> 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
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
On 19 Sep 2015, at 10:39, Marcus Denker <marcus.denker@inria.fr> 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
participants (6)
-
Ben Coman -
Esteban Lorenzano -
Marcus Denker -
stepharo -
Torsten Bergmann -
Tudor Girba