This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: snapshots: first resort, or last resort?

mwoehlke wrote:
Science Guy wrote:
In, 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 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

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?]

   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

   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.


-- Unsubscribe info: Problem reports: Documentation: FAQ:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]