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 From: "Dave Korn" To: Subject: RE: Request for a version/ revision/ release number for the whole Cygwin release/ distribution Date: Fri, 1 Oct 2004 14:16:45 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit In-Reply-To: <200410010531.i915VL1a014777@a.mail.sonic.net> Message-ID: X-OriginalArrivalTime: 01 Oct 2004 13:16:45.0298 (UTC) FILETIME=[E64F1520:01C4A7B8] > -----Original Message----- > From: cygwin-owner On Behalf Of David Christensen > Sent: 01 October 2004 06:31 > cygwin AT OHFORCRYINGOUTLOUD DOT XXX: http://cygwin.com/acronyms#PCYMTNQREAIYR, then please don't go and manually enter any either! > Per the Cygwin FAQ (http://cygwin.com/faq.html): > > "If you are looking for the version number for the whole Cygwin > release, there is none. Each package in the Cygwin release has its own > version. The packages in Cygwin are continually improving, > thanks to the > efforts of net volunteers who maintain the Cygwin binary ports. Each > package has its own version numbers and its own release process. " > > > I would like to request that this policy be reversed -- that > there be a version number for the entire Cygwin release. Well, you haven't explained how you would like this to be achived. As far as I can see, the only two ways would be a) Have an overall version number that is bumped every time any package changes at all, or b) Forbid package maintainers from making releases directly, but instead accumulate all the new releases they come up with and roll them all up into a new "entire Cygwin release" at arbitrary intervals, at which time a new version number is assigned to the overall bundle. Is there another option I've overlooked? > Every O/S and application > I've used had a release number for the whole thing; Cygwin should as > well. As has been pointed out before, this is simply not remotely true. Every O/S you've used has a release number that applies only to the core O/S without any relevance to the applications, and there are always many versions of applications per version of each O/S. So you could achive the same goal by simply choosing the version number of the dll as your "entire Cygwin release" version number. > I would especially like to request that there be a "stable" > distribution. There's absolutely no reason on earth why you shouldn't go ahead and assemble a "stable" distribution for yourself. > Why? Because: > > 1. I use Cygwin for all sorts of stuff, including mission-critical > backup chores. I was recently bitten by the cron-2.6.2 EOF issue, as > were others. This represents real damages that people are > suffering by > using Cygwin. This is bad for the open-source movement. What "cron-2.6.2 EOF issue"? I couldn't find any reference to a cygwin version of cron earlier than 3.0.something. However, on the assumption that you mean rsync, the problem presumably happened when you upgraded to the latest version, yes? And you think this is the cygwin project's or rsync maintainer's fault? No, this is entirely your own fault for following bad practice. Why on earth did you go replacing a known-good version of a mission-critical app in a production environment with an unknown and untested version? Have you ever heard of 'change control management'? If it was already working as desired, and there wasn't some critical bug or security fix or vital new feature you needed, it was irresponsible and reckless of you to go and change the installed version. The urge to always have the very latest versions of everything is completely pointless: there's no need for it and it imposes risk to your project without any clear benefit in exchange. When you went to upgrade that already-working-package, you were on a hiding to nothing. It also has nothing to do with the open-source movement. Nobody installs the latest and newest version of Windows onto a production server the second it hits the streets, precisely because the latest'n'greatest version of _any_ software is also _always_ the least reliable and stable, and everybody knows it. Why do you think so many major corporations still use Nt4Sp6 for all their working servers? Because it's a known quantity, stable and well understood and refined and debugged over many years. You don't go and install the latest beta longhorn release on an operationally vital machine, not if you value the continuity of your business you don't. > 2. This is not the first time I've experienced this meta-problem. It > indicates a lack of integration testing of Cygwin as a whole. This is > also bad. > > 3. I would like to be able to burn Cygwin X.Y.Z onto a CD or DVD for > myself and for others. This is good. > > 4. I develop software and would like to be able to tell > people "it runs on Cygwin X.Y.Z". This is also good. Right, this is a reasonable suggestion: that you want Cygwin to become a distribution, like one of the major Linux distros, with a tested and integrated set of packages. This begins to answer my earlier question: I assume that you want co-ordinated releases at infrequent intervals rather than ad-hoc releases by maintainers whenever they have new versions. Unfortunately, it's a lot of work. This is why corporations like Red Hat and SuSE and Debian and whoever can charge money for the work they do in packaging, integrating, testing and certifying distros. So if you wanted to set up a company in the business of making Cygwin distros, you could do so, and then you would stand in the same relation to Cygwin as Red Hat, Debian, et al. do in relation to the Linux kernel. However, it would be a _vast_ amount of work to assemble a distro based around Cygwin starting from scratch, similarly to how it has involved a vast amount of man-years and financial resources to develop the commercial Linux distros to the levels of testing, stability, integration and reliability they are achieving these days. Nobody's going to put that amount of effort into something unless a) they really badly want it for themselves, or b) someone else pays them to do so. So there's nothing to stop you doing your own testing and establishing a set of package versions and a dll version that you can guarantee to work well together, and if you did that you could undoubtedly sell it and become the first Cygwin distro. Or you can take option b), and pay someone to do this work for you: I'm sure Red Hat would still be glad to discuss terms for Cygwin support contracts. > I hereby request that everybody who reads this message reply > and express > their opinion so that the Cygwin release maintainers will > know what the community wants. I'm perfectly happy with the current system. I myself maintain an approved distribution for internal use here at my work. I've taken a much more simplistic approach to it though, because I don't have vast resources to throw at it. Basically, I've been keeping an eye on the mailing list, and when it seemed to me that the dll was going through a fairly stable patch, I rsync'd a local mirror. And that's it. If any packages turn out to have major bugs or security holes, and even then _only_ if those problems impact on the users who I have to support, then I'll update them. If something new is released, and there is a demand for it from my users, then I'll add it. But anything that works, I'm not going to fix. > p.s. I hereby volunteer my time to work on implementing my request. > However, be warned that I have very high standards and, > especially as a > volunteer, I will not tolerate my time being wasted. If you want me to "express my opinion" on this paragraph, we'll have to TITTL. I'm tempted to offer my opinion whether it's wanted or not, but it's not going to have much to do with Cygwin cheers, DaveK -- Can't think of a witty .sigline today.... -- 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/