[Squeak-ev] Fwd: location of package dependencies

Markus Gaelli gaelli at emergent.de
Mit Jul 30 12:05:10 UTC 2003


Was denkt Ihr?
Ich fände eine integrierte Squeak-Lösung natürlich super schick,
Könnten wir sowas hosten?
Heißt ja nicht unbedingt selber programmieren, aber wer Lust hat...

Den Vorschlag "mit Bestätigung der Mail und nur für dev-Mitglieder"
find ich gut.

Markus

Anfang der weitergeleiteten E-Mail:

> Von: Daniel Vainsencher <danielv at netvision.net.il>
> Datum: Mi, 30. Jul 2003  13:37:20 Europe/Berlin
> An: The general-purpose Squeak developers list 
> <squeak-dev at lists.squeakfoundation.org>
> Cc: The general-purpose Squeak developers list 
> <squeak-dev at lists.squeakfoundation.org>
> Betreff: Re: location of package dependencies
> Antwort an: The general-purpose Squeak developers list 
> <squeak-dev at lists.squeakfoundation.org>
>
> I think that an ftp/http/webdav space that gives any squeak
> people/projects a directory would be wonderful. The important thing is
> that it should take too much effort for people to get space.
>
> I think that consider Avi's post, and the tight fit of MC to Squeak vs
> CVS, this would be really useful, both for package development, and to
> make sure that SM packages are easily available.
>
> I imagine a little seaside app could be useful in semi-automating
> account creation, to balance the ease of opening projects with security
> against warez monger. Maybe a "mail the password back but only to
> someone in the Squeak lists" scheme would solve the problem.
>
> This would be much easier to use and more powerful for Squeak projects
> than SF/CVS. If Squeak e.v. can do this, that would be a real service 
> to
> the Sqeauk community.
>
> Daniel
>
> Markus Gaelli <gaelli at emergent.de> wrote:
>> Hi,
>>
>>> For example - suppose SmaCC is declared by it's author to depend on 
>>> RB
>>> because the RB includes some specific extensions that SmaCC needs.
>>> Suppose those extensions are then incorporated in a later version of
>>> Squeak. The dependency information has changed, though the SmaCC code
>>> hasn't. It should be possible to update the dependency information
>>> somewhere, without repackaging or modifying the SM entry.
>>>
>>> Suppose the SmaCC maintainer is no longer interested in it, but one 
>>> of
>>> its avid users has noted the dependency change. This user should be
>>> able
>>> add this information.
>>
>> We should enable collaboration as good as possible.
>> That is why I think we should put our code on SourceForge or
>> something like it as often as we can.
>>
>> SourceForge is very well suited for BSD-licensed stuff (OSI approved)
>> and  Andreas Raab told me recently, that Avi and others
>> put their Squeak-licensed code on SourceForge under  the
>> "Other custom license (OSD-Compliant as Open Source)", which means 
>> some
>> effort for the SourceForge people:
>>
>> "If you selected "other", please provide an explanation along with a
>> description of your license.
>> Realize that other licenses may not be approved. Also, it may take
>> additional time to make a decision
>> for such project, since we will need to check that license is
>> compatible with the OSI's Open Source Definition."
>>
>> Different with SmaCC, as this has no explicit license, so I cannot put
>> it there.
>> But I surely want others to collaborate on that, and absolutely don't
>> like the
>> fact, that it is lying on my own server, where I only own one
>> upload-password,
>> which I don't want to give to anybody...
>>
>> So anybody wants to build SorceForge with Seaside? If no one else is
>> found,
>> the Squeak association Germany might host that stuff, we would have to
>> discuss this.
>> Might be overkill though, as most of the stuff is BSD or
>> Squeak-licensed, it
>> just needs to be moved to SourceForge.
>>
>> Markus
>