X-Spam-Check-By: sourceware.org Message-ID: <44A079F7.2020309@tlinx.org> Date: Mon, 26 Jun 2006 17:21:11 -0700 From: Linda Walsh 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> <44A03D53 DOT 2050707 AT tlinx DOT org> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com 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/