June 2014 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Versioner

by Dale Henrichs

On Mon, Jun 30, 2014 at 10:01 AM, kilon alios <kilon.alios(a)gmail.com> wrote: > > ----------Dale------------- > > "Smalltalk with it's heavy reliance on GUI-based tools is not quite as > easy to customize (for several reasons) ... before knickers get knotted, > please keep in mind that I think that customizable GUI-based tools are > important, it's just that the GUI raises the entry level bar a bit higher > than it needs to be... " > > I can't speak for others but I would say that for me is lack of > documentation mainly, I am actually learning Rubric slowly, obviously I > don't code in Pharo full time as some of you nor I have years of experience > in my back, reading and understanding code is a slow process. If those > tools were well documented there would be a lot more people hacking them > and contributing to them since it would lower the steep learning curve > quite substantially. But I can understand that Pharo has not the amount of > people that for example emacs has to provide an in depth documentation > about its tools and libraries and I try to help it to come one step closer. > > I don't think not having GUIs is a problem for me. I did not have issues > working with Metacello . I actually recently started using Versioner and I > use it for the simple stuff, have no issues falling back to metacello if I > have to. Pharo puts emphasis on GUI but it should not be viewed as a > mandatory requirement. I am actually working on making Workspace behave > similar to emacs with as less GUI as possible. There is even a tool to run > a shell terminal inside Pharo and of course we should forget that Pharo > runs from terminal too. > Cool! I really think it is worthwhile exploring the territory "below the GUI" or "with minimal GUI" ... there is no question that a good GUI tool is very useful, but there is a place for the stripped down minimal effort tools as well ... Dale

June 30, 2014

Re: [Pharo-dev] Versioner

by kilon alios

----------------Stephan--------------- "That's fine, you work in a different context than we do. What do you disagree on?" I disagreed with this Stephan "That being said, I am getting a bit nervous about how versioner is released. It should aim to improve the way people can work, and *not* to create a single workflow for all people working on pharo projects. I hope my fears are unfounded." this what I was replying to. "You might have missed a discussion on the Moose list. There Stef proposed to use Versioner to manage the Moose configuration, and use it in a specific way. We noticed some problems, and try to explain where they come from in order to get an improved situation." I have read through it yes, I did not argue that Versioner is perfect. I am actually arguing the opposite, that is a rather basic tool, it gets some basic tasks done but obviously its not the "one ring to rule them all" meaning its up to pharo developers to contribute and improve it or create additional tools to assist with tasks that Versioner can't handle. I disagree that it has an agenda to enforce a single workflow. It is what it is and it can be improved. "Common sense, I hope..." So basically what you saying is that being in a environment ( Pharo ) which is making it easier to create your own IDE tools is not common sense to create your own IDE tools ? You want to join efforts that fine , you want to do it your own way thats fine too, the end result is tools that solve problems. Obviously joining effort is the preferable choice, but doing your own thing is a recipe that Pharo has been based on. I think its great to have these discussion so people are aware of problems before they face them in real life. I definitely would love to read about these problems and plan ahead my actions. If its a problem for Moose people there is no reason to believe it won't be a problem for others in the near future. ----------Dale------------- "Smalltalk with it's heavy reliance on GUI-based tools is not quite as easy to customize (for several reasons) ... before knickers get knotted, please keep in mind that I think that customizable GUI-based tools are important, it's just that the GUI raises the entry level bar a bit higher than it needs to be... " I can't speak for others but I would say that for me is lack of documentation mainly, I am actually learning Rubric slowly, obviously I don't code in Pharo full time as some of you nor I have years of experience in my back, reading and understanding code is a slow process. If those tools were well documented there would be a lot more people hacking them and contributing to them since it would lower the steep learning curve quite substantially. But I can understand that Pharo has not the amount of people that for example emacs has to provide an in depth documentation about its tools and libraries and I try to help it to come one step closer. I don't think not having GUIs is a problem for me. I did not have issues working with Metacello . I actually recently started using Versioner and I use it for the simple stuff, have no issues falling back to metacello if I have to. Pharo puts emphasis on GUI but it should not be viewed as a mandatory requirement. I am actually working on making Workspace behave similar to emacs with as less GUI as possible. There is even a tool to run a shell terminal inside Pharo and of course we should forget that Pharo runs from terminal too.

