Package maintenance

ducasse ducasse at iam.unibe.ch
Thu Oct 9 10:20:39 UTC 2003


>
>> Not everybody I guess. Why the changeset sorted then is still using
>> changeset and remove? When I harvest I only get cs and not mcv. When I
>> click on changeset sorter mail to the list I send a changeset. So this
>> means that behind the scene the nice harvester would have to dispatch
>> the changes to packages.  My point is that people should realise that
>> having just a layer of packages does not scale for the harvesting
>> process and maintenance of external packages. May be I'm wrong....
>
> Why doesn't it scale?  If we decided to harvest based on packages 
> instead
> of changesets, we could do exactly that without too much trouble.  
> Daniel
> and I have talked serveral times about setting exactly that up.  I 
> think
> it's a great direction to go.

this would be much better for my point of view too. I think that this 
is important
that this discussion happens in the community, even if it may hurt a 
bit.

> You misunderstood me - I wasn't being sarcastic, but genuinely looking 
> for
> feedback.  Monticello *does* suck, or rather is incomplete.  What I 
> want
> is for you to try to use it and tell me which parts that are missing 
> are
> hurting your efforts the most, and should be addressed first.

Ok I will try to use it.

>> I'm just saying that there is a guy (not an easy one sure) that works
>> over 15 years in envy, package.... management wrote books, works on 
>> big
>> industrial projects that will release a meta-model for code and that I
>> do not want to reinvent that. (because I already did that for my
>> research and this is enough for me).
>
> Stef, if you really want to have this argument, let's make it 
> technical,
> not personal.  We all know that Joseph is an experienced professional -
> much more experienced than I am, for example.  We all know he does good
> work.  But what is it that you actually want from Ginsu that you're not
> getting elsewhere?  What, specifically, does the code we have available
> for Ginsu do, that the code we have available for Monticello doesn't?

Ok I will look at it because the last time I looked at monticello meta 
model was because
it was named monticello

> Again, I'm not asking rhetorically.  I genuinely want to know.
OK

> Great.  Why?  What do you miss from StORE or ENVY?
>
> Stef, forgive me if I seem to be coming on strong.  I know you won't be
> offended by it...

I'm not and you are right. I will do an analysis then during my 
holidays in two weeks.

But just thinking about it as an end user. I want a browser with 
package and not naming conventions.
I want to know which packages I changed when I programmed or refactored 
the system.
I want to have bundle/cluster that says ok all those change below 
together and
I should load version 1.1 of x and 2.3 of z. May be this is the job 
that will be done by
SM2.0.
  But this is genuine wishes :)



More information about the Squeak-dev mailing list