2016-06-08 11:13 GMT+02:00 Andrei Chis <[email protected]>: > Hi Pavel, > > On Wed, Jun 8, 2016 at 11:05 AM, Pavel Krivanek <[email protected]> > wrote: > >> Hi, >> >> we had in the system circular package dependency between Catalog and >> GTools and we decided to solve it by simple moving of one method from >> one package to other one. However, these two packages are external packages >> managed by configurations. That means that we needed move the method, save >> dirty packages and fix both configurations. >> >> For the catalog we have very simple configuration because it manages only >> one package (and dependency on STON). ConfigurationOfGTInspectorCore was >> more complicated because the repository already included newer development >> version of the modified package so we needed to merge. But because we are >> not the maintainers, we cannot know if the change in this package is not >> requiring changes in other packages provided by the configuration. >> Well, the new configurations were prepared and copied into inbox. We >> needed to create next two issues for updating of the configuration in the >> system. We did it and integrated all together in one update. But that is >> not all... >> ConfigurationOfGTInspectorCore is used by three other configurations ( >> ConfigurationOfGTPlaygroundCore, ConfigurationOfGToolkitCore and >> ConfgurationOfGTDebugger) that specify number of >> ConfigurationOfGTInspectorCore version. In ideal state you should create >> new versions of the configurations but that means that you need to modify >> configurations of all other configurations that use them. It is simpler >> just modify current configuration and upgrade required version number of >> GTInspectorCore. That means to create three next issues, each for one >> configuration, create new configuration versions (and check and merge the >> newer versions in the home repository if needed), copy them to the inbox, >> wait for the review and hope that during integration the Integrator will >> not create new versions of some packages. If yes, you need to update >> configurations again. >> > > Just a quick comment. > Did you edited the configurations and their dependencies by hand? Since > some time I never update them by hand, only use versioner to generate a new > version for ConfigurationOfGToolkitCore and automatically also update all > dependencies to all other configurations that I need. Then I make just one > issue to integrate ConfigurationOfGToolkitCore that also loads/updates all > other configurations. I know this is still not ideal but it's significant > less work than what you described. >
Yes, by hand. I do not use Versionner for packages of others because I'm not 100% sure that it will not break something. -- Pavel > > Chees, > Andrei > > >> So at the end you have at least six issues because you wanted to change >> package for one method that has still the same content and is placed in the >> same class... And it can be worse. Both of these external projects have >> public access to the repository and are managed the same way (not mixing MC >> with GIT). >> >> As you see, it is crazy and unmaintainable. >> >> It is clear that we need to change the process. We need to discuss it >> deeply and some of the results may touch maintainers of the external >> projects integrated in Pharo but please keep in mind that the current >> system is clearly bad. >> >> Cheers, >> -- Pavel >> >> >> >
