basically, if you working on a subproject, you should not mess with others. so, if you fixing, lets say, GTools, dirtiness should affect just him. If not, then you, gtool maintainers or pharo core maintainers made a mistake (or all of them). of course, that works *just* for sub-projects managed with configurations. All the rest still works as before. And for configurations, Iâm adapting the monkey to test them too (but you should not worry about that, unless you are a âsub-project maintainerâ). Esteban
On 01 Oct 2014, at 18:30, Ben Coman <btc@openInWorld.com> wrote:
Esteban Lorenzano wrote:
Hi, As you might or might not seen, we are moving Pharo into a different architecture: From a monolitic "one-image-is-all", we are (very slowly) going into an small kernel and a set of sub-projects who will populate the image and provide all required features. In general, the idea is that the final state, what we call "Pharo" will stay as an unity with all the tools/frameworks/libraries you already know and love, but the building process will be completely different, allowing us to better manage the release process and allowing users to build their own versions of specific pharos (I can imagine, for example, morphic-less pharos used in server applications, etc.). Well... this direction we are taking just made his first change, that can annoy a bit the community, until we find a new equillibrium :) Until now, most changes, bugfixes, etc. were contributed using old know SLICES, who make a good job in this monilitic approach. And starting now, there are certain subprojects that cannot be managed like that anymore and has to be managed through regular contributions to their repositories. Then, responsible guys from those projects will submit an "Integration request" (something like a pull request), when they consider is necesary an update to Pharo. Those projects are, for now: - Zinc (responsible is Sven) - GTools (responsibles are Doru and Andrei) - OSWindow (responsible is Igor) We hope, with time, to move all non-kernel code into their respective sub-projects, all with their responsibles, but for now, we started with this ones :) (I hope this mail is understandable... I feel I'm being super confusing :P) cheers, Esteban
Not confusing, and I like the philosophy, but there are some gaps.
* How will multiple dirty sub-packages be bundled as a group for an issue? Could Versioneer be designed to help add a #fixNNNNN symbolic tag into the Configuration. Or do we name the files ConfigurationOfZinc-FixNNNNN?
* How will the monkey interact with the submitted fixes, when they are first submitted? Its very useful for the monkey to remotely check the tests rather than have to wait for tests to run locally.
cheers -ben