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?


On Mon, 26 Jun 2006, Linda Walsh wrote:

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

What is the difference between installing a "test release" of Cygwin and
installing a "snapshot" of Cygwin (other than the mechanism by which you
do it)?  How would it help you if the current snapshot were made available
as a "release" today?  It would be as (un)stable as the snapshot it was
packaged from.  The Cygwin developers intentionally do not make snapshots
installable via setup, because of exactly that mindset: "releases are
stable, snapshots aren't".  If you got something via setup, you would feel
you have the right to complain about it if something breaks and demand
that it be fixed.  If you install a snapshot, well, you were warned.
You'd still complain (and we want you to), but you'll probably invest more
effort in tracking down the problem and producing a simple testcase.

FWIW, it's trivial for someone to provide a service that would mirror the
snapshot tarballs off the snapshots page and make them available to setup
as test releases.  It would even be possible, with a little effort, to be
selective and only mirror the snapshots that the developers deem stable
enough to be release candidates (though it would have to be done
manually).  However, anyone providing that service should be prepared to
field complaints and generate proper bug reports.  If done properly, this
kind of service would be invaluable to the Cygwin project.  If done
poorly, it would be a great hindrance.
	Igor
-- 
				http://cs.nyu.edu/~pechtcha/
      |\      _,,,---,,_	    pechtcha@cs.nyu.edu | igor@watson.ibm.com
ZZZzz /,`.-'`'    -.  ;-;;,_		Igor Peshansky, Ph.D. (name changed!)
     |,4-  ) )-,_. ,\ (  `'-'		old name: Igor Pechtchanski
    '---''(_/--'  `-'\_) fL	a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

"Las! je suis sot... -Mais non, tu ne l'es pas, puisque tu t'en rends compte."
"But no -- you are no fool; you call yourself a fool, there's proof enough in
that!" -- Rostand, "Cyrano de Bergerac"

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


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