Hello,

I have just discovered that some enh I posted one year ago in a .mcz
format were rejected because these are not in .cs format. I think that
.mcz format is the right way to manage enh (enhancement), so I take a
look in UnstableSqueak image which tackle enh management through
Monticello (the right way in my opinion !), but I didn't manage to do
a default update (bug), it's quite a pity... So I don't like the .cs
approach because too painful for me, and Monticello adds a lot of
facilities precisely to enhance the enhancements ;-) in a reflective
manner and hence in the smalltalk spirit. So I propose a temporary way
to manage enhancements in a collaborative manner, or at least ask
reviewers if it is possible to let us manage enhancements by posting
.mcz or - better for mail traffic - the url pointing to the required
.mcz. I'm ready to make some modifications to BFAV if it is necessary
to ease the review process...

So for the moment, I manage my own ENH with Monticello by setting up a
squeaksource project : SqueakEnh (available in R/W access). Usually,
when I do an enh in the core image (I define the core image as the set
of classes which are not (can not be?) packaged), I extensively use
*squeakenh-mynewenhancement extension since usually we need to modify
several classes in different categories for one enh. This solution is
for me satisfying until UnstableSqueak become stable ;-) for adding
enhancements. As far as I understand (I didn't manage to test this in
the latest unstableSqueak because of bugs), when you commit changes
for the Squeak Kernel, there is no way to separate the different
enhancements you made (for instance, for a SqueakEnh-Collections and
SqueakEnh-SqueakersInfo, if you made enhancements concerning this two
kinds of enh, there will be committed as a global enhancement). But
maybe I'm wrong.

To manage ENH for packages instead of Squeak Core, I used to use the
name SqueakEnh-StarBrowser for instance, and manage it in the same
way. But I think this enhancements should be send to the maintainer
first (not sure that it is relevant to send it to the squeak-dev), and
it's quite easy to automatically report a bug to the maintainer
(thanks to SMSqueakMap and SqueakEnh-SqueakersInfo for instance). I
could do it if you think it's interesting. In fact, the problem is
deeper because an enh sometimes modify both a package and the core
(see SqueakersInfo), which probably means that a little part of the
package should be in the core (or vice-versa ?), or that the core
should evolve. But this is not really clear yet.

A final word to propose that a [Bug Report] appear directly as a
button after the [Where] button, to add more visibility to bug
reporting (you have to use a context menu and dig into it to find the
little line "mail a bug report").

Comments ?

Cheers,
Samir

-- 
Samir SAIDANI				
PhD Student in CS / Doctorant en informatique 	web : http://www.info.unicaen.fr/~saidani
Universite de Caen - Laboratoire GREYC          tel : 02-31-56-74-30
Equipe MAD - Campus II - 14032 Caen Cedex       fax : 02-31-56-76-30