June 30, 2014

[pharo-project/pharo-core] 091e69: 40055

by GitHub

Branch: refs/heads/4.0 Home: https://github.com/pharo-project/pharo-core Commit: 091e69a4d07cb65c1b95d0972dc08116dd22d64e https://github.com/pharo-project/pharo-core/commit/091e69a4d07cb65c1b95d097… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2014-06-30 (Mon, 30 Jun 2014) Changed paths: A ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script55.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40055.st M ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st A Slot.package/InstanceVariableSlot.class/instance/testing/isSpecial.st A Slot.package/Slot.class/instance/testing/isSpecial.st R Slot.package/SlotClassBuilder.class/instance/deprecated/client_.st M Slot.package/SlotClassBuilder.class/instance/private/apply_.st R System-ObjectStorage.package/extension/SmalltalkImage/instance/storeDataOn_.st M Tool-Profilers.package/MessageTally.class/instance/collecting leaves/leavesInto_fromSender_.st M Tool-Profilers.package/MessageTally.class/instance/comparing/sonsOver_.st M Tool-Profilers.package/MessageTally.class/instance/printing/printOn_.st M Tool-Profilers.package/QSystemTally.class/instance/testing/isPrimitives.st A Tool-Profilers.package/SpaceTally.class/class/fileout/printSpaceAnalysis.st M Tool-Profilers.package/SpaceTally.class/instance/fileout/printSpaceAnalysis.st M Tool-Profilers.package/TimeProfiler.class/instance/accessing-computed/leaveItems.st A Traits.package/TClassDescription.class/instance/slots/usesSpecialSlot.st Log Message: ----------- 40055 13441 Small code critique cleanup in Tools https://pharo.fogbugz.com/f/cases/13441 13442 add test to classes for checking non-ivar slots are used https://pharo.fogbugz.com/f/cases/13442 13443 remove #storeDataOn: from SmalltalkImage https://pharo.fogbugz.com/f/cases/13443 http://files.pharo.org/image/40/40055.zip

June 30, 2014

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/40055 Home: https://github.com/pharo-project/pharo-core

June 30, 2014

Re: [Pharo-dev] Versioner

by Dale Henrichs

On Mon, Jun 30, 2014 at 8:49 AM, Stephan Eggermont <stephan(a)stack.nl> wrote: > Kilon wrote: > >I just don't see it the way you do. > Versioner makes life easier for a specific kind of projects. It is > important to be aware > of its limitations. > > >What stops anyone from implementing his own configuration tool ? > > Common sense, I hope... > Kilon has a point and so does Stephan ... In a programming language where the development environment allows script-based tools (as opposed to GUI-based tools) it is much easier to construct custom "tools" to support variations in workflow ... individual developers routinely copy/share scripts that routinely need to be customized for their environment ... Smalltalk with it's heavy reliance on GUI-based tools is not quite as easy to customize (for several reasons) ... before knickers get knotted, please keep in mind that I think that customizable GUI-based tools are important, it's just that the GUI raises the entry level bar a bit higher than it needs to be... There is room in Smalltalk for plain old-fashioned scripts (workspaces don't quite cut it in this regard) that can be easily shared and customized (and written in Smalltalk) ... anway, some (breakfast) food for thought... Dale

June 30, 2014

Re: [Pharo-dev] Versioner

by Stephan Eggermont

Kilon wrote: >I just don't see it the way you do. That's fine, you work in a different context than we do. What do you disagree on? You might have missed a discussion on the Moose list. There Stef proposed to use Versioner to manage the Moose configuration, and use it in a specific way. We noticed some problems, and try to explain where they come from in order to get an improved situation. >For me Versioner is a tool to make life a bit easier with Configurations, its not "the one ring to rule them all" , far from it. Versioner makes life easier for a specific kind of projects. It is important to be aware of its limitations. >What stops anyone from implementing his own configuration tool ? Common sense, I hope... Stephan

June 30, 2014

caturing key pressed

by Pablo R. Digonzelli

