--- El vie 13-feb-09, Igor Stasenko <siguctua at gmail.com> escribió:

> De: Igor Stasenko <siguctua at gmail.com>
> Asunto: Re: [squeak-dev] Re: SqueakMap Status?
> Para: "The general-purpose Squeak developers list" <squeak-dev at lists.squeakfoundation.org>
> Fecha: viernes, 13 de febrero de 2009, 3:53 pm
> 2009/2/13 Adrian Lienhard <adi at netstyle.ch>:
> >
> > On Feb 13, 2009, at 18:06 , Keith Hodges wrote:
> >
> >>
> >>> Somehow I got amiable through Keiths Mail to
> the pharo list. He was
> >>> blaming the pharo crew for not caring about
> squeak and things/fixes
> >>> others do. That was exactly the reason back
> then for me to fix it in
> >>> pharo and then open a bug on mantis as well.
> So it turns out that the
> >>> integrational aspect doesn't work in
> either direction.
> >>>
> >> It would work fine if....
> >>
> >> SqueakMap was treated as an external package to
> both squeak and pharo,
> >> and the repo, or at least a repo is available to
> any contributors that
> >> want to improve things.
> >
> > [...]
> >
> >> If in the case of SqueakMap situation mentioned
> you "fixed it in pharo"
> >> then that means there is likely to be a new SMBase
> with your initials on
> >> it, where is it? If it is languishing in a pharo
> repository, then that
> >> simply illustrates my point. Namely, that pharo
> should conceptually
> >> treat external packages as external packages, and
> contributors should be
> >> encouraged to improve such external packages for
> everyone. e.g. tell the
> >> maintainer what is going on, and check your
> changes back in to the main
> >> development stream... isn't it rude not to?
> >
> > For version 1.0 we've planned to remove SqueakMap
> from the Pharo core and
> > treat it as an external package.
> >
> >> My complaint against pharo is that while the rest
> of the squeak
> >> community has been trying to modularize the image
> and treat more and
> >> more modules as external loadable packages. The
> pharo team goes back 3
> >> (?) years and ignores anything done in said
> external projects in the
> >
> > As a side note, Keith, I'm slightly getting
> annoyed being criticized over
> > again for what we do wrong in your opinion. To do it
> our own way without
> > conflicting with the Squeak way of doing (or not
> doing) things, is why we
> > left. I believe that we can profit from the common
> effort, but it should
> > happen in a constructive way.
> >
> > Adrian
> >
> >
> 
> Keith, i understand your rightfull indignation.
> But i personally feel, that people who making fixes to
> external
> packages having no intent on keeping them private.
> It comes simply from different development process they
> involved in,
> and our common laziness to do something in addition (like
> ANN the fix)
> to what possibly be done to fix some annoying issue.
> 
> I seen multiple 'twas already fixed in XYZ' in this
> mailing list. And
> XYZ is not always =='Pharo' :)
> I think that such message could serve as a signal for
> backporting/reintegration but not as a signal to bash
> people :)
> 
> 
> -- 
> Best regards,
> Igor Stasenko AKA sig.

Adding to my views about current release, is not time to think we doing the wrong thing ?

We don't have a 3.11 image.
We don't have a process as we have earlier.
1 a bug or fix is summit to Mantis
2 some add his review , saying the particular fix or enh is good and should included in the image
3 the people running the release try the fix, run the relevant test
4 a nnnnImprovingFoo.cs go to updates folder
5 user press a button and have his 3.11Squeak.nnnn.image

For packages, we don't should reinvent the fire.
Exist some called Monticello 2 and all should help to being the only accepted way .

Universes and SqueakMap should integrate, Installer should be put to a deserved rest.

CodeLoader exist in the image from 1999 and with a few changes do the load of external things.

A new SqueakSource should be run by Aida , if Aida people is ready for the challenge.

This time, not only .mcz could be put for each package.

The acepted formats should be .pr, .morph, .mcz , .obj, etc

Mientras esto no se entienda ...
As long this don't be understand...

Edgar



      Yahoo! Cocina
Recetas prácticas y comida saludable
http://ar.mujer.yahoo.com/cocina/