This is the mail archive of the
mailing list for the Cygwin project.
Re: Request for a version/ revision/ release number for the whole cygwin release/ distribution
- From: Christopher Faylor <cgf-no-personal-reply-please at cygwin dot com>
- To: cygwin at cygwin dot com
- Date: Sun, 3 Oct 2004 01:08:10 -0400
- Subject: Re: Request for a version/ revision/ release number for the whole cygwin release/ distribution
- References: <200410030214.i932ESVF003419@a.mail.sonic.net> <415F84D9.71F7A078@dessent.net>
- Reply-to: cygwin at cygwin dot com
On Sat, Oct 02, 2004 at 09:49:29PM -0700, Brian Dessent wrote:
>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.
Good points. If you read fark.com, you'll note that sometimes news
stories are posted with an additional "still no cure for cancer" tag,
"Fish fart scientists win Nobel Prize, still no cure for cancer"
If we were going to be improving cygwin so that more people used it and
there were fewer complaints then there is a fair amount of low hanging
fruit that could be grabbed. Improving setup.exe is one improvement
(adding more help to it, clarifying some buttons, overhauling the UI).
Improving cygwin's documentation (adding a new user's guide, maybe?) is
another. Adding new tests to cygwin's test suite and running tests on
an automated basis (an old chestnut from cygwin-developers that no one
has ever stepped up for) is another one. I'd love for any new cygwin
bug to be checked in with an addition to the cygwin test suite.
We could look into ways of making openssh installation idiot-proof.
We could create our own service manager that just had to be installed
once and then managed all of cygwin's services. I could complete the
fifo implementation in cygwin (it's not that far from finished).
If we have limited resources then there are a lot of tasks that I'd like
to see which I think would have a bigger impact developing a "stable
release". Maybe it's a false dilemma to see things this way and there
is a group of people who'd love to do release engineering and QA for a
monolithic cygwin release but can't help out with some of the more
obvious problems that plague cygwin now.
If you're out there, this is the time to step up.
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html