Hi all , I need to capture the key pressed in a Spec TextModel and ListModel. Can someone give orientation? TIA Ing. Pablo Digonzelli Software Solutions IP-Solutiones SRL Metrotec SRL 25 de Mayo 521 Email: pdigonzelli(a)softsargentina.com pdigonzelli(a)gmail.com Cel: 5493815982714

June 30, 2014

Re: [Pharo-dev] Nautilus memory leak/hog crashing Pharo

by Goubier Thierry

I'm trying to see if I could do it in a cleaner way, and I found it! On partial updates, AltBrowser is able to cleanly delete the node morphs because it sends #noteRemovalOfAll: aCollection to MorphTreeMorph, which has the selection testing and removal code. Which means changing MorphTreeMorph>>updateContentsWithPreviouslyExpanded: aNodeList nodeList := nil. self noteRemovalOfAll: self allNodeMorphs. "<-- Changed" (self nodeList isNil or: [ self nodeList isEmpty ]) ifTrue: [ nodeList := nil. ^ self emptySelection ]. self addSubmorphsFromNodeList: self currentNodelist previouslyExpanded: aNodeList It solves the problem. However, I don't like this that much overall, because delete is never sent to the node morphs themselves, and this seems very wrong to me. Thierry Le 30/06/2014 16:56, Goubier Thierry a Ã©crit : > It would solve the selection kept while updating the full list, but it > won't solve partial updates. You would also be apparently deselecting > and reselecting when appending elements to the list. > > Thierry > > Le 30/06/2014 16:15, Nicolai Hess a Ã©crit : >> How about this change, if it rebuilds the whole list, we can savely >> remove the selection, or not? >> >> MorphTreeMorph>> >> addSubmorphsFromNodeList: aNodeList previouslyExpanded: expandedNodeList >> | morphList | >> morphList := OrderedCollection new. >> self >> addMorphsTo: morphList >> from: aNodeList >> withExpandedItems: expandedNodeList >> atLevel: 0. >> self insertNewMorphs: morphList. >> self listManager emptySelection. "<--- >> added" >> self listManager updateSelectionFromModel. >> self roots do: [:r | r updateChildrenRecursively]. >> self updateColumnMorphs >> >> >> >> >> 2014-06-30 15:35 GMT+02:00 Goubier Thierry <thierry.goubier(a)cea.fr >> <mailto:thierry.goubier@cea.fr>>: >> >> Ok, I have the test case showing the problem. >> >> | c w t | >> c := ClassTreeExample new. >> w := c openOn: Collection. >> t := c dependents last. >> t expandAll. >> t selectAll. >> c updateList. >> t listManager selectedMorphList do: [ :each | self assert: ( t >> allNodeMorphs includes: each ) ] >> >> Fail on the final assert. Switching to single selection hold the >> same error. >> >> Interestingly, reselecting cleans the selectedMorphList. >> >> | c w t | >> c := ClassTreeExample new. >> w := c openOn: Collection. >> t := c dependents last. >> t expandAll. >> t selectAll. >> c updateList. >> t setSelectedMorph: t allNodeMorphs first. >> t listManager selectedMorphList do: [ :each | self assert: ( t >> allNodeMorphs includes: each ) ] >> >> This one has no error. >> >> Changing the way Nautilus maintain the selection would work. Forcing >> selectedMorphList to be cleaned up on addition / removal in the list >> would be nice too (but possible update code can delete the node >> morphs by itself). >> >> Thierry >> >> >> Le 30/06/2014 10:15, Johan Brichau a Ã©crit : >> >> Hi Nicolai, >> >> >> Do you have a method selected in the browser? >> As the memory leak happens via the selectedMorphs instvar, it >> requires a package to be selected (and maybe even a method). >> >> Before and after the load. I do this and notice the increase. >> >> Smalltalk garbageCollect. >> MorphTreeNodeMorph allInstances size. >> >> It really only becomes problematic (i.e. out-of-mem) when you >> load large projects. Maybe MOOSE will qualify? >> >> Yes, I was astonished as well when I noticed that every update >> was rebuilding the entire set of Morphs. It's the easiest >> solution of course but it does impose a lot of overhead. >> First, I will see how to solve that leaking problem. Then I will >> take a look at the update itself. >> >> I can only spend some of my free time on this, so I will >> continue tonight. >> >> best, >> Johan >> >> On 30 Jun 2014, at 09:09, Nicolai Hess <nicolaihess(a)web.de >> <mailto:nicolaihess@web.de>> wrote: >> >> 2014-06-29 22:31 GMT+02:00 Johan Brichau <johan(a)inceptive.be >> <mailto:johan@inceptive.be>>: >> >> On 27 Jun 2014, at 14:00, Goubier Thierry >> <thierry.goubier(a)cea.fr <mailto:thierry.goubier@cea.fr>> >> wrote: >> >> It seems to depend on the Nautilus window state. If >> you've just opened it, then nothing seems to be amiss. >> If you start to select things in it, you start to see >> time spent in updateClassView, but why? >> >> >> I just found that the instances are being kept by the >> MorphTreeListManager#__selectedMorphs instvar. So, that >> observation is correct: you need to have a package selected. >> >> What seems to happen is that on every package load, the >> Nautilus package tree is updated (which means a >> PackageTreePackageNodeModel is created for each package in >> the image via #asNautilusNodeWithModel:). >> This update does not clear the selectedMorphs list and just >> this single reference seem to keep the entire package tree >> model and its Morphs in memory. >> >> There were 496 morphs in the selectedMorphs list and when I >> cleaned that, all trailing Morphs and PackageNodeModelNodes >> (and all the other garbage) could be gc'ed. >> >> On to investigating the growth of the selectedMorphs >> variable... >> >> Johan >> >> >> Yes, we had quite some bugs with this package tree update >> in the past. What I don't understand is, why >> is the whole tree removed and rebuild, maybe this is a >> common strategy in Morphic, update a list ore tree >> will always rebuild the whole morph structure? But it >> happens even if the structure is the same and >> just this little package/dirty package icon is updated. >> >> Another issue is this "selected package/package selection". >> The tree (and for example the >> category list and/or method list" as well), stores the >> selection on multiple ways, in the model >> (PackageTreeNautilus), the >> UI (PackageTreeNautilusUi) and the treelist morph. Once as a >> SelectedTreeNode, a Package from Nautilus Model and >> once as a PackgeTreeSelection/__PackageTreeTagSelection. >> I find it pretty confusing. >> >> >> BTW, I still can not reproduce this memory leak behavior. I >> tried this: >> >> [ Gofer new smalltalkhubUser: 'ObjectProfile' >> project: 'Roassal2'; >> package: 'ConfigurationOfRoassal2'; >> load. >> (Smalltalk at: #ConfigurationOfRoassal2) load ] timeToRun. >> >> with and without an open SystemBrowser. But the load time and >> memory consumption is the same. >> >> >> Nicolai >> >> >> >> >> >> >> >> -- >> Thierry Goubier >> CEA list >> Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s >> 91191 Gif sur Yvette Cedex >> France >> Phone/Fax: +33 (0) 1 69 08 32 92 >> <tel:%2B33%20%280%29%201%2069%2008%2032%2092> / 83 95 >> >> > -- Thierry Goubier CEA list Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95

