Hi -

> Our motivation is twofold
>     -  have first class packages with all the meta-information we  can get:
> package comments, author,... So the changes are just turning PI into  a 
> real object with its own state.

Just out of curiosity is there anything wrong with just extending PI so 
it holds the information you are interested in? It seems to me that its 
name implies that it would be the right place to store meta data like 
you mention. It then seems that the relation between package and pi 
might be something where package holds onto the actual entities but pi 
can be used to "reconstruct" the package in full. In this way you'd have 
the best of both worlds.

>     - having a better browser for Package may be with tabs as in VW  so 
> that in one click
>     we can see the views you mentioned (all the extension of a  package, 
> all the package a class belong to)

 From what I've seen of the VW browser (which is not recent - I think 
the last time I looked at it was at ESUG last year) I wasn't too 
impressed. It felt overloaded and way to crowded with features. If one 
would really want all of these features in a single place an approach 
like StarBrowser would seem more appropriate to me.

But -quite practically speaking- I actually quite like the distribution 
of labour that MC achieves today. Most of the time you spend hacking in 
a browser and occasionally you commit something to a repository. Since I 
always check the changes before I commit it is actually useful to switch 
over to the MC browser, review my changes, and commit them. Personally, 
I feel little need for having the package management directly integrated 
into a browser although I will agree that a little restructuring of the 
tools could help (but so could other things such as being automatically 
notified when a change to a certain repository occurs).

I must also say that while the emphasis on the package items is 
understandable in the new browser there is a danger that it will getting 
into one's way very quickly. For example, how often do you move a method 
from one package to another (this is the first item in the message list 
menu)? Rarely, if ever. It is dangerous to overload the more common 
actions with lots of esoteric things that are rarely used. By the end of 
the day we must understand that the primary purpose of a system browser 
is programming, not package management. The system browser can support 
package management and to the extend it does this is a useful 
side-effect (after all, the choice for going with category prefixes 
originates directly from the desire to have the system browser help us 
with package management) but it's a side effect nonetheless.

So what I'm trying to say here is you walking a very fine line here and 
you need to be careful not to make that new browser so package-centric 
that it is no longer as useful as other browsers for general-purpose 
programming. This should be an interesting exercise and probably needs 
lots of feedback from real users (both novice and expert).

Cheers,
   - Andreas