SqueakMap Community Account? (was: About Configurations)

> Andreas wrote:
>
>> Well, I don't *think* of it as SqueakMap but the comparison is somewhat
>> appropriate. The main reason why I don't think of it as SM is that SM wants
>> to be "all packages ever created for Squeak" but what we need is "all
>> packages that we've actually tested to work in this image".
>
> Every version of every SqueakMap package declares which image version
> it is for.  In fact, it even includes additional tags such as whether
> it makes any modifications to that base image.
>
> Currently, there is no 4.2 entry in SqueakMap so, regardless of the
> quality of this tag for past versions, there is an opportunity for,
> going forward, to simply *test it* before posting it...
>
> Not that that should really matter, given usual (MIT) license which
> completely denies fitness for a particular puporse..
>
>> And of course
>> there are some other differences (like community ownership instead of
>> individual ownership of the catalog elements)
>
> To put this shallow shortcoming to rest, I have a mind to create a new
> SqueakMap account called, "Community" and announce the password for it
> here on this list:  "squeak"...
>
> We can take charge behind the scenes to add "Community" as a
> co-maintainer of all existing SqueakMap projects.  We can then
> announce, on this list, "if you don't want your package to be
> community-maintaintable, then remove Community as a co-maintainer."
>
> Any unrepresented projects will, therefore, not have a advocate to
> remove it and therefore keep  Community account as a co-maintainer.
>
>> but other than that I agree;
>
> That's it then?  Cool!!  Let's breakout the SqueakMap!  :-D
>
>   - Chris
>
>

> Hi Chris -
>
> I don't want to keep raising bars here but one other issue with SM is lack
> of dependencies. There needs to be *some* way to provide dependency
> information if we want to make it easy to install things. That is, unless we
> assume that anything that has 'real' dependencies is done using Metacello?
>
> Cheers,
>  - Andreas
>
> On 7/15/2010 1:36 PM, Chris Muller wrote:
>>
>> Andreas wrote:
>>
>>> Well, I don't *think* of it as SqueakMap but the comparison is somewhat
>>> appropriate. The main reason why I don't think of it as SM is that SM
>>> wants
>>> to be "all packages ever created for Squeak" but what we need is "all
>>> packages that we've actually tested to work in this image".
>>
>> Every version of every SqueakMap package declares which image version
>> it is for.  In fact, it even includes additional tags such as whether
>> it makes any modifications to that base image.
>>
>> Currently, there is no 4.2 entry in SqueakMap so, regardless of the
>> quality of this tag for past versions, there is an opportunity for,
>> going forward, to simply *test it* before posting it...
>>
>> Not that that should really matter, given usual (MIT) license which
>> completely denies fitness for a particular puporse..
>>
>>> And of course
>>> there are some other differences (like community ownership instead of
>>> individual ownership of the catalog elements)
>>
>> To put this shallow shortcoming to rest, I have a mind to create a new
>> SqueakMap account called, "Community" and announce the password for it
>> here on this list:  "squeak"...
>>
>> We can take charge behind the scenes to add "Community" as a
>> co-maintainer of all existing SqueakMap projects.  We can then
>> announce, on this list, "if you don't want your package to be
>> community-maintaintable, then remove Community as a co-maintainer."
>>
>> Any unrepresented projects will, therefore, not have a advocate to
>> remove it and therefore keep  Community account as a co-maintainer.
>>
>>> but other than that I agree;
>>
>> That's it then?  Cool!!  Let's breakout the SqueakMap!  :-D
>>
>>  - Chris
>>
>>
>
>
>