June 30, 2014

Re: [Pharo-dev] Nautilus memory leak/hog crashing Pharo

by Goubier Thierry

It would solve the selection kept while updating the full list, but it won't solve partial updates. You would also be apparently deselecting and reselecting when appending elements to the list. Thierry Le 30/06/2014 16:15, Nicolai Hess a Ã©crit : > How about this change, if it rebuilds the whole list, we can savely > remove the selection, or not? > > MorphTreeMorph>> > addSubmorphsFromNodeList: aNodeList previouslyExpanded: expandedNodeList > | morphList | > morphList := OrderedCollection new. > self > addMorphsTo: morphList > from: aNodeList > withExpandedItems: expandedNodeList > atLevel: 0. > self insertNewMorphs: morphList. > self listManager emptySelection. "<--- > added" > self listManager updateSelectionFromModel. > self roots do: [:r | r updateChildrenRecursively]. > self updateColumnMorphs > > > > > 2014-06-30 15:35 GMT+02:00 Goubier Thierry <thierry.goubier(a)cea.fr > <mailto:thierry.goubier@cea.fr>>: > > Ok, I have the test case showing the problem. > > | c w t | > c := ClassTreeExample new. > w := c openOn: Collection. > t := c dependents last. > t expandAll. > t selectAll. > c updateList. > t listManager selectedMorphList do: [ :each | self assert: ( t > allNodeMorphs includes: each ) ] > > Fail on the final assert. Switching to single selection hold the > same error. > > Interestingly, reselecting cleans the selectedMorphList. > > | c w t | > c := ClassTreeExample new. > w := c openOn: Collection. > t := c dependents last. > t expandAll. > t selectAll. > c updateList. > t setSelectedMorph: t allNodeMorphs first. > t listManager selectedMorphList do: [ :each | self assert: ( t > allNodeMorphs includes: each ) ] > > This one has no error. > > Changing the way Nautilus maintain the selection would work. Forcing > selectedMorphList to be cleaned up on addition / removal in the list > would be nice too (but possible update code can delete the node > morphs by itself). > > Thierry > > > Le 30/06/2014 10:15, Johan Brichau a Ã©crit : > > Hi Nicolai, > > > Do you have a method selected in the browser? > As the memory leak happens via the selectedMorphs instvar, it > requires a package to be selected (and maybe even a method). > > Before and after the load. I do this and notice the increase. > > Smalltalk garbageCollect. > MorphTreeNodeMorph allInstances size. > > It really only becomes problematic (i.e. out-of-mem) when you > load large projects. Maybe MOOSE will qualify? > > Yes, I was astonished as well when I noticed that every update > was rebuilding the entire set of Morphs. It's the easiest > solution of course but it does impose a lot of overhead. > First, I will see how to solve that leaking problem. Then I will > take a look at the update itself. > > I can only spend some of my free time on this, so I will > continue tonight. > > best, > Johan > > On 30 Jun 2014, at 09:09, Nicolai Hess <nicolaihess(a)web.de > <mailto:nicolaihess@web.de>> wrote: > > 2014-06-29 22:31 GMT+02:00 Johan Brichau <johan(a)inceptive.be > <mailto:johan@inceptive.be>>: > > On 27 Jun 2014, at 14:00, Goubier Thierry > <thierry.goubier(a)cea.fr <mailto:thierry.goubier@cea.fr>> wrote: > > It seems to depend on the Nautilus window state. If > you've just opened it, then nothing seems to be amiss. > If you start to select things in it, you start to see > time spent in updateClassView, but why? > > > I just found that the instances are being kept by the > MorphTreeListManager#__selectedMorphs instvar. So, that > observation is correct: you need to have a package selected. > > What seems to happen is that on every package load, the > Nautilus package tree is updated (which means a > PackageTreePackageNodeModel is created for each package in > the image via #asNautilusNodeWithModel:). > This update does not clear the selectedMorphs list and just > this single reference seem to keep the entire package tree > model and its Morphs in memory. > > There were 496 morphs in the selectedMorphs list and when I > cleaned that, all trailing Morphs and PackageNodeModelNodes > (and all the other garbage) could be gc'ed. > > On to investigating the growth of the selectedMorphs variable... > > Johan > > > Yes, we had quite some bugs with this package tree update > in the past. What I don't understand is, why > is the whole tree removed and rebuild, maybe this is a > common strategy in Morphic, update a list ore tree > will always rebuild the whole morph structure? But it > happens even if the structure is the same and > just this little package/dirty package icon is updated. > > Another issue is this "selected package/package selection". > The tree (and for example the > category list and/or method list" as well), stores the > selection on multiple ways, in the model > (PackageTreeNautilus), the > UI (PackageTreeNautilusUi) and the treelist morph. Once as a > SelectedTreeNode, a Package from Nautilus Model and > once as a PackgeTreeSelection/__PackageTreeTagSelection. > I find it pretty confusing. > > > BTW, I still can not reproduce this memory leak behavior. I > tried this: > > [ Gofer new smalltalkhubUser: 'ObjectProfile' > project: 'Roassal2'; > package: 'ConfigurationOfRoassal2'; > load. > (Smalltalk at: #ConfigurationOfRoassal2) load ] timeToRun. > > with and without an open SystemBrowser. But the load time and > memory consumption is the same. > > > Nicolai > > > > > > > > -- > Thierry Goubier > CEA list > Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s > 91191 Gif sur Yvette Cedex > France > Phone/Fax: +33 (0) 1 69 08 32 92 > <tel:%2B33%20%280%29%201%2069%2008%2032%2092> / 83 95 > > -- Thierry Goubier CEA list Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95

