Re: snapshots: first resort, or last resort?

[Linda Walsh <cygwin at tlinx dot org>]

Igor Peshansky wrote:
> What is the difference between installing a "test release" of Cygwin and
> installing a "snapshot" of Cygwin
---
	I would hope it is the difference between daily work and something that
is of "Beta" quality -- i.e. something that "seems to work" and "should work
for most people" and isn't as likely as "daily" work to be as variable as
"daily" snapshots are.


> The Cygwin developers intentionally do not make snapshots
> installable via setup, because of exactly that mindset: "releases are
> stable, snapshots aren't".
---
	Bingo.  A Beta release should have some stability even though it
may not be that of a finished product.  Do you guys live in a black and white
world?  There are more than two points "stable" and "unstable" in the real
world.  Virtually no software released today is bugfree (and by that definition
has some "instability" in it), but there are different "levels" of quality
that I and most users I know can notice.  For example, very conservative users
stay away from "V.0" releases, as they are the first after major changes.  For
them, they want the stability that may come from an "V.0.17" or an "V.3".
Other users are fine with released, but perhaps cannot afford "Beta" level
quality.  Other users are can tolerate Beta, but don't want to get into
"alpha's" (which are often internal, anyway).  Of lower quality than "alpha's"
are "daily snapshots" (which hopefully, at least build and are installable, but
not guaranteed), and below that might be the current CVS image.

	Different people are comfortable with different levels of "risk".


>  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.  
---
	Yeah, and?...So?


> 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.
---
	If you are a developer on the project, yes, or if you have a full plate
with other projects -- many managers I've been under would not be pleased if you
spent time debugging Cygwin.  On the other hand, I wouldn't make daily snapshot
code available if it wasn't of some minimal level of quality.  For all anyone 
knows, a daily snapshot might reformat your disk.  And we'd be expected not to
be upset when this occurs on a production system (since most engineers know one 
don't try software that's less stable than their machine is "rated".

> 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.
---
	Automatic releases would defeat the point.

  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). 
---
	You mean, select what version is going out with what changes in
an "intelligent" manner?  Are you inferring this is too difficult or not
possible for the cygwin developers?


> 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.
----
	Agreed.  The bugs could be filed (like the bugzilla available firefox and 
thunderbird) under their version -- whether its a daily snapshot, an alpha
a beta or a "released & tested version".  Perhaps cygwin could find a 
free-software bug-tracking site to integrate with?  Maybe the bugzilla website
could allow tracking of cygwin (might even give it more visibility, who knows?)?

	I also agree that not having a public bug tracking mechanism would be
a hindrance to a large and complex project like Cygwin.

	But barring any new developments, the Beta versions could be use
the same, bug tracking mechanism available today, right?  (ok, that's not
entirely fair), but the point would be when someone reports a bug in the "Beta"
or "Test" version, they *darn* well should say what version they are finding the
bug in, _and_, hopefully whether or not it is a new bug (is it in the released
version).

	If the two versions were never more than a month or two apart, then that
mechanism should point to whether or not it is a regression, or a "new, 
unreported bug".

	It has the added benefit of users being able to search through existing bugs to 
see if one has already been filed -- versus the current expectation that
users will go and read the cygwin-mailing list archives to find their problem.
Searching the cygwin-mailing archives with Google generates alot of "noise" in
the search results that are unrelated to bugs that have been reported and are 
"in the system" to be addressed at some point.

	I think the current method of scanning for bug reports out of all
posts that go to the cygwin mailing list would be much more work for a
developer or development team, but, then, that could be because that type of
structure would help me focus and prioritize so I think others "would" like
it too... :-)

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/