Could you please announce when there is a discussion started
on debian-devel? 

thanks,

Norbert
On Wed, 2008-05-21 at 23:34 +0200, Bert Freudenberg wrote:
> Etoys was being considered to get into Debian. Now it may be rejected,  
> because an image file is not "transparent enough" (see below). It was  
> suggested to discuss this issue on the debian-devel list.
> 
> Do any of you have ideas how to respond? Are there perhaps other  
> Debian packages that have a similar issue of accountability?
> 
> And how hard would it actually be to bootstrap a fresh Squeak image  
> from sources nowadays?
> 
> - Bert -
> 
> Begin forwarded message:
> 
> > From: Thomas Viehmann <tv at beamnet.de>
> > Date: 21. Mai 2008 23:06:38 MESZ
> > To: "José L. Redrejo Rodríguez" <jredrejo at edu.juntaextremadura.net>
> > Cc: Bert Freudenberg <bert at freudenbergs.de>, ftpmaster at debian.org,  holger at layer-acht.org
> > Subject: etoys_3.0.1916+svn132-1_amd64.changes (almost) REJECTED
> > Reply-To: ftpmaster at debian.org
> >
> > (OK, for technical reasons, this is not the REJECT, but there is
> > little point in delaying this mail now that I have written it.)
> >
> > Hi José, Bert, Holger,
> >
> > this is, unfortunately, the REJECT of etoys.
> > First of all, thanks Bert, Holger, José for the discussion of some of
> > the concepts. However, I am afraid that there are some fundamental
> > concerns that have not been eliminated (yet). As such I would like to
> > invite you to start a discussion on the packaging of squeak session
> > images on debian-devel at lists.debian.org. Feel free to forward this
> > mail if you consider it useful as a starting point.
> >
> > It seems to me that the method of distributing VM sessions in .image
> > files as the preferred form of modification does not match too well
> > with Debian practices of compiling packages from source and having
> > easy access to the differences between various versions of a package.
> >
> > So as far as I understand it it seems like a typical squeak image
> > cannot be bootstrapped[1] from (textual) source and that the typical
> > mode of operation is to modify some known image and distribute the
> > result. As such, the preferred form of modification is indeed the
> > image file.
> >
> > This, in my opinion, raises at least the following questions that seem
> > fundamental to me:
> >
> > - How easy should it be to figure out what is in an image?
> >  While the source code to any class seems to be available, the
> >  image is more than that. Does that matter? Should source of Debian
> >  packages be auditable and is etoys currently auditable easily
> >  enough?
> >
> > - Does Debian (including the various teams that might have to take
> >  a look at your packages) want to have easy access to the
> >  differences between upstream version, one Debian revision and
> >  another? Do squeak session images provide this in a way that
> >  is acceptable to Debian?
> >
> > From the squeak wiki pages and your explanations it seems that what I
> > would consider at least partial solutions exist, but it seems that
> > either I am still lacking understanding of important concepts or
> > that the etoys packaging (Debian and maybe also upstream) could
> > possibly be made a bit more transparent.
> > Of course, we might find out that my difficulties with the
> > perspective of squeak images in Debian originate in misconceptions of
> > Debian packaging and maintenance that I may have. Either way, I would
> > appreciate if we could discuss this with the Debian development public
> > at large and draw on their additional expertise.
> >
> > Kind regards
> >
> > Thomas
> >
> > 1. http://wiki.squeak.org/squeak/769
> > -- 
> > Thomas Viehmann, http://thomas.viehmann.net/
> 
> 
> 
>