On Sep 7, 2012, at 10:08 PM, GOUBIER Thierry 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).
The problem is that even if we would have fixed nautilus to reflect
Package
- tags
benjamin started to do that
we are not sure that all the tools using categories will not produce bugs.
So we decided to see how to stage the effort.
> 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 ?
>
> (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)
>
> 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).
>
> 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.
>
>
>