June 30, 2014

Re: [Pharo-dev] Versioner

by kilon alios

I just don't see it the way you do. For me Versioner is a tool to make life a bit easier with Configurations, its not "the one ring to rule them all" , far from it. What stops anyone from implementing his own configuration tool ? On Mon, Jun 30, 2014 at 10:23 AM, Diego Lont <diego.lont(a)delware.nl> wrote: > I am afraid this mail is going to be too long, but I feel it needs to be > written. I will start with the conclusion, so you can skip the mail if you > feel it does not interest you. Please keep the discussion on the Moose > list, as there the discussion was started. > > I am very happy that versioner is being built. We need more and better > software configuration tools, and versioner will make our life easier. That > being said, I am getting a bit nervous about how versioner is released. It > should aim to improve the way people can work, and *not* to create a > single workflow for all people working on pharo projects. I hope my fears > are unfounded. > > Software configuration management (SCM) is in my opinion an undervalued > topic within the software world. One cannot find very many good books on > them, and I am afraid this lack of knowledge shows in the way people go > around with their SCM. So I would like to write down some observations of > the SCM processes in Pharo that I believe we should keep in mind. > > The main target of SCM is to keep the impact of changes as minimal as > possible. Good SCM allows all people working on a certain project, to make > their changes, without causing trouble for other project members and people > using this project. Open source projects are (in SCM terms) rather complex, > as they involve a lot of people, including some people we do not know. > > 1. One of the best things of Metacello is that it does not require you to > follow a certain workflow. It is very flexible and supports a large range > of possible workflows. Within the Pharo community we have at least 3 > different workflows: > A. For Pharo core, we have a pharo inbox, where suggested fixes for > reported bugs are put. These fixes are reviewed and, if accepted, > integrated into Pharo. This ensures that the changes in Pharo hold (most of > the time) to quite some quality standards. > B. For the âcross-platformâ projects (Grease, Seaside, Magritte, etc.) all > suggested fixes are put in the main repository on smalltalkhub. The fixes > are, after review and tests, released by putting them in a âreleasedâ > version of the configuration. Since not all fixes should be in all > versions, and sometimes only concern a certain platform, the process for > Pharo core would not work: releasing fixes are more complex because of the > cross-platform issues. > C. For the âmooseâ projects all suggested fixes are put in the main > repository and are accepted by default. Since most projects evolve very > fast, quality assurance is done afterwards, by submitting bug fixes. > > I can say a lot about why I believe these workflows are appropriate for > their different projects, but the point I am trying to make here, is that > these workflows have come to existence because of the different demands on > them. And to stress my point about the flexibility (thank you Dale): > When there was a problem with the workflow in the cross platform projects, > I could find a solution (using releases) that Metacello supported. > > 2. Unfortunately Metacello does not have a good UI. And for large > configurations like Seaside, it is a lot of work to keep them maintained. I > dream of a tool that acts as a UI for Metacello: this tool is flexible as > Metacello, while making the simple things real easy (hitting a button and > done). Does versioner aim to do this? > > 3. I always get very nervous when someone says: They do it like this, and > that works very well for them. So we should do that too. I do not believe > that is always a good idea. The conclusion should be a question: Can we use > that too? And now I cannot find the mail about the java SCM practice, but I > do not think we can apply it to all our processes ... > > 4. Modularity is very important. Also for performing good SCM. And yes, we > lack sufficient modularity in Moose. It should be better. I.e. because of > the lack of modularity, it is sometimes hard to distinguish between where > the change needs to be put in. So there is no clear group to point out who > should accept the changes. So this is also an SCM problem. > > Cleaning up the configuration will help here very much. Thank you Steff > for the good work here. And maybe you also have a point that the people > working on Moose should have more focus on keeping things modular, because > it makes the system better maintainable in a lot of ways. > > 5. Forking things will only make SCM worse, as it adds a complexity. So I > very much hope we can come to an agreement how the process works, without > resorting to drastic measures. > > Regards, > Diego >

June 30, 2014