Hi goran

>
> Daniel Vainsencher <danielv at netvision.net.il> wrote:
>> Loading this package reloads all the packages unloads. If you want to
>> work on a Full image, as you stated, this will help.
>
> Right.
>
>> I've stated before that I don't think that's the solution - I think 
>> that
>> refactoring an image with any subset of SM package will break some
>> stuff. Working in Full will make you generate patches to lots of
>> packages. This is good, if you intend to help the maintainer of each
>> package integrate it. Otherwise, it's a waste of time.
>
> Exactly. The point here is that changes you do to packages (that you 
> are
> not signed up as maintainer of) should be sent to the maintainer of 
> that
> package.

But my problem is currently that I do not know up front to which package
a change I'm doing should go.

After all I have no problem discarding the changes I did for the 
removal but this
is still silly.


> DVS makes this simpler - but all packages are not maintained using DVS.
> We could start thinking about forcing all "official" Squeak packages to
> use DVS of course.
>
> Using that you would simply hack away with the packages installed. Then
> those packages that get a little "*" in the Packagepanel have been
> "touched" and you would simply press "Fileout" on those and send those
> .st files to the appropriate maintainer.
>
> He/she could then (Avi?) probably use DVS to produce a ChangeSet from
> those fileouts in order to see what the changes are etc. And then
> integrate and release a new version.
>
>
>> Either way, don't feel free to deprecate anything you don't think is
>> used, because you *don't* have a closed world. Give consideration to
>> what you remove/deprecate.
>
> Exactly - and this includes *more* than what is in the current 3.5
> (before the removals came).

I do not get what you say here. Use or unused is not a criteria
for deprecation. For the moment we are focusing on illness ;)

Stef