Mailing-List: contact cygwin-help@sourceware.cygnus.com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe@sources.redhat.com>
List-Archive: <http://sources.redhat.com/ml/cygwin/>
List-Post: <mailto:cygwin@sources.redhat.com>
List-Help: <mailto:cygwin-help@sources.redhat.com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-owner@sources.redhat.com
Delivered-To: mailing list cygwin@sources.redhat.com
Message-ID: <3BF44D66.A282870F@wapme-systems.de>
Date: Fri, 16 Nov 2001 00:19:02 +0100
From: Stipe Tolj <tolj@wapme-systems.de>
Organization: Wapme Systems AG
X-Mailer: Mozilla 4.7 [de]C-CCK-MCD QXW0322b  (WinNT; I)
X-Accept-Language: de,en
MIME-Version: 1.0
To: Robert Collins <robert.collins@itdomain.com.au>
CC: Charles Wilson <cwilson@ece.gatech.edu>,
   "Gerrit P. Haase" <cygwin@cygwin.com>
Subject: Re: new site for my ports is up
References: <5314439342.20011114212805@familiehaase.de>	 <3BF2D797.B0481987@ece.gatech.edu> <20011114211942.GB9636@redhat.com> <1119104841.20011114224550@familiehaase.de> <3BF2F6AD.726DB93E@ece.gatech.edu> <3BF3C5A2.7F7907B8@wapme-systems.de> <05cc01c16e24$2e03bf00$0200a8c0@lifelesswks>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

> The site maintenance is actually pretty automatic now. Copy the file to
> the location, it's included. Delete the file, it's removed. Hmm that's
> easy :}.

yes, considered in the raw uploading semantic. But what about
regression testing and file conflicts. Basicly we tread tarballs as
black-boxes without knowing (exactly) if the included files may mess
up a installation/package in some way.

> >   1) supporting the (new) users the best way to get what they want,
> > aka "has someone ported foobar already to Cygwin?!"
> 
> Chris has this already - he generates an automatic list of packages on
> the cygwin site. See this list a few days back IIRC.

I can't find that, what subject was the thread running under?

> >   2) support the pacakge maintainers, i.e. by having a reference of
> > all used files and possible file conflicts within a database on the
> > site. A package maintainer should be able to "check-in" a new release
> > and roll a regression test on it before it gets publicaly available
> > and integrated to setup.ini.
> 
> Hmm, I don't agree. See my point about conflicts. Conflicts are normal,
> and to be expected. There is no point getting all automated about
> detecting conflicts in packages until setup.exe can prevent the users
> installing those conflicting packages. Until that point, a check every
> month or three will probably suffice. An automated check on the package
> when it is put into the repository would also be great, but that takes
> tuit and I can think of other things that I'd like Chris to tuit before
> this (winsup/utils breakout specifically).

I agree, a fully automated procedure is not what I'm intending, but a
automation _support_.


Stipe

tolj@wapme-systems.de
-------------------------------------------------------------------
Wapme Systems AG

Münsterstr. 248
40470 Düsseldorf

Tel: +49-211-74845-0
Fax: +49-211-74845-299

E-Mail: info@wapme-systems.de
Internet: http://www.wapme-systems.de
-------------------------------------------------------------------
wapme.net - wherever you are

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

