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 >>> >>> >> >