crap⦠I was victim of IMAP OSX Mail bug. This answer should be linked to other thread, sorry.
On 01 Oct 2014, at 20:12, Esteban Lorenzano <estebanlm@gmail.com> wrote:
Process can always be enhanced, of course. But in fact what we did now was just to formalise what was already happening (with Zinc, for example). so we can continue enhancing it from here.
about your fears: - all sub-projects will be (we still need to move some there) under âPharoâ umbrella, so once you have access to one you have access to all. - It will slowdown some stuff, but it will promote better decoupling of system components and with time, it will enhance (and speed) the work a lot. - most of the changes we made are just a few method changes that are almost all the time in just one package. The potential problem is just in the rest⦠we will reduce the emergence of these in the process of extracting subprojects from what now is a complicated, monolithic system. The process of decoupling, btw, is an ongoing process from years now, and it still will take some more years. It will not be finished in Pharo4 and probably not on Pharo6 either⦠what we did now is to create the required infrastructure support for allow this decoupling. - This way is different to what we have been doing until now, I know, and it will need some adjustment in the way we contribute. But is a lot better!
cheers, Esteban
ps: Side note, about the issue linked: it was not going to happen that we change something through a slice, even without this new infrastructure, because is an external managed project (same as Zinc), and it will require a commit in appropriate repository anyway.
On 01 Oct 2014, at 19:03, Alexandre Bergel <alexandre.bergel@me.com> wrote:
And confusing as one can see here: https://pharo.fogbugz.com/f/cases/14137
Will we end up in "I need access to repo", "please add me as contributor to" hell and slow down the integration process as one has to wait until the responsible person has time (and is willing to accept the change)?
I agree with the goal but not the way it is now presented to the community!
For such an important change why not propose FIRST a plan how contribution process will change, discussing how it could be handled best or supported by tools. Instead you just change/enforce it and now discussion starts afterwards...
Bye T.
Gesendet: Mittwoch, 01. Oktober 2014 um 18:20 Uhr Von: "Sebastian Sastre" <sebastian@flowingconcept.com> An: "Pharo Development List" <pharo-dev@lists.pharo.org> Betreff: Re: [Pharo-dev] IMPORTANT: Contributing to "Configurated" sub-projects
sounds great!
sebastian
o/
On 01/10/2014, at 12:41, Esteban Lorenzano <estebanlm@gmail.com> 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