On Sep 8, 2012, at 12:41 AM, GOUBIER Thierry wrote: > :). RPackage and Monticello are already too coupled :)
No they are layered. Monticello RPackage and not the inverse. > I believe some of the problems are in the way Monticello is working (as far > as I can gather from tracing RPackage(1) bugs). > > In my opinion, there are two problems : > > 1 - Choosing between RPackage(1) and RPackage(2). RPackage(2) adds one level > of organisation, if I understand correctly (RPackageSet contains RPackages > which contains tags, no ?). We would not need tags with this scenario. In scenario 2 RPackage are first class categories handling class extension. > Both are very similar, I'd judge RPackage(2) a bit better (one more level; > I'd like to have more levels in truth). The thing is, if the problem with > RPackage(1) is a hard one, then I don't see how RPackage(2) will solve it. > 2 - Maintaining the same decisions as Monticello in RPackage(1) or > RPackage(2) when it comes to classifying code. This is for me the hard one. > Monticello has carefully, over apparently quite some time and many versions > and implementations, fine tuned a way of matching unstructured, semi formal > meta-data (Smalltalk categories and protocols) to "packages" (even with > apparently overlapping packages ?). Reproducing that very same behavior in > another structure-adding tool is a challenging task I would have considered > as hard, up to very hard. I do not think so. This is just that we decided to be backward compatible. Personnally I would have just throw away categories. We do not need them. But we are like poor people wanted to be rich, we do not have the money but we want more stuff. > There is also a body of adding additional hierarchy levels in MCPackages by > carefully naming packages with well chosen prefixes and - (System-whatever > for example), which points out to the fact packages developpers need at least > one more level of hierarchy. This is why in the first design we added tags. > (Remember that I wrote code extracting a hierarchical view of the full system > out of both PackageInfo/Monticello and RPackage and it worked in both cases, > even if RPackage was my favorite instead of trying to reproduce Monticello > decisions) > > Now, there is the fact RPackage touches the core of the code management > system, and that it intends to replace the for ever old classification > system, and then... I'll keep a critic role, I'm not good enough :-) But I > wish RPackage to succeed :) Thanks :) > If you want to see how one could view the RPackage(1) world, try one of the > latest AltBrowser versions. It looks and feel great, even if still buggy. > That's why I would really be disappointed if it goes through the same pain a > second time. I think that we should let esteban experiment and we will discuss again to see. Frankly I do not like the pattern-matching semantics and I understand that we do not want an explosion of packages so let us give a bit more time and see. > Thierry > > ________________________________________ > De : [email protected] > [[email protected]] de la part de Esteban Lorenzano > [[email protected]] > Date d'envoi : vendredi 7 septembre 2012 23:18 > À : [email protected] > Objet : Re: [Pharo-project] RE : RE : RPackage, Monticello and the > removal of PackageInfo > > On Sep 7, 2012, at 11:04 PM, GOUBIER Thierry <[email protected]> wrote: > >> I will be a bit harder to convince then. 1 MCPackage = N RPackage doesn't >> strike me as any better than 1 MCPackage = 1 RPackage with tags, apart from >> performance issues. Remember that I was using option 1 in depth and hitting >> bugs, but not that much. >> >> My opinion is that you don't really know what went wrong with option 1, >> except the implementation became unmanageable. So, I expect option 2 to be >> hardly better, sadly. And, as it promises breaking existing configurations, >> it will be a lot more fun ! > >> Yeah, probably I'm just not smart enough... I'm sorry not being at the >> required level, I just do my best. But then, this was largely discussed in >> the team, with Marcus, Guille, Camillo and Mariano (and also with Stef, >> btw)... we discussed the problem and together we decided the path to follow. > >> >> By the way, if you enlarge the vision with RPackage, and think about the >> size of the overall system and how it has evolved a lot since the class >> categories of the beginning of Smalltalk, then your option 2 is, for me, >> already obsolete. You need more levels than the two you are promising with >> option 2. Scrolling throught thousands of categories is not fun; having >> packages which add hundreds of methods as an extension to a class is clearly >> not scalable and manageable. And scrolling through hundreds of package isn't >> either (or are you all working on 30" screens ? I'm not.). >> >>> That just don't work. If we remove monticello from SA, monticello doesn't >>> know what changed and needs to >reconstruct every time its state... which >>> also means that monticello gui cannot be updated either. >> >> This is wrong, since RPackageOrganizer, being aware of the changes, could >> update monticello and maintain a coherent view. It would have made the >> situation a tiny bit better. > > By coupling RPackageOrganizer with Monticello. Nice piece of design :) > > Esteban > >> >> Thierry >> ________________________________________ >> De : [email protected] >> [[email protected]] de la part de Esteban >> Lorenzano [[email protected]] >> Date d'envoi : vendredi 7 septembre 2012 22:37 >> À : [email protected] >> Objet : Re: [Pharo-project] RE : RPackage, Monticello and the removal >> of PackageInfo >> >> Hi, >> >> On Sep 7, 2012, at 10:08 PM, GOUBIER Thierry <[email protected]> wrote: >> >>> It's hard to converse with that Exchange webmail. Oh, Ok, here it goes. >>> >>> The one MCPackage _ One RPackage I'm Ok with, I made that working with my >>> browser. But if this is the goal, then the current code is almost there and >>> option 2) isn't needed ? A RPackage (the one with tags) clearly represent >>> well what a MCPackage can be, bugs apart. (technically, it's a bit wider, >>> since extension methods may belong to any protocol, not just the >>> *PackageName : the AltBrowser consequently hides the extension name, which >>> is interesting at the GUI level and works very well). >> >> That's not the goal... that *was* the goal. The goal is to have a good >> representation of the system with RPackage. >> And no, we were not close, we were very far away to be close. >> Here is the thing 1 MCPackage = 1 RPackage breaks everything. Tags are just >> tags and don't have coherence with Class Categories. >> Now, 1 MCPackage = N RPackage has much more sense because stresses a lot >> less the system. >> >> Now, what Stef is saying is that we wanted 1 to 1 correspondence, but a lot >> larger granularity... that means MCPackage matching current class >> categories. Not the opposite... but that means we need to ask everybody to >> adapt their monticello and configurations to match that vision, and that's >> something that it's not going to happen, not just because, for instance, >> Seaside has already tons of packages, do you imagine with the proposed >> granularity? >> Also, Versionner or other tools can help to reduce the fear to that >> granularity in the future, but that's not going to happen tomorrow. >> >> So, I'm really sorry your work was almost ported and we changed the rules... >> and I'm sorry that while looking for the best solution for everybody we some >> times break somethings, but that's are the risks of developing over bleeding >> edge :( >> >>> >>> The only thing needed is to make sure than when Monticello says X belongs >>> to MCPackage A, that RPackageOrganizer doesn't say that X belongs to >>> RPackage B instead, and the reverse. There is a fault in the RPackage >>> introduction there, which is that both RPackageOrganizer and Monticello are >>> tracking system announcements, and giving them different meanings (and >>> RPackage propagate its changes to Monticello). I am at around 10 Pharo >>> images I had to scrap because the damage done by those bugs was beyond >>> repair. >>> >>> When you say force people to have one class category, one RPackage, that I >>> do not understand why. As stated above, you have everything to handle >>> multiple class categories in a RPackage. Why add a RPackageSet layer above >>> ? Why make the transition break that ? >> >> "Force" is a strong word. We don't force anyone... RPackage is a >> construction with a purpose, not a general malleable tool. It is not a tool >> to create your package with your desired format. Is a way to represent the >> fact that system is composed from classes, who are grouped in units called >> categories. Categories are there for the human eye, not for the system... >> now, the common convention around those categories is that you see them in >> class declaration, as class categories, and in browser "packages" panel. >> Monticello packages, in other term, are conceptually collections of class >> categories packaged together. >> So... for me is important to maintain that notion. >> Now, there are two point of views: >> 1) you have a new completely different infrastructure (aka RPackage+tags) to >> represent system, and then adapt (I can say "force" too) all the tools to >> this (which is a lot of work). For me it looks like a hack (we have >> something and we force the tools to show other thing, just because), and >> also no real necessity to do it, or >> 2) we took our new packaging system and make it work in the most simplest >> way possible, focusing on maintain the system as close to the eyes as >> possible. RPackageSet represents a notion for Monticello packages grouping >> packages (and btw, it can disappear in the future, because RPackageSet >> responsibility belongs most probably to regular MCPackages), and RPackage >> instances who matches to what users expect most probably about the >> organization categories in their system. >> >> Our error was trying to take approach 1 first... not take path approach 2 >> now... and it was an error because after one month of working on that >> direction, the system was more and more unstable and chaotic and complex, >> and not what it should happens, which was the opposite. >> >>> >>> (RPackage is not, in my opinion, naming agnostic. The main bugs I found in >>> RPackage are because someone believe it is, where it isn't) >> >> you're right, it is not. >> >>> >>> One thing I would suggest is : remove Monticello from system announcements. >>> Make RPackageOrganizer in charge of updating the MCWorkingCopy as needed >>> (have a coherent view of the system). >> >> That just don't work. If we remove monticello from SA, monticello doesn't >> know what changed and needs to reconstruct every time its state... which >> also means that monticello gui cannot be updated either. >> >> Esteban >> >>> >>> Thierry >>> >>> ________________________________________ >>> De : [email protected] >>> [[email protected]] de la part de Stéphane >>> Ducasse [[email protected]] >>> Date d'envoi : vendredi 7 septembre 2012 21:37 >>> À : [email protected] >>> Objet : Re: [Pharo-project] RPackage, Monticello and the removal of >>> PackageInfo >>> >>> On Sep 7, 2012, at 8:44 PM, GOUBIER Thierry wrote: >>> >>>> Ok, >>>> >>>> It's good to know, because, for me, as I was / I am trying to track the >>>> changes in RPackage for the past two weeks, it seemed that RPackage was >>>> happily oscillating between 1 and 2, and, to add to the fun, backporting >>>> it's instability by creating spurious packages in Monticello on the way. >>>> >>>> Oh well, I almost managed to stabilize on 1), now I'll have to recode for >>>> 2). Should have stuck to PackageInfo :-(. >>> >>> >>> you are not the only one. Benjamin too. >>> Now we are fighting with it and this is just not for fun. >>> >>> >>>> Is there a plan to have clear semantics of the different matches planned >>>> (extension categories and sub categories, class category, package >>>> sub-category) ? >>> >>> Yes >>> Ideally we want >>> one MCPackage - one RPackage + tags >>> >>> Nothing more (no class category, no package info). >>> Now we should be able to remove class categories. >>> But this does not work easily because everybody would have to rewrite >>> configurationOf for their projects (since each categories would be turned >>> into a package). >>> So may be when versionner will be working we can add a behavior to migrate >>> automatically configuration. >>> >>> >>> So esteban will see if his idea is working which leads to a first class >>> category and we can in a second period go more towards >>> one MCPackage - one RPackage with tagged classes. >>> >>>> Monticello has already set a few conventions (not case sensitive, for >>>> example) (and they are not respected by quite a few packages) and not a >>>> few of the RPackage bugs are linked to it not respecting it (i.e. some >>>> methods of package matching in RPackage are case sensitive, whereas they >>>> are not in MCWorkingCopy) ? >>> >>> You forgot to add "crap in PackageOrganizer." >>> So yes it would be good to clean all that. >>> RPackage is totally agostic to naming conventions but we have to create >>> them and support backward compatibility. >>> >>> >>> >> >> >> > > >
