[Squeak-ev] Fwd: location of package dependencies

[mietzsch at gmx.de]

Hallo Markus,
um was geht es denn eigentlich?
Gruß
Esther

> 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
> >
> 

-- 
COMPUTERBILD 15/03: Premium-e-mail-Dienste im Test
--------------------------------------------------
1. GMX TopMail - Platz 1 und Testsieger!
2. GMX ProMail - Platz 2 und Preis-Qualitätssieger!
3. Arcor - 4. web.de - 5. T-Online - 6. freenet.de - 7. daybyday - 8. e-Post