Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
Message-ID: <415F84D9.71F7A078@dessent.net>
Date: Sat, 02 Oct 2004 21:49:29 -0700
From: Brian Dessent <brian AT dessent DOT net>
Organization: My own little world...
MIME-Version: 1.0
To: cygwin AT cygwin DOT com
Subject: Re: Request for a version/ revision/ release number for the whole Cygwin release/ distribution
References: <200410030214 DOT i932ESVF003419 AT a DOT mail DOT sonic DOT net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-IsSubscribed: yes
Reply-To: cygwin AT cygwin DOT com

David Christensen wrote:

> If we can build a fully automated Cygwin "stable" test suite and
> parallelize it across many computers (wishful thinking: SETI screen
> saver), it may be possible to do 100% testing of all changes prior to
> release -- major, minor, and updates.

Fortunately for all the other major software projects like
Redhat/Debian, their installer tools can be automated.  The cygwin
setup.exe is the sole supported means for installing and removing
packages, and it requires user intervention.  Yes, I know there are some
command line parameters that are undocumented that you can kludge up an
automated solution with, but I've never really seen anyone step up and
say that they are working or even supported.

From reading bug reports on the list, one of the major areas that Cygwin
could be improved is just minor little issues that occur during setup. 
"Oops, package <x> wasn't installed but is required."  "Oh, looks like
that postinstall script has a minor bug that causes it to hang."  And so
on... Those are the kind of things that I think it would be great to
solve (e.g. a nightly automated stock base install, with a test harness
that ensures that stuff that should work on a base install does work)
but at this point the whole setup infrastructure just isn't there. 
Perhaps that would be a managable sub-goal to focus on first --
separating setup into a scriptable backend and GUI frontend.  I know it
has been discussed before but it's no trivial undertaking.

Really, I think everyone agrees that it would be great to have what
you're describing... But the problem is that it requires a lot of
initiative on somebody's part, and currently the people that would be
most qualified to steer that initiative are too busy to do so.

Brian

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/