delorie.com/archives/browse.cgi   search  
Mail Archives: cygwin/2006/06/26/16:02:40

X-Spam-Check-By: sourceware.org
Message-ID: <44A03D53.2050707@tlinx.org>
Date: Mon, 26 Jun 2006 13:02:27 -0700
From: Linda Walsh <cygwin AT tlinx DOT org>
User-Agent: Thunderbird 1.5.0.4 (Windows/20060516)
MIME-Version: 1.0
To: cygwin AT cygwin DOT com
Subject: Re: snapshots: first resort, or last resort?
References: <001201c6945d$59ca3010$0a3b6080 AT joehome> <e7a38b$mrv$1 AT sea DOT gmane DOT org>
In-Reply-To: <e7a38b$mrv$1@sea.gmane.org>
X-IsSubscribed: yes
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

mwoehlke wrote:
> Science Guy wrote:
>> In http://cygwin.com/ml/cygwin/2006-06/msg00434.html, Brian said 
>> "using the
>> latest snapshot should always be the first thing you try when 
>> encountering a
>> problem before reporting it to the list."
>>
>> However, the instructions for installing snapshots at
>> http://cygwin.com/faq/faq-nochunks.html#faq.setup.snapshots say:  
>> "First,
>> are you sure you want to do this? Snapshots are risky. They have not 
>> been
>> tested. Use them ONLY if there is a feature or bugfix that you need 
>> to try,
>> and you are willing to deal with any problems, or at the request of a 
>> Cygwin
>> developer."
>>
>> For a non-expert, such as me, this dichotomy of views is perplexing.  
>> This
>> is made all the more perplexing because there does not seem to be (I 
>> could
>> not find) a user-readable list of bugs that each snapshot fixes 
>> vis-a-vis
>> the latest release.  So how would a user know whether the "risky" 
>> step of
>> installing a snapshot will have any chance of fixing a particular bug?
>>
>> -- Joe
--- 
    Excellent point Joe (aka Science Guy!). 

>  If you have a problem, you should try a snapshot. However, you should 
> keep in mind that doing so means trying a potentially unstable setup. 
> Therefore, when trying a snapshot, you should do as little as possible 
> while using that snapshot. If it doesn't fix your problem, it is 
> safest to go back to a stable version. If it does, *then* you have to 
> decide if you want to use a setup that might be unstable (more so than 
> usual), or if you can wait for an official release.
----

    Which begs the question -- why aren't releases done more often?  Five
months between releases seems intensely long compared to, say, the linux
kernel, which averaged 1 month releases when 2.4 was active, to 2 month
releases, now, with 2.6 and the managed "bug fix" releases that happen in
between  regular releases.

    It doesn't do _users_ alot of good to check a snapshot.  It does,
indirectly, in that it may increase code quality, *but*, if they don't want
to run with an unstable snapshot, they won't see their bugfix for [several?]
months.

    Trying a snapshot fine for testing a particular bugfix, but snapshots
are no substitute for updating the released product on a regular basis.  If
the cost to do a release is low and number of changes / bugfixes are high,
it would be good to get the product to a "releasable" point every few weeks
to a month so users will see their efforts at find/isolating/reporting/
trying snapshots, rewarded.  Is there some obstacle to more regular
releases?

    If it were me, (and I know it's not, thank-you), I'd feel better about
getting updated releases into user's hands as soon as reasonable.  If I fix
something, or change something, I wouldn't want to wait 6 months to release
it, (ideally,) so if a change I make introduces an untested and unthought-of
incompatibility I'm more likely to remember the changes that went into the
code.  Five-Six months later, on active code and the changes might as well
have been made by someone else and I'm more likely to have to go in "cold"
to figure out which change broke things for some isolated user test case.
If there have been many changes, it's all the more difficult to find out
which change introduced the problem (IMNSHO).

    I would take advantage of the "Test" release present in setup to give
people time to check things, then rotate it into the "Current" slot, and the
older one to "Previous".  I know other people have different working styles,
but it helps to understand where they are coming from and their rationale
for doing it the way they do it. 

Linda




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

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019