Integration process in presence of "external" project
Esteban I was thinking about the following this night. While I understand that we want configuration only it will slow us down like hell. Example with guille we wanted to fix a problem (I do not remember which one) we need a change to be done in rubric so we will have to publish the change in rubric repo - (find it and add it) so the rubric repo should be there before - then one guy of rubric should have a look - then merge - then publish an issue with a configuration - then only then we can work => result why do we need sync for me and guille to continue to work??? => what if Alain in on vacation? we stop working? => Remember: We did Pharo especially because people in squeak did not want that we change packages. Alternate process - we do a fix we publish it in Pharo and yes this touches Rubric and - we integrate it in Pharo head - then the guy from rubric merge in their trunk when they want. it should be part of the their process to merge always with pharo trunk - At that point they can report a problem - then they produce at their speed a new configuration - then we integrate when ready their change Stef
I disagree with your proposal. It will be a mess, nobody will merge (because there will be no point on doing it) and we will not move out from a monolithic system. What I propose is not an invention, is how big projects work⦠what you have to take into account is that any project under the Pharo umbrella does not have an owner, but a maintainer. That means if Alan is on vacation or he does not has the time to do the new configuration, anyone can doit. Yes, it can look slow, but that is because you are too used to the old workflow, and because right now system is not modular. The method I propose will enhance modularity (while the older will, at least, not help), which means with time, changes will be applied just in one module and not along the full system like now. Of course with proper tools this will be faster, but I very much prefer people telling me âI need thisâ (thatâs why I did the integrator app, and modified the monkey to take and validate configurations), and we do it, that we abandon our pursuit of modularity because is uncomfortable at the beginning. We can modify also monticello or versioner (better monticello because everything will be closer, but using versioner API) to do a âsave new versionâ which would be more or less the same as a slice, but for a configuration, and it will: - save the packages associated to the configuration - create a new version - save the new configuration this will not be to much work (I think I can have it in a couple of days), it will help the process (because eventually everything should be managed through configurations (or PPM configurations), and it will allow us to keep a process that is better and validated.. TL;DR: Better enhance the tools than drop the process. Esteban
On 22 Apr 2015, at 07:47, stepharo <stepharo@free.fr> wrote:
Esteban I was thinking about the following this night.
While I understand that we want configuration only it will slow us down like hell.
Example with guille we wanted to fix a problem (I do not remember which one) we need a change to be done in rubric so we will have to publish the change in rubric repo - (find it and add it) so the rubric repo should be there before - then one guy of rubric should have a look - then merge - then publish an issue with a configuration - then only then we can work => result why do we need sync for me and guille to continue to work??? => what if Alain in on vacation? we stop working? => Remember: We did Pharo especially because people in squeak did not want that we change packages.
Alternate process - we do a fix we publish it in Pharo and yes this touches Rubric and - we integrate it in Pharo head - then the guy from rubric merge in their trunk when they want. it should be part of the their process to merge always with pharo trunk - At that point they can report a problem - then they produce at their speed a new configuration - then we integrate when ready their change
Stef
and btw⦠of course I agree repositories need to be added, and configurations kept in image. cheers, Esteban
On 22 Apr 2015, at 08:34, Esteban Lorenzano <estebanlm@gmail.com> wrote:
I disagree with your proposal. It will be a mess, nobody will merge (because there will be no point on doing it) and we will not move out from a monolithic system. What I propose is not an invention, is how big projects work⦠what you have to take into account is that any project under the Pharo umbrella does not have an owner, but a maintainer. That means if Alan is on vacation or he does not has the time to do the new configuration, anyone can doit.
Yes, it can look slow, but that is because you are too used to the old workflow, and because right now system is not modular. The method I propose will enhance modularity (while the older will, at least, not help), which means with time, changes will be applied just in one module and not along the full system like now.
Of course with proper tools this will be faster, but I very much prefer people telling me âI need thisâ (thatâs why I did the integrator app, and modified the monkey to take and validate configurations), and we do it, that we abandon our pursuit of modularity because is uncomfortable at the beginning.
We can modify also monticello or versioner (better monticello because everything will be closer, but using versioner API) to do a âsave new versionâ which would be more or less the same as a slice, but for a configuration, and it will:
- save the packages associated to the configuration - create a new version - save the new configuration
this will not be to much work (I think I can have it in a couple of days), it will help the process (because eventually everything should be managed through configurations (or PPM configurations), and it will allow us to keep a process that is better and validated..
TL;DR: Better enhance the tools than drop the process.
Esteban
On 22 Apr 2015, at 07:47, stepharo <stepharo@free.fr> wrote:
Esteban I was thinking about the following this night.
While I understand that we want configuration only it will slow us down like hell.
Example with guille we wanted to fix a problem (I do not remember which one) we need a change to be done in rubric so we will have to publish the change in rubric repo - (find it and add it) so the rubric repo should be there before - then one guy of rubric should have a look - then merge - then publish an issue with a configuration - then only then we can work => result why do we need sync for me and guille to continue to work??? => what if Alain in on vacation? we stop working? => Remember: We did Pharo especially because people in squeak did not want that we change packages.
Alternate process - we do a fix we publish it in Pharo and yes this touches Rubric and - we integrate it in Pharo head - then the guy from rubric merge in their trunk when they want. it should be part of the their process to merge always with pharo trunk - At that point they can report a problem - then they produce at their speed a new configuration - then we integrate when ready their change
Stef
in fact I just checked and Versioner already does that: right button on monticello over a configuration gives you a: âcreate development/release versionâ. So only thing we need is to use the tools we already created :)
On 22 Apr 2015, at 08:50, Esteban Lorenzano <estebanlm@gmail.com> wrote:
and btw⦠of course I agree repositories need to be added, and configurations kept in image.
cheers, Esteban
On 22 Apr 2015, at 08:34, Esteban Lorenzano <estebanlm@gmail.com> wrote:
I disagree with your proposal. It will be a mess, nobody will merge (because there will be no point on doing it) and we will not move out from a monolithic system. What I propose is not an invention, is how big projects work⦠what you have to take into account is that any project under the Pharo umbrella does not have an owner, but a maintainer. That means if Alan is on vacation or he does not has the time to do the new configuration, anyone can doit.
Yes, it can look slow, but that is because you are too used to the old workflow, and because right now system is not modular. The method I propose will enhance modularity (while the older will, at least, not help), which means with time, changes will be applied just in one module and not along the full system like now.
Of course with proper tools this will be faster, but I very much prefer people telling me âI need thisâ (thatâs why I did the integrator app, and modified the monkey to take and validate configurations), and we do it, that we abandon our pursuit of modularity because is uncomfortable at the beginning.
We can modify also monticello or versioner (better monticello because everything will be closer, but using versioner API) to do a âsave new versionâ which would be more or less the same as a slice, but for a configuration, and it will:
- save the packages associated to the configuration - create a new version - save the new configuration
this will not be to much work (I think I can have it in a couple of days), it will help the process (because eventually everything should be managed through configurations (or PPM configurations), and it will allow us to keep a process that is better and validated..
TL;DR: Better enhance the tools than drop the process.
Esteban
On 22 Apr 2015, at 07:47, stepharo <stepharo@free.fr> wrote:
Esteban I was thinking about the following this night.
While I understand that we want configuration only it will slow us down like hell.
Example with guille we wanted to fix a problem (I do not remember which one) we need a change to be done in rubric so we will have to publish the change in rubric repo - (find it and add it) so the rubric repo should be there before - then one guy of rubric should have a look - then merge - then publish an issue with a configuration - then only then we can work => result why do we need sync for me and guille to continue to work??? => what if Alain in on vacation? we stop working? => Remember: We did Pharo especially because people in squeak did not want that we change packages.
Alternate process - we do a fix we publish it in Pharo and yes this touches Rubric and - we integrate it in Pharo head - then the guy from rubric merge in their trunk when they want. it should be part of the their process to merge always with pharo trunk - At that point they can report a problem - then they produce at their speed a new configuration - then we integrate when ready their change
Stef
Le 22/04/2015 09:02, Esteban Lorenzano a écrit :
in fact I just checked and Versioner already does that: right button on monticello over a configuration gives you a: âcreate development/release versionâ. So only thing we need is to use the tools we already created :)
My position would be that, as in large projects with external upstream, the version of the external project you integrate is not exactly the same as the external one. You have a process of pushing fixes upstream, and merging the versions from the external project into yours. If you have good merge support, this is an easy process. Also remember that we have to deal with long-lived integration processes with a significant memory; large configurations with lots of versions may become a concern after a while (and for the current image, it doesn't mean much to have access to all that history). We saw that with package history; it may be nice to plan for that now. Another idea/possibility is to consider Baselines; given that a possible evolution for Pharo is towards versionning systems which handles branches and tags properly, baselines make that process significantly simpler than configurations by letting one only describe the dependencies between packages and sub-projects, and not their specific version numbers. A key evaluation to see if that works is: can a Minimal image can be rebuilt easily up to a full image, at any point (i.e. at least is all the information related to external projects easily available). A second one would be: if we had a git based process, how would that be? Could considering that (planning for branches, basically) make our current process simpler? Thierry
On 22 Apr 2015, at 08:50, Esteban Lorenzano <estebanlm@gmail.com> wrote:
and btw⦠of course I agree repositories need to be added, and configurations kept in image.
cheers, Esteban
On 22 Apr 2015, at 08:34, Esteban Lorenzano <estebanlm@gmail.com> wrote:
I disagree with your proposal. It will be a mess, nobody will merge (because there will be no point on doing it) and we will not move out from a monolithic system. What I propose is not an invention, is how big projects work⦠what you have to take into account is that any project under the Pharo umbrella does not have an owner, but a maintainer. That means if Alan is on vacation or he does not has the time to do the new configuration, anyone can doit.
Yes, it can look slow, but that is because you are too used to the old workflow, and because right now system is not modular. The method I propose will enhance modularity (while the older will, at least, not help), which means with time, changes will be applied just in one module and not along the full system like now.
Of course with proper tools this will be faster, but I very much prefer people telling me âI need thisâ (thatâs why I did the integrator app, and modified the monkey to take and validate configurations), and we do it, that we abandon our pursuit of modularity because is uncomfortable at the beginning.
We can modify also monticello or versioner (better monticello because everything will be closer, but using versioner API) to do a âsave new versionâ which would be more or less the same as a slice, but for a configuration, and it will:
- save the packages associated to the configuration - create a new version - save the new configuration
this will not be to much work (I think I can have it in a couple of days), it will help the process (because eventually everything should be managed through configurations (or PPM configurations), and it will allow us to keep a process that is better and validated..
TL;DR: Better enhance the tools than drop the process.
Esteban
On 22 Apr 2015, at 07:47, stepharo <stepharo@free.fr> wrote:
Esteban I was thinking about the following this night.
While I understand that we want configuration only it will slow us down like hell.
Example with guille we wanted to fix a problem (I do not remember which one) we need a change to be done in rubric so we will have to publish the change in rubric repo - (find it and add it) so the rubric repo should be there before - then one guy of rubric should have a look - then merge - then publish an issue with a configuration - then only then we can work => result why do we need sync for me and guille to continue to work??? => what if Alain in on vacation? we stop working? => Remember: We did Pharo especially because people in squeak did not want that we change packages.
Alternate process - we do a fix we publish it in Pharo and yes this touches Rubric and - we integrate it in Pharo head - then the guy from rubric merge in their trunk when they want. it should be part of the their process to merge always with pharo trunk - At that point they can report a problem - then they produce at their speed a new configuration - then we integrate when ready their change
Stef
On Wed, Apr 22, 2015 at 9:02 AM, Esteban Lorenzano <estebanlm@gmail.com> wrote:
in fact I just checked and Versioner already does that: right button on monticello over a configuration gives you a: âcreate development/release versionâ. So only thing we need is to use the tools we already created :)
But this only works for releasing simple configurations that do not depend on other configurations. This would work for rubric, for example, but not for other configurations we have in gtools. Cheers, Andrei
On 22 Apr 2015, at 08:50, Esteban Lorenzano <estebanlm@gmail.com> wrote:
and btw⦠of course I agree repositories need to be added, and configurations kept in image.
cheers, Esteban
On 22 Apr 2015, at 08:34, Esteban Lorenzano <estebanlm@gmail.com> wrote:
I disagree with your proposal. It will be a mess, nobody will merge (because there will be no point on doing it) and we will not move out from a monolithic system. What I propose is not an invention, is how big projects work⦠what you have to take into account is that any project under the Pharo umbrella does not have an owner, but a maintainer. That means if Alan is on vacation or he does not has the time to do the new configuration, anyone can doit.
Yes, it can look slow, but that is because you are too used to the old workflow, and because right now system is not modular. The method I propose will enhance modularity (while the older will, at least, not help), which means with time, changes will be applied just in one module and not along the full system like now.
Of course with proper tools this will be faster, but I very much prefer people telling me âI need thisâ (thatâs why I did the integrator app, and modified the monkey to take and validate configurations), and we do it, that we abandon our pursuit of modularity because is uncomfortable at the beginning.
We can modify also monticello or versioner (better monticello because everything will be closer, but using versioner API) to do a âsave new versionâ which would be more or less the same as a slice, but for a configuration, and it will:
- save the packages associated to the configuration - create a new version - save the new configuration
this will not be to much work (I think I can have it in a couple of days), it will help the process (because eventually everything should be managed through configurations (or PPM configurations), and it will allow us to keep a process that is better and validated..
TL;DR: Better enhance the tools than drop the process.
Esteban
On 22 Apr 2015, at 07:47, stepharo <stepharo@free.fr> wrote:
Esteban I was thinking about the following this night.
While I understand that we want configuration only it will slow us down like hell.
Example with guille we wanted to fix a problem (I do not remember which one) we need a change to be done in rubric so we will have to publish the change in rubric repo - (find it and add it) so the rubric repo should be there before - then one guy of rubric should have a look - then merge - then publish an issue with a configuration - then only then we can work => result why do we need sync for me and guille to continue to work??? => what if Alain in on vacation? we stop working? => Remember: We did Pharo especially because people in squeak did not want that we change packages.
Alternate process - we do a fix we publish it in Pharo and yes this touches Rubric and - we integrate it in Pharo head - then the guy from rubric merge in their trunk when they want. it should be part of the their process to merge always with pharo trunk - At that point they can report a problem - then they produce at their speed a new configuration - then we integrate when ready their change
Stef
Le 22/04/2015 10:21, Andrei Chis a écrit :
On Wed, Apr 22, 2015 at 9:02 AM, Esteban Lorenzano <estebanlm@gmail.com <mailto:estebanlm@gmail.com>> wrote:
in fact I just checked and Versioner already does that: right button on monticello over a configuration gives you a: âcreate development/release versionâ. So only thing we need is to use the tools we already created :)
But this only works for releasing simple configurations that do not depend on other configurations. This would work for rubric, for example, but not for other configurations we have in gtools.
I believe GTTools is certainly a poster case for trying to make that process simpler. I would really be interested to see how a combination of simpler configurations, baselines, tags and branches would look. A kind of hierarchical modeling where you only have configurations at the moment. Thierry
Cheers, Andrei
> On 22 Apr 2015, at 08:50, Esteban Lorenzano <estebanlm@gmail.com <mailto:estebanlm@gmail.com>> wrote: > > and btw⦠of course I agree repositories need to be added, and configurations kept in image. > > cheers, > Esteban > >> On 22 Apr 2015, at 08:34, Esteban Lorenzano <estebanlm@gmail.com <mailto:estebanlm@gmail.com>> wrote: >> >> I disagree with your proposal. >> It will be a mess, nobody will merge (because there will be no point on doing it) and we will not move out from a monolithic system. >> What I propose is not an invention, is how big projects work⦠what you have to take into account is that any project under the Pharo umbrella does not have an owner, but a maintainer. That means if Alan is on vacation or he does not has the time to do the new configuration, anyone can doit. >> >> Yes, it can look slow, but that is because you are too used to the old workflow, and because right now system is not modular. >> The method I propose will enhance modularity (while the older will, at least, not help), which means with time, changes will be applied just in one module and not along the full system like now. >> >> Of course with proper tools this will be faster, but I very much prefer people telling me âI need thisâ (thatâs why I did the integrator app, and modified the monkey to take and validate configurations), and we do it, that we abandon our pursuit of modularity because is uncomfortable at the beginning. >> >> We can modify also monticello or versioner (better monticello because everything will be closer, but using versioner API) to do a âsave new versionâ which would be more or less the same as a slice, but for a configuration, and it will: >> >> - save the packages associated to the configuration >> - create a new version >> - save the new configuration >> >> this will not be to much work (I think I can have it in a couple of days), it will help the process (because eventually everything should be managed through configurations (or PPM configurations), and it will allow us to keep a process that is better and validated.. >> >> TL;DR: Better enhance the tools than drop the process. >> >> Esteban >> >>> On 22 Apr 2015, at 07:47, stepharo <stepharo@free.fr <mailto:stepharo@free.fr>> wrote: >>> >>> Esteban >>> I was thinking about the following this night. >>> >>> While I understand that we want configuration only it will slow us down like hell. >>> >>> Example >>> with guille we wanted to fix a problem (I do not remember which one) >>> we need a change to be done in rubric so we will have to publish the change in rubric repo >>> - (find it and add it) so the rubric repo should be there before >>> - then one guy of rubric should have a look >>> - then merge >>> - then publish an issue with a configuration >>> - then only then we can work >>> => result why do we need sync for me and guille to continue to work??? >>> => what if Alain in on vacation? >>> we stop working? >>> => Remember: We did Pharo especially because people in squeak did not want that we change >>> packages. >>> >>> Alternate process >>> - we do a fix we publish it in Pharo and yes this touches Rubric and >>> - we integrate it in Pharo head >>> - then the guy from rubric merge in their trunk when they want. >>> it should be part of the their process to merge always with pharo trunk >>> - At that point they can report a problem >>> - then they produce at their speed a new configuration >>> - then we integrate when ready their change >>> >>> >>> Stef >>> >>> >> >
Well, I agree with Esteban and Thierry in the fact that making our lives easier to manage now by pushing changes into the Pharo/main branch will make things harder in the long run. I think we can see this as a case of two dependent configurations ConfigurationOfPharo (which does not exist but as the ad-hoc list of packages in Pharo/main) ConfigurationOfRubric => depends on ConfigurationOfPharo Stef, I'd manage it like this: - push the change we have into rubric - open an issue number X asking for the integration of rubric with that feature - open an issue Y that depends on X with the other slice of changes And here the main problem that we will have is that if we do not integrate quickly these fixes, then slices can age and become not valid. Alternatively, we can do it in several steps, avoiding the dependency: - push the change into rubric - push the part of the change into pharo that does not break the current version of rubric (avoid the renames/removals of methods) - when both are integrated we do the last step that integrates the last set of changes El mié., 22 de abr. de 2015 a la(s) 11:15 a. m., Thierry Goubier < thierry.goubier@gmail.com> escribió:
Le 22/04/2015 10:21, Andrei Chis a écrit :
On Wed, Apr 22, 2015 at 9:02 AM, Esteban Lorenzano <estebanlm@gmail.com <mailto:estebanlm@gmail.com>> wrote:
in fact I just checked and Versioner already does that: right button on monticello over a configuration gives you a: âcreate development/release versionâ. So only thing we need is to use the tools we already created :)
But this only works for releasing simple configurations that do not depend on other configurations. This would work for rubric, for example, but not for other configurations we have in gtools.
I believe GTTools is certainly a poster case for trying to make that process simpler.
I would really be interested to see how a combination of simpler configurations, baselines, tags and branches would look. A kind of hierarchical modeling where you only have configurations at the moment.
Thierry
Cheers, Andrei
> On 22 Apr 2015, at 08:50, Esteban Lorenzano <estebanlm@gmail.com <mailto:estebanlm@gmail.com>> wrote: > > and btw⦠of course I agree repositories need to be added, and configurations kept in image. > > cheers, > Esteban > >> On 22 Apr 2015, at 08:34, Esteban Lorenzano <estebanlm@gmail.com <mailto:estebanlm@gmail.com>> wrote: >> >> I disagree with your proposal. >> It will be a mess, nobody will merge (because there will be no point on doing it) and we will not move out from a monolithic system. >> What I propose is not an invention, is how big projects work⦠what you have to take into account is that any project under the Pharo umbrella does not have an owner, but a maintainer. That means if Alan is on vacation or he does not has the time to do the new configuration, anyone can doit. >> >> Yes, it can look slow, but that is because you are too used to the old workflow, and because right now system is not modular. >> The method I propose will enhance modularity (while the older will, at least, not help), which means with time, changes will be applied just in one module and not along the full system like now. >> >> Of course with proper tools this will be faster, but I very much prefer people telling me âI need thisâ (thatâs why I did the integrator app, and modified the monkey to take and validate configurations), and we do it, that we abandon our pursuit of modularity because is uncomfortable at the beginning. >> >> We can modify also monticello or versioner (better monticello because everything will be closer, but using versioner API) to do a âsave new versionâ which would be more or less the same as a slice, but for a configuration, and it will: >> >> - save the packages associated to the configuration >> - create a new version >> - save the new configuration >> >> this will not be to much work (I think I can have it in a couple of days), it will help the process (because eventually everything should be managed through configurations (or PPM configurations), and it will allow us to keep a process that is better and validated.. >> >> TL;DR: Better enhance the tools than drop the process. >> >> Esteban >> >>> On 22 Apr 2015, at 07:47, stepharo <stepharo@free.fr <mailto:stepharo@free.fr>> wrote: >>> >>> Esteban >>> I was thinking about the following this night. >>> >>> While I understand that we want configuration only it will slow us down like hell. >>> >>> Example >>> with guille we wanted to fix a problem (I do not remember which one) >>> we need a change to be done in rubric so we will have to publish the change in rubric repo >>> - (find it and add it) so the rubric repo should be there
before
>>> - then one guy of rubric should have a look >>> - then merge >>> - then publish an issue with a configuration >>> - then only then we can work >>> => result why do we need sync for me and guille to continue to work??? >>> => what if Alain in on vacation? >>> we stop working? >>> => Remember: We did Pharo especially because people in squeak did not want that we change >>> packages. >>> >>> Alternate process >>> - we do a fix we publish it in Pharo and yes this touches Rubric and >>> - we integrate it in Pharo head >>> - then the guy from rubric merge in their trunk when they want. >>> it should be part of the their process to merge always with pharo trunk >>> - At that point they can report a problem >>> - then they produce at their speed a new configuration >>> - then we integrate when ready their change >>> >>> >>> Stef >>> >>> >> >
Le 22/4/15 13:01, Guillermo Polito a écrit :
Well, I agree with Esteban and Thierry in the fact that making our lives easier to manage now by pushing changes into the Pharo/main branch will make things harder in the long run.
Yes but you see when you clean the architecture and the dependencies then after you can change not before. At least I'm not Toyota (if you know the story). My time is too limited.
I think we can see this as a case of two dependent configurations
ConfigurationOfPharo (which does not exist but as the ad-hoc list of packages in Pharo/main)
ConfigurationOfRubric => depends on ConfigurationOfPharo
Stef, I'd manage it like this:
- push the change we have into rubric - open an issue number X asking for the integration of rubric with that feature - open an issue Y that depends on X with the other slice of changes
And here the main problem that we will have is that if we do not integrate quickly these fixes, then slices can age and become not valid.
This is ok for me so I will not work on anything during the summer. Because when people are on vacation what do we do? Busy polling? Play magic?
Alternatively, we can do it in several steps, avoiding the dependency:
- push the change into rubric - push the part of the change into pharo that does not break the current version of rubric (avoid the renames/removals of methods) - when both are integrated we do the last step that integrates the last set of changes
And die in deadlock?
El mié., 22 de abr. de 2015 a la(s) 11:15 a. m., Thierry Goubier <thierry.goubier@gmail.com <mailto:thierry.goubier@gmail.com>> escribió:
Le 22/04/2015 10:21, Andrei Chis a écrit : > > > On Wed, Apr 22, 2015 at 9:02 AM, Esteban Lorenzano <estebanlm@gmail.com <mailto:estebanlm@gmail.com> > <mailto:estebanlm@gmail.com <mailto:estebanlm@gmail.com>>> wrote: > > in fact I just checked and Versioner already does that: right button > on monticello over a configuration gives you a: âcreate > development/release versionâ. > So only thing we need is to use the tools we already created :) > > > But this only works for releasing simple configurations that do not > depend on other configurations. > This would work for rubric, for example, but not for other > configurations we have in gtools.
I believe GTTools is certainly a poster case for trying to make that process simpler.
I would really be interested to see how a combination of simpler configurations, baselines, tags and branches would look. A kind of hierarchical modeling where you only have configurations at the moment.
Thierry
> > Cheers, > Andrei > > > > On 22 Apr 2015, at 08:50, Esteban Lorenzano <estebanlm@gmail.com <mailto:estebanlm@gmail.com> > <mailto:estebanlm@gmail.com <mailto:estebanlm@gmail.com>>> wrote: > > > > and btw⦠of course I agree repositories need to be added, and > configurations kept in image. > > > > cheers, > > Esteban > > > >> On 22 Apr 2015, at 08:34, Esteban Lorenzano <estebanlm@gmail.com <mailto:estebanlm@gmail.com> > <mailto:estebanlm@gmail.com <mailto:estebanlm@gmail.com>>> wrote: > >> > >> I disagree with your proposal. > >> It will be a mess, nobody will merge (because there will be no > point on doing it) and we will not move out from a monolithic system. > >> What I propose is not an invention, is how big projects work⦠> what you have to take into account is that any project under the > Pharo umbrella does not have an owner, but a maintainer. That means > if Alan is on vacation or he does not has the time to do the new > configuration, anyone can doit. > >> > >> Yes, it can look slow, but that is because you are too used to > the old workflow, and because right now system is not modular. > >> The method I propose will enhance modularity (while the older > will, at least, not help), which means with time, changes will be > applied just in one module and not along the full system like now. > >> > >> Of course with proper tools this will be faster, but I very much > prefer people telling me âI need thisâ (thatâs why I did the > integrator app, and modified the monkey to take and validate > configurations), and we do it, that we abandon our pursuit of > modularity because is uncomfortable at the beginning. > >> > >> We can modify also monticello or versioner (better monticello > because everything will be closer, but using versioner API) to do a > âsave new versionâ which would be more or less the same as a slice, > but for a configuration, and it will: > >> > >> - save the packages associated to the configuration > >> - create a new version > >> - save the new configuration > >> > >> this will not be to much work (I think I can have it in a couple > of days), it will help the process (because eventually everything > should be managed through configurations (or PPM configurations), > and it will allow us to keep a process that is better and validated.. > >> > >> TL;DR: Better enhance the tools than drop the process. > >> > >> Esteban > >> > >>> On 22 Apr 2015, at 07:47, stepharo <stepharo@free.fr <mailto:stepharo@free.fr> > <mailto:stepharo@free.fr <mailto:stepharo@free.fr>>> wrote: > >>> > >>> Esteban > >>> I was thinking about the following this night. > >>> > >>> While I understand that we want configuration only it will slow > us down like hell. > >>> > >>> Example > >>> with guille we wanted to fix a problem (I do not remember which > one) > >>> we need a change to be done in rubric so we will have to > publish the change in rubric repo > >>> - (find it and add it) so the rubric repo should be there before > >>> - then one guy of rubric should have a look > >>> - then merge > >>> - then publish an issue with a configuration > >>> - then only then we can work > >>> => result why do we need sync for me and guille to continue to > work??? > >>> => what if Alain in on vacation? > >>> we stop working? > >>> => Remember: We did Pharo especially because people in squeak > did not want that we change > >>> packages. > >>> > >>> Alternate process > >>> - we do a fix we publish it in Pharo and yes this touches > Rubric and > >>> - we integrate it in Pharo head > >>> - then the guy from rubric merge in their trunk when they want. > >>> it should be part of the their process to merge always > with pharo trunk > >>> - At that point they can report a problem > >>> - then they produce at their speed a new configuration > >>> - then we integrate when ready their change > >>> > >>> > >>> Stef > >>> > >>> > >> > > > > >
On Wed, Apr 22, 2015 at 11:15 AM, Thierry Goubier <thierry.goubier@gmail.com
wrote:
Le 22/04/2015 10:21, Andrei Chis a écrit :
On Wed, Apr 22, 2015 at 9:02 AM, Esteban Lorenzano <estebanlm@gmail.com <mailto:estebanlm@gmail.com>> wrote:
in fact I just checked and Versioner already does that: right button on monticello over a configuration gives you a: âcreate development/release versionâ. So only thing we need is to use the tools we already created :)
But this only works for releasing simple configurations that do not depend on other configurations. This would work for rubric, for example, but not for other configurations we have in gtools.
I believe GTTools is certainly a poster case for trying to make that process simpler.
I would really be interested to see how a combination of simpler configurations, baselines, tags and branches would look. A kind of hierarchical modeling where you only have configurations at the moment.
One *issue* with GTools is that they still go through a lot of changes. They are far from their final version :). For a stable project (for example Zinc) where bugs/features are less frequent one only needs to integrate once in a while. This makes working with configurations very easy: there were no complaints about this process until GTools. With GTools we need to develop and integrate at a fastest rate. Still, developing and integrating GTools into pharo just by using slices and merging commits from Pharo back to the projects' repos would take a lot of effort. Right now the problem with configurations is that it takes time from when a fix is available until it is integrated. Still, until now, with one exception, we more or less, sync with pharo quite often. Reducing the number of configurations, offering a one click solution for releasing a new version, plus a tool that show a diff for a configuration would make this process quite easy. Cheers, Andrei
Thierry
Cheers, Andrei
> On 22 Apr 2015, at 08:50, Esteban Lorenzano <estebanlm@gmail.com <mailto:estebanlm@gmail.com>> wrote: > > and btw⦠of course I agree repositories need to be added, and configurations kept in image. > > cheers, > Esteban > >> On 22 Apr 2015, at 08:34, Esteban Lorenzano <estebanlm@gmail.com <mailto:estebanlm@gmail.com>> wrote: >> >> I disagree with your proposal. >> It will be a mess, nobody will merge (because there will be no point on doing it) and we will not move out from a monolithic system. >> What I propose is not an invention, is how big projects work⦠what you have to take into account is that any project under the Pharo umbrella does not have an owner, but a maintainer. That means if Alan is on vacation or he does not has the time to do the new configuration, anyone can doit. >> >> Yes, it can look slow, but that is because you are too used to the old workflow, and because right now system is not modular. >> The method I propose will enhance modularity (while the older will, at least, not help), which means with time, changes will be applied just in one module and not along the full system like now. >> >> Of course with proper tools this will be faster, but I very much prefer people telling me âI need thisâ (thatâs why I did the integrator app, and modified the monkey to take and validate configurations), and we do it, that we abandon our pursuit of modularity because is uncomfortable at the beginning. >> >> We can modify also monticello or versioner (better monticello because everything will be closer, but using versioner API) to do a âsave new versionâ which would be more or less the same as a slice, but for a configuration, and it will: >> >> - save the packages associated to the configuration >> - create a new version >> - save the new configuration >> >> this will not be to much work (I think I can have it in a couple of days), it will help the process (because eventually everything should be managed through configurations (or PPM configurations), and it will allow us to keep a process that is better and validated.. >> >> TL;DR: Better enhance the tools than drop the process. >> >> Esteban >> >>> On 22 Apr 2015, at 07:47, stepharo <stepharo@free.fr <mailto:stepharo@free.fr>> wrote: >>> >>> Esteban >>> I was thinking about the following this night. >>> >>> While I understand that we want configuration only it will slow us down like hell. >>> >>> Example >>> with guille we wanted to fix a problem (I do not remember which one) >>> we need a change to be done in rubric so we will have to publish the change in rubric repo >>> - (find it and add it) so the rubric repo should be there before >>> - then one guy of rubric should have a look >>> - then merge >>> - then publish an issue with a configuration >>> - then only then we can work >>> => result why do we need sync for me and guille to continue to work??? >>> => what if Alain in on vacation? >>> we stop working? >>> => Remember: We did Pharo especially because people in squeak did not want that we change >>> packages. >>> >>> Alternate process >>> - we do a fix we publish it in Pharo and yes this touches Rubric and >>> - we integrate it in Pharo head >>> - then the guy from rubric merge in their trunk when they want. >>> it should be part of the their process to merge always with pharo trunk >>> - At that point they can report a problem >>> - then they produce at their speed a new configuration >>> - then we integrate when ready their change >>> >>> >>> Stef >>> >>> >> >
Le 22/04/2015 14:47, Andrei Chis a écrit :
On Wed, Apr 22, 2015 at 11:15 AM, Thierry Goubier <thierry.goubier@gmail.com <mailto:thierry.goubier@gmail.com>> wrote:
Le 22/04/2015 10:21, Andrei Chis a écrit :
On Wed, Apr 22, 2015 at 9:02 AM, Esteban Lorenzano <estebanlm@gmail.com <mailto:estebanlm@gmail.com> <mailto:estebanlm@gmail.com <mailto:estebanlm@gmail.com>>> wrote:
in fact I just checked and Versioner already does that: right button on monticello over a configuration gives you a: âcreate development/release versionâ. So only thing we need is to use the tools we already created :)
But this only works for releasing simple configurations that do not depend on other configurations. This would work for rubric, for example, but not for other configurations we have in gtools.
I believe GTTools is certainly a poster case for trying to make that process simpler.
I would really be interested to see how a combination of simpler configurations, baselines, tags and branches would look. A kind of hierarchical modeling where you only have configurations at the moment.
One *issue* with GTools is that they still go through a lot of changes. They are far from their final version :).
Which is perfectly fine by my book; it just makes it a bit more crucial to get the process right :)
For a stable project (for example Zinc) where bugs/features are less frequent one only needs to integrate once in a while. This makes working with configurations very easy: there were no complaints about this process until GTools.
Yes, I agree.
With GTools we need to develop and integrate at a fastest rate. Still, developing and integrating GTools into pharo just by using slices and merging commits from Pharo back to the projects' repos would take a lot of effort.
And this is the key of the discussion: we need a way to streamline the process to make it easier (and, if possible, avoid changing anciliary information such as the configuration as stored in another repository).
Right now the problem with configurations is that it takes time from when a fix is available until it is integrated. Still, until now, with one exception, we more or less, sync with pharo quite often.
You're the test bench :)
Reducing the number of configurations, offering a one click solution for releasing a new version, plus a tool that show a diff for a configuration would make this process quite easy.
What I know is this: If you manipulate branches and tags (as in git), what you can do is delegate part/all of the configuration update to your SCM. - Write a configuration which targets a BaselineOf and a tag (say v2.0.*) in your development repository. Do not write any package information in the configuration, write just the package names and dependencies in the BaselineOf. From now on, the Configuration will not change. - In that branch, release regular versions, naming them v2.0.<n>, as often as you like (nobody will bother if you release v2.0.113 :)) - Add as many feature branches you'd like for your internal development, merging into the v2 as you want. - Update the BaselineOf if necessary (adding a new package, changing dependencies). - Ask Pharo to integrate or merge the latest v2.0.<n> (which consist of running the ConfigurationOf: nothing less, nothing more)(*). - Merge back pharo/main stuff if any, packaged as a set of packages (a SLICE, why not: a pull request would be easier, but it is not that different). Until you switch branches and main version, you won't change that configuration again and you will never have to write (or generate) a version with all packages version numbers again. (*) Does anybody knows if we can use Metacello to merge instead of loading? Thierry
Cheers, Andrei
Thierry
Cheers, Andrei
> On 22 Apr 2015, at 08:50, Esteban Lorenzano <estebanlm@gmail.com <mailto:estebanlm@gmail.com> <mailto:estebanlm@gmail.com <mailto:estebanlm@gmail.com>>> wrote: > > and btw⦠of course I agree repositories need to be added, and configurations kept in image. > > cheers, > Esteban > >> On 22 Apr 2015, at 08:34, Esteban Lorenzano <estebanlm@gmail.com <mailto:estebanlm@gmail.com> <mailto:estebanlm@gmail.com <mailto:estebanlm@gmail.com>>> wrote: >> >> I disagree with your proposal. >> It will be a mess, nobody will merge (because there will be no point on doing it) and we will not move out from a monolithic system. >> What I propose is not an invention, is how big projects work⦠what you have to take into account is that any project under the Pharo umbrella does not have an owner, but a maintainer. That means if Alan is on vacation or he does not has the time to do the new configuration, anyone can doit. >> >> Yes, it can look slow, but that is because you are too used to the old workflow, and because right now system is not modular. >> The method I propose will enhance modularity (while the older will, at least, not help), which means with time, changes will be applied just in one module and not along the full system like now. >> >> Of course with proper tools this will be faster, but I very much prefer people telling me âI need thisâ (thatâs why I did the integrator app, and modified the monkey to take and validate configurations), and we do it, that we abandon our pursuit of modularity because is uncomfortable at the beginning. >> >> We can modify also monticello or versioner (better monticello because everything will be closer, but using versioner API) to do a âsave new versionâ which would be more or less the same as a slice, but for a configuration, and it will: >> >> - save the packages associated to the configuration >> - create a new version >> - save the new configuration >> >> this will not be to much work (I think I can have it in a couple of days), it will help the process (because eventually everything should be managed through configurations (or PPM configurations), and it will allow us to keep a process that is better and validated.. >> >> TL;DR: Better enhance the tools than drop the process. >> >> Esteban >> >>> On 22 Apr 2015, at 07:47, stepharo <stepharo@free.fr <mailto:stepharo@free.fr> <mailto:stepharo@free.fr <mailto:stepharo@free.fr>>> wrote: >>> >>> Esteban >>> I was thinking about the following this night. >>> >>> While I understand that we want configuration only it will slow us down like hell. >>> >>> Example >>> with guille we wanted to fix a problem (I do not remember which one) >>> we need a change to be done in rubric so we will have to publish the change in rubric repo >>> - (find it and add it) so the rubric repo should be there before >>> - then one guy of rubric should have a look >>> - then merge >>> - then publish an issue with a configuration >>> - then only then we can work >>> => result why do we need sync for me and guille to continue to work??? >>> => what if Alain in on vacation? >>> we stop working? >>> => Remember: We did Pharo especially because people in squeak did not want that we change >>> packages. >>> >>> Alternate process >>> - we do a fix we publish it in Pharo and yes this touches Rubric and >>> - we integrate it in Pharo head >>> - then the guy from rubric merge in their trunk when they want. >>> it should be part of the their process to merge always with pharo trunk >>> - At that point they can report a problem >>> - then they produce at their speed a new configuration >>> - then we integrate when ready their change >>> >>> >>> Stef >>> >>> >> >
On 22 Apr 2015, at 10:21, Andrei Chis <chisvasileandrei@gmail.com> wrote:
But this only works for releasing simple configurations that do not depend on other configurations. This would work for rubric, for example, but not for other configurations we have in gtools.
then you have two options: 1) you rewrite your configurations to not need nested configurations. This is not recommendable in huge projects like Seaside, but things like GTools are easily (I did a quick check and your 3 configurations have in total 7 packages⦠would not be a problem to have them without nesting projects and just using the packages). In fact, this is how Dale recommends using configurations (if I understood him right). 2) we enhance the tools to also allow the commit of nested packages. I think both approaches needs to be done: you donât need unnecessary complexity in your configurations and we need to add some nesting support to commit new version. What is not admisible, IMO, is to do something that is wrong just because it looks easier in the short term (and I say âin short termâ because what looks easier now will generate a lot of problems in the future). cheers, Esteban
And do not forget that with better Pharo modularization it will start to be a problem on more lower level. When eg. Morphic will be an "exteranal" Pharo package. -- Pavel 2015-04-22 12:03 GMT+02:00 Esteban Lorenzano <estebanlm@gmail.com>:
On 22 Apr 2015, at 10:21, Andrei Chis <chisvasileandrei@gmail.com> wrote:
But this only works for releasing simple configurations that do not depend on other configurations. This would work for rubric, for example, but not for other configurations we have in gtools.
then you have two options:
1) you rewrite your configurations to not need nested configurations. This is not recommendable in huge projects like Seaside, but things like GTools are easily (I did a quick check and your 3 configurations have in total 7 packages⦠would not be a problem to have them without nesting projects and just using the packages). In fact, this is how Dale recommends using configurations (if I understood him right). 2) we enhance the tools to also allow the commit of nested packages.
I think both approaches needs to be done: you donât need unnecessary complexity in your configurations and we need to add some nesting support to commit new version.
What is not admisible, IMO, is to do something that is wrong just because it looks easier in the short term (and I say âin short termâ because what looks easier now will generate a lot of problems in the future).
cheers, Esteban
exactly. what we need in the long term is a complete better integration process. I dream to have a git pharo project with submodules and pull requests. Slowly the tools are coming, but this will take time to implement. In the mean time, we need to do all the steps we can to allow us to achieve the modularisation goal. Even if they look not easy because we are still building it, or too used to previous ways of doing it. Esteban
On 22 Apr 2015, at 12:15, Pavel Krivanek <pavel.krivanek@gmail.com> wrote:
And do not forget that with better Pharo modularization it will start to be a problem on more lower level. When eg. Morphic will be an "exteranal" Pharo package.
-- Pavel
2015-04-22 12:03 GMT+02:00 Esteban Lorenzano <estebanlm@gmail.com>:
On 22 Apr 2015, at 10:21, Andrei Chis <chisvasileandrei@gmail.com> wrote:
But this only works for releasing simple configurations that do not depend on other configurations. This would work for rubric, for example, but not for other configurations we have in gtools.
then you have two options:
1) you rewrite your configurations to not need nested configurations. This is not recommendable in huge projects like Seaside, but things like GTools are easily (I did a quick check and your 3 configurations have in total 7 packages⦠would not be a problem to have them without nesting projects and just using the packages). In fact, this is how Dale recommends using configurations (if I understood him right). 2) we enhance the tools to also allow the commit of nested packages.
I think both approaches needs to be done: you donât need unnecessary complexity in your configurations and we need to add some nesting support to commit new version.
What is not admisible, IMO, is to do something that is wrong just because it looks easier in the short term (and I say âin short termâ because what looks easier now will generate a lot of problems in the future).
cheers, Esteban
In all new tools that we did we tried to have only 2-3 packages and use tags to organize classes in a packaged (GT-* has 9 packages for 3 projects). This allows for very simple configurations with clear dependencies. Glamour has more packages (17) but those should also be reduced, as we do not need such a low level of granularity. Given that support for working with multiple nested configuration is not great we can merge all GT-* projects into one configuration. I would still like to have different configurations for Glamour and Rubric as they are separate projects. So we can have just three configurations (each one for a separate project that can be released independent of the others): ConfigurationOfGToolkitCore ----> ConfigurationOfGlamourCore ---------> ConfigurationOfRubric This would make releasing a new version easier with the current support from versioner. Releasing a version for all three configurations at once would still require some manual updating of versions, but that's a less frequent use-case. Cheers, Andrei On Wed, Apr 22, 2015 at 12:21 PM, Esteban Lorenzano <estebanlm@gmail.com> wrote:
exactly. what we need in the long term is a complete better integration process. I dream to have a git pharo project with submodules and pull requests.
Slowly the tools are coming, but this will take time to implement. In the mean time, we need to do all the steps we can to allow us to achieve the modularisation goal. Even if they look not easy because we are still building it, or too used to previous ways of doing it.
Esteban
On 22 Apr 2015, at 12:15, Pavel Krivanek <pavel.krivanek@gmail.com> wrote:
And do not forget that with better Pharo modularization it will start to be a problem on more lower level. When eg. Morphic will be an "exteranal" Pharo package.
-- Pavel
2015-04-22 12:03 GMT+02:00 Esteban Lorenzano <estebanlm@gmail.com>:
On 22 Apr 2015, at 10:21, Andrei Chis <chisvasileandrei@gmail.com>
wrote:
But this only works for releasing simple configurations that do not
depend
on other configurations. This would work for rubric, for example, but not for other configurations we have in gtools.
then you have two options:
1) you rewrite your configurations to not need nested configurations. This is not recommendable in huge projects like Seaside, but things like GTools are easily (I did a quick check and your 3 configurations have in total 7 packages⦠would not be a problem to have them without nesting projects and just using the packages). In fact, this is how Dale recommends using configurations (if I understood him right). 2) we enhance the tools to also allow the commit of nested packages.
I think both approaches needs to be done: you donât need unnecessary complexity in your configurations and we need to add some nesting support to commit new version.
What is not admisible, IMO, is to do something that is wrong just because it looks easier in the short term (and I say âin short termâ because what looks easier now will generate a lot of problems in the future).
cheers, Esteban
andrei You talk about releasing. I talk about changes that should be done on a system while people are not active. Stef Le 22/4/15 15:29, Andrei Chis a écrit :
In all new tools that we did we tried to have only 2-3 packages and use tags to organize classes in a packaged (GT-* has 9 packages for 3 projects). This allows for very simple configurations with clear dependencies. Glamour has more packages (17) but those should also be reduced, as we do not need such a low level of granularity.
Given that support for working with multiple nested configuration is not great we can merge all GT-* projects into one configuration. I would still like to have different configurations for Glamour and Rubric as they are separate projects. So we can have just three configurations (each one for a separate project that can be released independent of the others):
ConfigurationOfGToolkitCore ----> ConfigurationOfGlamourCore ---------> ConfigurationOfRubric
This would make releasing a new version easier with the current support from versioner. Releasing a version for all three configurations at once would still require some manual updating of versions, but that's a less frequent use-case.
Cheers, Andrei
On Wed, Apr 22, 2015 at 12:21 PM, Esteban Lorenzano <estebanlm@gmail.com <mailto:estebanlm@gmail.com>> wrote:
exactly. what we need in the long term is a complete better integration process. I dream to have a git pharo project with submodules and pull requests.
Slowly the tools are coming, but this will take time to implement. In the mean time, we need to do all the steps we can to allow us to achieve the modularisation goal. Even if they look not easy because we are still building it, or too used to previous ways of doing it.
Esteban
> On 22 Apr 2015, at 12:15, Pavel Krivanek <pavel.krivanek@gmail.com <mailto:pavel.krivanek@gmail.com>> wrote: > > And do not forget that with better Pharo modularization it will start > to be a problem on more lower level. When eg. Morphic will be an > "exteranal" Pharo package. > > -- Pavel > > 2015-04-22 12:03 GMT+02:00 Esteban Lorenzano <estebanlm@gmail.com <mailto:estebanlm@gmail.com>>: >> >> On 22 Apr 2015, at 10:21, Andrei Chis <chisvasileandrei@gmail.com <mailto:chisvasileandrei@gmail.com>> wrote: >> >> But this only works for releasing simple configurations that do not depend >> on other configurations. >> This would work for rubric, for example, but not for other configurations we >> have in gtools. >> >> >> then you have two options: >> >> 1) you rewrite your configurations to not need nested configurations. This >> is not recommendable in huge projects like Seaside, but things like GTools >> are easily (I did a quick check and your 3 configurations have in total 7 >> packages⦠would not be a problem to have them without nesting projects and >> just using the packages). In fact, this is how Dale recommends using >> configurations (if I understood him right). >> 2) we enhance the tools to also allow the commit of nested packages. >> >> I think both approaches needs to be done: you donât need unnecessary >> complexity in your configurations and we need to add some nesting support to >> commit new version. >> >> What is not admisible, IMO, is to do something that is wrong just because it >> looks easier in the short term (and I say âin short termâ because what looks >> easier now will generate a lot of problems in the future). >> >> cheers, >> Esteban >
On Wed, Apr 22, 2015 at 7:55 PM, stepharo <stepharo@free.fr> wrote:
andrei
You talk about releasing. I talk about changes that should be done on a system while people are not active.
If we are all on vacation, or you really really need a bug fixed, or you make a change that touches a lot of packages then I see no problem if you make a slice and notify us so we can back port it. What I would like to avoid is this becoming the default behaviour any time you want to make change that is just related to a project that is maintain by configurations. Right now for rubric you can just commit you package to the rubric repo under the pharo team, create a new version using versioner, copy it to PharoInbox50, make an issue to integrate it and integrate it. A few more steps then working with slices but you do not have to wait for us to integrate :). You might get some merge conflicts when we are actively working on rubric but then we are around to help with the merge. Cheers, Andrei
Stef
Le 22/4/15 15:29, Andrei Chis a écrit :
In all new tools that we did we tried to have only 2-3 packages and use tags to organize classes in a packaged (GT-* has 9 packages for 3 projects). This allows for very simple configurations with clear dependencies. Glamour has more packages (17) but those should also be reduced, as we do not need such a low level of granularity.
Given that support for working with multiple nested configuration is not great we can merge all GT-* projects into one configuration. I would still like to have different configurations for Glamour and Rubric as they are separate projects. So we can have just three configurations (each one for a separate project that can be released independent of the others):
ConfigurationOfGToolkitCore ----> ConfigurationOfGlamourCore ---------> ConfigurationOfRubric
This would make releasing a new version easier with the current support from versioner. Releasing a version for all three configurations at once would still require some manual updating of versions, but that's a less frequent use-case.
Cheers, Andrei
On Wed, Apr 22, 2015 at 12:21 PM, Esteban Lorenzano <estebanlm@gmail.com> wrote:
exactly. what we need in the long term is a complete better integration process. I dream to have a git pharo project with submodules and pull requests.
Slowly the tools are coming, but this will take time to implement. In the mean time, we need to do all the steps we can to allow us to achieve the modularisation goal. Even if they look not easy because we are still building it, or too used to previous ways of doing it.
Esteban
On 22 Apr 2015, at 12:15, Pavel Krivanek <pavel.krivanek@gmail.com> wrote:
And do not forget that with better Pharo modularization it will start to be a problem on more lower level. When eg. Morphic will be an "exteranal" Pharo package.
-- Pavel
2015-04-22 12:03 GMT+02:00 Esteban Lorenzano <estebanlm@gmail.com>:
On 22 Apr 2015, at 10:21, Andrei Chis <chisvasileandrei@gmail.com>
wrote:
But this only works for releasing simple configurations that do not
depend
on other configurations. This would work for rubric, for example, but not for other configurations we have in gtools.
then you have two options:
1) you rewrite your configurations to not need nested configurations. This is not recommendable in huge projects like Seaside, but things like GTools are easily (I did a quick check and your 3 configurations have in total 7 packages⦠would not be a problem to have them without nesting projects and just using the packages). In fact, this is how Dale recommends using configurations (if I understood him right). 2) we enhance the tools to also allow the commit of nested packages.
I think both approaches needs to be done: you donât need unnecessary complexity in your configurations and we need to add some nesting support to commit new version.
What is not admisible, IMO, is to do something that is wrong just because it looks easier in the short term (and I say âin short termâ because what looks easier now will generate a lot of problems in the future).
cheers, Esteban
On 22 Apr 2015, at 21:17, Andrei Chis <chisvasileandrei@gmail.com> wrote:
On Wed, Apr 22, 2015 at 7:55 PM, stepharo <stepharo@free.fr <mailto:stepharo@free.fr>> wrote: andrei
You talk about releasing. I talk about changes that should be done on a system while people are not active.
If we are all on vacation, or you really really need a bug fixed, or you make a change that touches a lot of packages then I see no problem if you make a slice and notify us so we can back port it.
What I would like to avoid is this becoming the default behaviour any time you want to make change that is just related to a project that is maintain by configurations.
Right now for rubric you can just commit you package to the rubric repo under the pharo team, create a new version using versioner, copy it to PharoInbox50, make an issue to integrate it and integrate it. A few more steps then working with slices but you do not have to wait for us to integrate :). You might get some merge conflicts when we are actively working on rubric but then we are around to help with the merge.
I will add a âcommit new versionâ option that will reduce the steps too. It will: - commit dirty packages from version to corresponding configuration, - generate and commit new version. - It will do it recursively with nested configurations so, this will solve all complains you might have :) Esteban
Cheers, Andrei
Stef
Le 22/4/15 15:29, Andrei Chis a écrit :
In all new tools that we did we tried to have only 2-3 packages and use tags to organize classes in a packaged (GT-* has 9 packages for 3 projects). This allows for very simple configurations with clear dependencies. Glamour has more packages (17) but those should also be reduced, as we do not need such a low level of granularity.
Given that support for working with multiple nested configuration is not great we can merge all GT-* projects into one configuration. I would still like to have different configurations for Glamour and Rubric as they are separate projects. So we can have just three configurations (each one for a separate project that can be released independent of the others):
ConfigurationOfGToolkitCore ----> ConfigurationOfGlamourCore ---------> ConfigurationOfRubric
This would make releasing a new version easier with the current support from versioner. Releasing a version for all three configurations at once would still require some manual updating of versions, but that's a less frequent use-case.
Cheers, Andrei
On Wed, Apr 22, 2015 at 12:21 PM, Esteban Lorenzano <estebanlm@gmail.com <mailto:estebanlm@gmail.com>> wrote: exactly. what we need in the long term is a complete better integration process. I dream to have a git pharo project with submodules and pull requests.
Slowly the tools are coming, but this will take time to implement. In the mean time, we need to do all the steps we can to allow us to achieve the modularisation goal. Even if they look not easy because we are still building it, or too used to previous ways of doing it.
Esteban
On 22 Apr 2015, at 12:15, Pavel Krivanek <pavel.krivanek@gmail.com <mailto:pavel.krivanek@gmail.com>> wrote:
And do not forget that with better Pharo modularization it will start to be a problem on more lower level. When eg. Morphic will be an "exteranal" Pharo package.
-- Pavel
2015-04-22 12:03 GMT+02:00 Esteban Lorenzano <estebanlm@gmail.com <mailto:estebanlm@gmail.com>>:
On 22 Apr 2015, at 10:21, Andrei Chis <chisvasileandrei@gmail.com <mailto:chisvasileandrei@gmail.com>> wrote:
But this only works for releasing simple configurations that do not depend on other configurations. This would work for rubric, for example, but not for other configurations we have in gtools.
then you have two options:
1) you rewrite your configurations to not need nested configurations. This is not recommendable in huge projects like Seaside, but things like GTools are easily (I did a quick check and your 3 configurations have in total 7 packages⦠would not be a problem to have them without nesting projects and just using the packages). In fact, this is how Dale recommends using configurations (if I understood him right). 2) we enhance the tools to also allow the commit of nested packages.
I think both approaches needs to be done: you donât need unnecessary complexity in your configurations and we need to add some nesting support to commit new version.
What is not admisible, IMO, is to do something that is wrong just because it looks easier in the short term (and I say âin short termâ because what looks easier now will generate a lot of problems in the future).
cheers, Esteban
I will add a âcommit new versionâ option that will reduce the steps too. It will: - commit dirty packages from version to corresponding configuration, - generate and commit new version. - It will do it recursively with nested configurations
so, this will solve all complains you might have :)
Ok show us and we will do it. Now for now I will not work on changes that imply waiting for an integration of a subproject. Stef
Indeed, I also think this is the better option at this point in time. Doru On Wed, Apr 22, 2015 at 9:22 PM, Esteban Lorenzano <estebanlm@gmail.com> wrote: ....
I will add a âcommit new versionâ option that will reduce the steps too. It will: - commit dirty packages from version to corresponding configuration, - generate and commit new version. - It will do it recursively with nested configurations
so, this will solve all complains you might have :)
Esteban
-- www.tudorgirba.com "Every thing has its own flow"
Le 22/4/15 13:21, Esteban Lorenzano a écrit :
exactly. what we need in the long term is a complete better integration process. I dream to have a git pharo project with submodules and pull requests.
Slowly the tools are coming, but this will take time to implement. In the mean time, we need to do all the steps we can to allow us to achieve the modularisation goal. Even if they look not easy because we are still building it, or too used to previous ways of doing it.
This is ok for me but I will not work on this condition. I will just frustrate too much. Just waiting that somebody somewhere is integrating a stupid change so that I can work. Because there are moments where I can work and other not. I will accomodate about this and work on other projects than Pharo. Stef
in fact I just checked and Versioner already does that: right button on monticello over a configuration gives you a: âcreate development/release versionâ. So only thing we need is to use the tools we already created :)
Well did you try the configurations that other people created with versionner? I will not fix them. Stef
On 22 Apr 2015, at 08:50, Esteban Lorenzano <estebanlm@gmail.com> wrote:
and btw⦠of course I agree repositories need to be added, and configurations kept in image.
cheers, Esteban
On 22 Apr 2015, at 08:34, Esteban Lorenzano <estebanlm@gmail.com> wrote:
I disagree with your proposal. It will be a mess, nobody will merge (because there will be no point on doing it) and we will not move out from a monolithic system. What I propose is not an invention, is how big projects work⦠what you have to take into account is that any project under the Pharo umbrella does not have an owner, but a maintainer. That means if Alan is on vacation or he does not has the time to do the new configuration, anyone can doit.
Yes, it can look slow, but that is because you are too used to the old workflow, and because right now system is not modular. The method I propose will enhance modularity (while the older will, at least, not help), which means with time, changes will be applied just in one module and not along the full system like now.
Of course with proper tools this will be faster, but I very much prefer people telling me âI need thisâ (thatâs why I did the integrator app, and modified the monkey to take and validate configurations), and we do it, that we abandon our pursuit of modularity because is uncomfortable at the beginning.
We can modify also monticello or versioner (better monticello because everything will be closer, but using versioner API) to do a âsave new versionâ which would be more or less the same as a slice, but for a configuration, and it will:
- save the packages associated to the configuration - create a new version - save the new configuration
this will not be to much work (I think I can have it in a couple of days), it will help the process (because eventually everything should be managed through configurations (or PPM configurations), and it will allow us to keep a process that is better and validated..
TL;DR: Better enhance the tools than drop the process.
Esteban
On 22 Apr 2015, at 07:47, stepharo <stepharo@free.fr> wrote:
Esteban I was thinking about the following this night.
While I understand that we want configuration only it will slow us down like hell.
Example with guille we wanted to fix a problem (I do not remember which one) we need a change to be done in rubric so we will have to publish the change in rubric repo - (find it and add it) so the rubric repo should be there before - then one guy of rubric should have a look - then merge - then publish an issue with a configuration - then only then we can work => result why do we need sync for me and guille to continue to work??? => what if Alain in on vacation? we stop working? => Remember: We did Pharo especially because people in squeak did not want that we change packages.
Alternate process - we do a fix we publish it in Pharo and yes this touches Rubric and - we integrate it in Pharo head - then the guy from rubric merge in their trunk when they want. it should be part of the their process to merge always with pharo trunk - At that point they can report a problem - then they produce at their speed a new configuration - then we integrate when ready their change
Stef
and btw⦠of course I agree repositories need to be added, and configurations kept in image. So what will happen when I publish a configuration with new package in the repo of XXX where XXX is under dev or under a more recent version. They will have to merge. Because I will only publish to be able to load the code I changed into just the next version of Pharo so that I can continue to work on the other parts of the changes.
Stef
cheers, Esteban
On 22 Apr 2015, at 08:34, Esteban Lorenzano <estebanlm@gmail.com> wrote:
I disagree with your proposal. It will be a mess, nobody will merge (because there will be no point on doing it) and we will not move out from a monolithic system. What I propose is not an invention, is how big projects work⦠what you have to take into account is that any project under the Pharo umbrella does not have an owner, but a maintainer. That means if Alan is on vacation or he does not has the time to do the new configuration, anyone can doit.
Yes, it can look slow, but that is because you are too used to the old workflow, and because right now system is not modular. The method I propose will enhance modularity (while the older will, at least, not help), which means with time, changes will be applied just in one module and not along the full system like now.
Of course with proper tools this will be faster, but I very much prefer people telling me âI need thisâ (thatâs why I did the integrator app, and modified the monkey to take and validate configurations), and we do it, that we abandon our pursuit of modularity because is uncomfortable at the beginning.
We can modify also monticello or versioner (better monticello because everything will be closer, but using versioner API) to do a âsave new versionâ which would be more or less the same as a slice, but for a configuration, and it will:
- save the packages associated to the configuration - create a new version - save the new configuration
this will not be to much work (I think I can have it in a couple of days), it will help the process (because eventually everything should be managed through configurations (or PPM configurations), and it will allow us to keep a process that is better and validated..
TL;DR: Better enhance the tools than drop the process.
Esteban
On 22 Apr 2015, at 07:47, stepharo <stepharo@free.fr> wrote:
Esteban I was thinking about the following this night.
While I understand that we want configuration only it will slow us down like hell.
Example with guille we wanted to fix a problem (I do not remember which one) we need a change to be done in rubric so we will have to publish the change in rubric repo - (find it and add it) so the rubric repo should be there before - then one guy of rubric should have a look - then merge - then publish an issue with a configuration - then only then we can work => result why do we need sync for me and guille to continue to work??? => what if Alain in on vacation? we stop working? => Remember: We did Pharo especially because people in squeak did not want that we change packages.
Alternate process - we do a fix we publish it in Pharo and yes this touches Rubric and - we integrate it in Pharo head - then the guy from rubric merge in their trunk when they want. it should be part of the their process to merge always with pharo trunk - At that point they can report a problem - then they produce at their speed a new configuration - then we integrate when ready their change
Stef
Ok perfect then I will not work on changes that touch other projects. I suggest also guille not to try and we should focus on something else than in the image.
I disagree with your proposal. It will be a mess, nobody will merge (because there will be no point on doing it) and we will not move out from a monolithic system. What I propose is not an invention, is how big projects work⦠what you have to take into account is that any project under the Pharo umbrella does not have an owner, but a maintainer. That means if Alan is on vacation or he does not has the time to do the new configuration, anyone can doit.
Yes, it can look slow, but that is because you are too used to the old workflow, and because right now system is not modular. The method I propose will enhance modularity (while the older will, at least, not help), which means with time, changes will be applied just in one module and not along the full system like now. Ok I will let you enhance the modularity because my time is more expensive. Then when pharo will be modular I will come back.
Of course with proper tools this will be faster, but I very much prefer people telling me âI need thisâ (thatâs why I did the integrator app, and modified the monkey to take and validate configurations), and we do it, that we abandon our pursuit of modularity because is uncomfortable at the beginning.
You mixed everything. Did I talk about abandon our pursuit of modularity. Now what you are suggesting is that a change that can take 10 min will take several days to be done. From my concentration and energy point of view I will not work under such conditions. May I ask you when is the last time you work on remodularizing Pharo? Because I can say that I got my share with Guille but if Pharo does not respect my time then no problem I will do something else.
We can modify also monticello or versioner (better monticello because everything will be closer, but using versioner API) to do a âsave new versionâ which would be more or less the same as a slice, but for a configuration, and it will:
- save the packages associated to the configuration - create a new version - save the new configuration
And? I will have to - enter the repo of the external project - fight with a configuration of a project that I do not know, - no thanks - or all the external project should work for real with versioner. - But people will have to look anyway at my changes but in addition they will have a potentially incompatible version (that may be they cannot load in there image).
this will not be to much work (I think I can have it in a couple of days), it will help the process (because eventually everything should be managed through configurations (or PPM configurations), and it will allow us to keep a process that is better and validated..
TL;DR: Better enhance the tools than drop the process.
Which process? Right now what you are proposing is just slowly the remodularisation from my point of view. Because if we have to wait (and we already faced it) that a change goes in rubric and in the rubric configuration so that we can ***continue*** to work. Then we are dead. Because other projects not under our control depend on rubric and I will not fix any of them. I'm sorry I will not work on tools. So I will work on my home projects. Stef
Esteban
On 22 Apr 2015, at 07:47, stepharo <stepharo@free.fr> wrote:
Esteban I was thinking about the following this night.
While I understand that we want configuration only it will slow us down like hell.
Example with guille we wanted to fix a problem (I do not remember which one) we need a change to be done in rubric so we will have to publish the change in rubric repo - (find it and add it) so the rubric repo should be there before - then one guy of rubric should have a look - then merge - then publish an issue with a configuration - then only then we can work => result why do we need sync for me and guille to continue to work??? => what if Alain in on vacation? we stop working? => Remember: We did Pharo especially because people in squeak did not want that we change packages.
Alternate process - we do a fix we publish it in Pharo and yes this touches Rubric and - we integrate it in Pharo head - then the guy from rubric merge in their trunk when they want. it should be part of the their process to merge always with pharo trunk - At that point they can report a problem - then they produce at their speed a new configuration - then we integrate when ready their change
Stef
On Wed, Apr 22, 2015 at 7:47 AM, stepharo <stepharo@free.fr> wrote:
Esteban I was thinking about the following this night.
While I understand that we want configuration only it will slow us down like hell.
Example with guille we wanted to fix a problem (I do not remember which one) we need a change to be done in rubric so we will have to publish the change in rubric repo - (find it and add it) so the rubric repo should be there before - then one guy of rubric should have a look - then merge - then publish an issue with a configuration - then only then we can work => result why do we need sync for me and guille to continue to work??? => what if Alain in on vacation? we stop working? => Remember: We did Pharo especially because people in squeak did not want that we change packages.
Alternate process - we do a fix we publish it in Pharo and yes this touches Rubric and - we integrate it in Pharo head - then the guy from rubric merge in their trunk when they want. it should be part of the their process to merge always with pharo trunk - At that point they can report a problem - then they produce at their speed a new configuration - then we integrate when ready their change
This kind of process will be a pain for those that have to merge the changes back to their repos. I did this for a while when I was synching the debugger repo with Pharo and even if I only had to merge maybe one slice a day it was kind of annoying. Cheers, Andrei
Stef
Le 22/04/2015 10:26, Andrei Chis a écrit :
On Wed, Apr 22, 2015 at 7:47 AM, stepharo <stepharo@free.fr <mailto:stepharo@free.fr>> wrote:
Esteban I was thinking about the following this night.
While I understand that we want configuration only it will slow us down like hell.
Example with guille we wanted to fix a problem (I do not remember which one) we need a change to be done in rubric so we will have to publish the change in rubric repo - (find it and add it) so the rubric repo should be there before - then one guy of rubric should have a look - then merge - then publish an issue with a configuration - then only then we can work => result why do we need sync for me and guille to continue to work??? => what if Alain in on vacation? we stop working? => Remember: We did Pharo especially because people in squeak did not want that we change packages.
Alternate process - we do a fix we publish it in Pharo and yes this touches Rubric and - we integrate it in Pharo head - then the guy from rubric merge in their trunk when they want. it should be part of the their process to merge always with pharo trunk - At that point they can report a problem - then they produce at their speed a new configuration - then we integrate when ready their change
This kind of process will be a pain for those that have to merge the changes back to their repos. I did this for a while when I was synching the debugger repo with Pharo and even if I only had to merge maybe one slice a day it was kind of annoying.
The thing is, if you are not doing it, you're asking someone else to do it for you. So, some of the possibilities are: - Decouple a bit upstream from Pharo/main, not merging everything from there immediately. Wait to see the fixes and changes to stabilize, then extract and merge. - Wait for Pharo/main to pushes fixes to you upstream. So that Pharo/main has a duty of collecting the changes, making them all in a nice pack, and send them your way. A good thing is to adjust the process so that pushing things back and forth is easing the task of everybody involved (motivation!). For example, if an hypothetical Stef (not the true one :)) is changing and fixing things in Rubric inside Pharo/main, it will make merging Rubric newest version harder. So, a good thing would be to make that hypothetical Stef in charge of merging the new Rubric version as well. If he finds it a pain, then he will ease his tasks by sending his fixes nicely packaged to the Rubric maintainer, so that the Rubric manager can merge that with the newest version and send it back to Pharo/main for integration by our hypothetical Stef :) However, it would be allways possible for an external project to make it easier to fix in their project directly than in Pharo/main, but for that they need to be very reactive (make sure that fixes are propagated back very fast in Pharo/main) and make the process as easy as possible for an external contributor... Note that, in such a process, having good tools count. This is one of the reasons for using places like bitbucket or github: they do really support that kind of process (pull requests, branches, issues, server-based merge and CI check, etc...). We could recreate that with http repositories, but with a significant amount of work. Regards, Thierry
Cheers, Andrei
Stef
The thing is, if you are not doing it, you're asking someone else to do it for you.
So, some of the possibilities are:
- Decouple a bit upstream from Pharo/main, not merging everything from there immediately. Wait to see the fixes and changes to stabilize, then extract and merge.
- Wait for Pharo/main to pushes fixes to you upstream. So that Pharo/main has a duty of collecting the changes, making them all in a nice pack, and send them your way.
A good thing is to adjust the process so that pushing things back and forth is easing the task of everybody involved (motivation!).
For example, if an hypothetical Stef (not the true one :)) is changing and fixing things in Rubric inside Pharo/main, it will make merging Rubric newest version harder. Why? As a maintainer of Rubric, you know the system, its current development status. So you can decide when you reconcile with the Pharo version. I would say that Pharo core hackers should not integrate changes in external packages (only in urgence)
So, a good thing would be to make that hypothetical Stef in charge of merging the new Rubric version as well. If he finds it a pain, then he will ease his tasks by sending his fixes nicely packaged to the Rubric maintainer, so that the Rubric manager can merge that with the newest version and send it back to Pharo/main for integration by our hypothetical Stef :)
However, it would be allways possible for an external project to make it easier to fix in their project directly than in Pharo/main, but for that they need to be very reactive (make sure that fixes are propagated back very fast in Pharo/main) and make the process as easy as possible for an external contributor... I do not think that putting the stress on external projects to merge fast is good. Because you can be in the middle of something. Of course with a correct branch it can be simpler but we do not have such tool right now.
Note that, in such a process, having good tools count. This is one of the reasons for using places like bitbucket or github: they do really support that kind of process (pull requests, branches, issues, server-based merge and CI check, etc...). We could recreate that with http repositories, but with a significant amount of work.
Regards,
Thierry
Cheers, Andrei
Stef
Le 22/04/2015 20:05, stepharo a écrit :
The thing is, if you are not doing it, you're asking someone else to do it for you.
So, some of the possibilities are:
- Decouple a bit upstream from Pharo/main, not merging everything from there immediately. Wait to see the fixes and changes to stabilize, then extract and merge.
- Wait for Pharo/main to pushes fixes to you upstream. So that Pharo/main has a duty of collecting the changes, making them all in a nice pack, and send them your way.
A good thing is to adjust the process so that pushing things back and forth is easing the task of everybody involved (motivation!).
For example, if an hypothetical Stef (not the true one :)) is changing and fixing things in Rubric inside Pharo/main, it will make merging Rubric newest version harder.
Why? As a maintainer of Rubric, you know the system, its current development status. So you can decide when you reconcile with the Pharo version. I would say that Pharo core hackers should not integrate changes in external packages (only in urgence)
I agree. What I said is that if Pharo core hackers do not take a bit of time to package and push upstream (i.e. to the external project) their fixes, then it will be hard for the external project maintainer to reconcile Pharo and his stream. Note that as the Rubric maintainer, if I go on holiday for three weeks, I may have to cope with a jump of around 30 to 50 versions of Pharo main to adjust too... If this happens to be the period you go on a fixing bug chase over Rubric, then the merge may be a tad challenging ;)
So, a good thing would be to make that hypothetical Stef in charge of merging the new Rubric version as well. If he finds it a pain, then he will ease his tasks by sending his fixes nicely packaged to the Rubric maintainer, so that the Rubric manager can merge that with the newest version and send it back to Pharo/main for integration by our hypothetical Stef :)
However, it would be allways possible for an external project to make it easier to fix in their project directly than in Pharo/main, but for that they need to be very reactive (make sure that fixes are propagated back very fast in Pharo/main) and make the process as easy as possible for an external contributor...
I do not think that putting the stress on external projects to merge fast is good.
I consider that some external projects sufficiently staffed may want to react this way. Up to them...
Because you can be in the middle of something. Of course with a correct branch it can be simpler but we do not have such tool right now.
In fact, we do. Apart of the github/bitbucket kind of stuff, it is also possible to use smalltalkhub in that way. It's just a matter of organizing your projects and branches (with one smalltalkhub repository per branch). If you organize yourself that way, you'll end up being very close to a git / branch type of approach. Thierry
Ok so this is the way to go for me. At least to try. Le 22/4/15 21:47, Thierry Goubier a écrit :
In fact, we do. Apart of the github/bitbucket kind of stuff, it is also possible to use smalltalkhub in that way.
It's just a matter of organizing your projects and branches (with one smalltalkhub repository per branch). If you organize yourself that way, you'll end up being very close to a git / branch type of approach.
Thierry
Alternate process - we do a fix we publish it in Pharo and yes this touches Rubric and - we integrate it in Pharo head - then the guy from rubric merge in their trunk when they want. it should be part of the their process to merge always with pharo trunk - At that point they can report a problem - then they produce at their speed a new configuration - then we integrate when ready their change
This kind of process will be a pain for those that have to merge the changes back to their repos. I did this for a while when I was synching the debugger repo with Pharo and even if I only had to merge maybe one slice a day it was kind of annoying.
Andrei If we do a change that touch your project you will have to produce a configuration and merge the change anyway. Do not expect me to know what is the head of your project and what I should know. You know your project so you merge the changes we propose. Then you control the speed at which you want to release. Else I will create stupid configuration (in the sense that may be I will break something without even knowing it) and you will have to merge anyway the configurations and the package. Do not dream there is no such alternative. We should go fast to change some structural aspects and avoid to have changes that touch external packages but there is no magic Stef
stepharo wrote
- we do a fix we publish it in Pharo and yes this touches Rubric and - we integrate it in Pharo head
I'm not clear what the best process is, but I wanted to relate an experience I just had updating TxText... Tool-TxWorkspace-TheIntegrator.6 is the version in Pharo 5.0. Its ancestor, which I wanted to copy to the TxText repo, is Tool-TxWorkspace-TorstenBergmann.5. I couldn't find it anywhere. I checked the Pharo40, Pharo50, and Pharo/TxText repos; and then started checking others e.g. sig/TxText. Eventually I found it in the Pharo40Inbox, copied it over, and updated the config. So, for external projects, simply taking changes from the inbox and integrating seems to be a little lacking. Maybe at least copy the packages back to the canonical repos to preserve the ancestry... ----- Cheers, Sean -- View this message in context: http://forum.world.st/Integration-process-in-presence-of-external-project-tp... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
I will soon release a âversioner commit toolâ who will help with this. The process will remain as now: you do your changes you do âcommit version of Xâ (where X can be from âRubricâ to âGTSpotterâ (and in the hopefully not far future even âNautilusâ or, why not âPharo-IDEâ or even âPharoâ) tools will collect packages and configurations and generate new ones, using semver nomenclature. finally, you will copy your âmainâ configuration (the root of your change) to the inbox (same as now). this is the beginning of the end of SLICEd based development. and this is the beginning of a modular era :) This is almost ready and is a good example of incremental changes that produces a fundamental lap (remember ânomads do not build cathedralsâ talk from Marcus): - gofer allows the scripting of commit and load packages - metacello allows us to declare and manage dependences - versionner does a very good job maintaining metacello configurations - version commit tool will allow the automation release pacthes for nested configurations Esteban ps: and when I said almost ready, it is for real: I hope to release an alpha version for testing tomorrow :) pps: sounds bad to put this last tool in the list to the big contributions⦠at the end, is just a small tool on top of really important projects :))
On 27 Apr 2015, at 21:39, Sean P. DeNigris <sean@clipperadams.com> wrote:
stepharo wrote
- we do a fix we publish it in Pharo and yes this touches Rubric and - we integrate it in Pharo head
I'm not clear what the best process is, but I wanted to relate an experience I just had updating TxText... Tool-TxWorkspace-TheIntegrator.6 is the version in Pharo 5.0. Its ancestor, which I wanted to copy to the TxText repo, is Tool-TxWorkspace-TorstenBergmann.5. I couldn't find it anywhere. I checked the Pharo40, Pharo50, and Pharo/TxText repos; and then started checking others e.g. sig/TxText. Eventually I found it in the Pharo40Inbox, copied it over, and updated the config.
So, for external projects, simply taking changes from the inbox and integrating seems to be a little lacking. Maybe at least copy the packages back to the canonical repos to preserve the ancestry...
----- Cheers, Sean -- View this message in context: http://forum.world.st/Integration-process-in-presence-of-external-project-tp... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
On 27 Apr 2015, at 22:19, Esteban Lorenzano <estebanlm@gmail.com> wrote:
I will soon release a âversioner commit toolâ who will help with this. The process will remain as now:
you do your changes you do âcommit version of Xâ (where X can be from âRubricâ to âGTSpotterâ (and in the hopefully not far future even âNautilusâ or, why not âPharo-IDEâ or even âPharoâ) tools will collect packages and configurations and generate new ones, using semver nomenclature. finally, you will copy your âmainâ configuration (the root of your change) to the inbox (same as now).
this is the beginning of the end of SLICEd based development. and this is the beginning of a modular era :)
This is almost ready and is a good example of incremental changes that produces a fundamental lap (remember ânomads do not build cathedralsâ talk from Marcus):
- gofer allows the scripting of commit and load packages - metacello allows us to declare and manage dependences - versionner does a very good job maintaining metacello configurations - version commit tool will allow the automation release pacthes for nested configurations ah, and I forget to mention the other part:
- we have minimal images (6m)⦠and in the future even a bootstrapped minimal image. - we have the capability of ârebuildâ a complete Pharo from a Pharo-minimal image (Pavel just send me this cool link: https://ci.inria.fr/pharo/view/5.0-SysConf/job/Pharo-5.0-ConfigurationOfIDE <https://ci.inria.fr/pharo/view/5.0-SysConf/job/Pharo-5.0-ConfigurationOfIDE>) So the progress is in good shape in both directions :)
Esteban
ps: and when I said almost ready, it is for real: I hope to release an alpha version for testing tomorrow :) pps: sounds bad to put this last tool in the list to the big contributions⦠at the end, is just a small tool on top of really important projects :))
On 27 Apr 2015, at 21:39, Sean P. DeNigris <sean@clipperadams.com> wrote:
stepharo wrote
- we do a fix we publish it in Pharo and yes this touches Rubric and - we integrate it in Pharo head
I'm not clear what the best process is, but I wanted to relate an experience I just had updating TxText... Tool-TxWorkspace-TheIntegrator.6 is the version in Pharo 5.0. Its ancestor, which I wanted to copy to the TxText repo, is Tool-TxWorkspace-TorstenBergmann.5. I couldn't find it anywhere. I checked the Pharo40, Pharo50, and Pharo/TxText repos; and then started checking others e.g. sig/TxText. Eventually I found it in the Pharo40Inbox, copied it over, and updated the config.
So, for external projects, simply taking changes from the inbox and integrating seems to be a little lacking. Maybe at least copy the packages back to the canonical repos to preserve the ancestry...
----- Cheers, Sean -- View this message in context: http://forum.world.st/Integration-process-in-presence-of-external-project-tp... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
On Tue, Apr 28, 2015 at 4:19 AM, Esteban Lorenzano <estebanlm@gmail.com> wrote:
I will soon release a âversioner commit toolâ who will help with this. The process will remain as now:
you do your changes you do âcommit version of Xâ (where X can be from âRubricâ to âGTSpotterâ (and in the hopefully not far future even âNautilusâ or, why not âPharo-IDEâ or even âPharoâ) tools will collect packages and configurations and generate new ones, using semver nomenclature. finally, you will copy your âmainâ configuration (the root of your change) to the inbox (same as now).
this is the beginning of the end of SLICEd based development. and this is the beginning of a modular era :)
This is almost ready and is a good example of incremental changes that produces a fundamental lap (remember ânomads do not build cathedralsâ talk from Marcus):
- gofer allows the scripting of commit and load packages - metacello allows us to declare and manage dependences - versionner does a very good job maintaining metacello configurations - version commit tool will allow the automation release pacthes for nested configurations
Esteban
ps: and when I said almost ready, it is for real: I hope to release an alpha version for testing tomorrow :) pps: sounds bad to put this last tool in the list to the big contributions⦠at the end, is just a small tool on top of really important projects :))
Thanks Esteban. This sounds a good initiative to pull these parts together. I look forward to give it a try. I still maintain there is a need for a tool to merge two Configuration's resultant-set-of-packages (similar to what is done a Slice's dependants) to facilitate parallel paths of development. For context, when reviewing resolved issues, I use Monticello's merge tool to review the individual changes of a Slice before loading it. I also find that list a great reference after loading the Slice. My issue review workflow simultaneously starts two merges and completes one, leaving the other open as a reference. Then I can Browse direct to the affected methods and drop halts in them to get into the debugger to understand what is going on. There is also a broader issue here. Unless I'm missing something, when loading a Configuration we are blind to what the changes will be. This has some small security implications. I envisage merging a Configuration's resultant-set-of-packages *somehow* plugs into the existing merge tool. A Slice's resultant-set-of-packages is directly specified by its dependants list, so where that list is passed for further merge processing of individual packages, at that point I thought we might be able to pass in a Configuration's resultant-set-of-packages -- but I haven't looked into this yet. cheers -ben
On 27 Apr 2015, at 21:39, Sean P. DeNigris <sean@clipperadams.com> wrote:
stepharo wrote
- we do a fix we publish it in Pharo and yes this touches Rubric and - we integrate it in Pharo head
I'm not clear what the best process is, but I wanted to relate an experience I just had updating TxText... Tool-TxWorkspace-TheIntegrator.6 is the version in Pharo 5.0. Its ancestor, which I wanted to copy to the TxText repo, is Tool-TxWorkspace-TorstenBergmann.5. I couldn't find it anywhere. I checked the Pharo40, Pharo50, and Pharo/TxText repos; and then started checking others e.g. sig/TxText. Eventually I found it in the Pharo40Inbox, copied it over, and updated the config.
So, for external projects, simply taking changes from the inbox and integrating seems to be a little lacking. Maybe at least copy the packages back to the canonical repos to preserve the ancestry...
----- Cheers, Sean -- View this message in context: http://forum.world.st/Integration-process-in-presence-of-external-project-tp... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
participants (9)
-
Andrei Chis -
Ben Coman -
Esteban Lorenzano -
Guillermo Polito -
Pavel Krivanek -
Sean P. DeNigris -
stepharo -
Thierry Goubier -
Tudor Girba