> On 09 Jun 2016, at 10:03, Denis Kudriashov <dionisi...@gmail.com> wrote: > > So does we all agree to commit fixes for external packages by slices without > new configs?
that would break the bootstrap process, so no. Esteban > > 2016-06-09 9:42 GMT+02:00 Pavel Krivanek <pavel.kriva...@gmail.com > <mailto:pavel.kriva...@gmail.com>>: > > > 2016-06-08 19:40 GMT+02:00 stepharo <steph...@free.fr > <mailto:steph...@free.fr>>: > ***THANKS*** Pavel. > > Yes it is the best way to make sure that nobody wants to work at this level. > We discussed this problem during the last board meeting. This is why I > proposed the following process. > > When the core Pharo developers are in need to change a package they should do > it without updating the external package configurations. > And the external developers should check and merge the changes from the Pharo > repo and when they want > release a new configuration that we will integrate. > > But the problem is that for bootstrap we need updated configurations (or > somenting like it) because we want to load all system correctly from them. So > even for such small changes we need to update them somehow. Moreover, we want > to test incomming slices with bootstrap. That means that for every new slice > we need to create temporary configurations and run bootstrap-load process on > them. > > So it is clear that we need configurations that will be created and managed > automatically and will enable swapping of repositories. We had already > several discussions on this theme and from my point of view we need: > > - own separate repository for every semi-external project. So something like > fork for Pharo. With GIT it will be natural, for the management by MC it will > be only a temporary step. > > - own configuration that will be aware only of Pharo and will be fully > automatically managed > > Pharo developers will provide only slices and will not care about > configuraitons at all. It will mean that maintainers of semi-external > projects will loose part of the controll and will need to care of sync with > own development repository but it is nothing new. Even now Pharo makes own > forks of some projects but it is not so visible. > > > For me this is clear (for example for the icon: fix) I do not do anything if > this is with the process you describe because it is insane. > In fact fixing this process is part of the job description for your position. > > It was > - republishing automatically changes and the configuration > > - working on package validation (making sure that the catalog does not > get full of not working project) > - bootstrap :) > > > Of course I am aware of it :-) > > -- Pavel > > Stef > > Le 8/6/16 à 11:05, Pavel Krivanek a écrit : >> 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. >> >> 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 >> >> > > >
