Re: Request for a version/ revision/ release number for the whole Cygwin release/ distribution
On Oct 5 22:19, Karl M wrote: Hi All... What about calling it B21? : *cough* Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader mailto:[EMAIL PROTECTED] Red Hat, Inc. -- 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/
Re: Request for a version/ revision/ release number for the whole Cygwin release/ distribution
Karl M schrieb: What about calling it B21? : As already discussed on cygwin-talk and as officially described on the webpage, B stood for Beta that times (up to 1998). We are already stable since a few years, though we use uneven version numbers, marking it as developer releases. fun So we could use S1511 (stable 1.5.11) or SS1511 (standalone stable 1.5.11) - I obviously watched a lot of world war movies. /fun Go with the Redhat scheme and use Cygwin 1.6.0. That's a unique name (unlike Yggdrasil, John Kerry or Roman Catholic) and would only clash with Redhat's supported GNUPro tools. Which is good IMHO, since it has comparable versions, we would just add much more packages. BTW: The link from http://sources.redhat.com/cygwin/ to Red Hat support contracts http://www.redhat.com/software/tools/cygwin/ fails. -- Reini Urban http://xarch.tu-graz.ac.at/home/rurban/ -- 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/
Re: Request for a version/ revision/ release number for the whole cygwin release/ distribution
On Tue, Oct 05, 2004 at 10:19:29PM -0700, Karl M wrote: Hi All... What about calling it B21? : It's as good a name for vaporware as any. cgf -- 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/
Re: Request for a version/ revision/ release number for the whole cygwin release/ distribution
On Wed, Oct 06, 2004 at 02:47:15PM +0200, Reini Urban wrote: Karl M schrieb: What about calling it B21? : As already discussed on cygwin-talk and as officially described on the webpage, B stood for Beta that times (up to 1998). We are already stable since a few years, though we use uneven version numbers, marking it as developer releases. fun So we could use S1511 (stable 1.5.11) or SS1511 (standalone stable 1.5.11) - I obviously watched a lot of world war movies. /fun Go with the Redhat scheme and use Cygwin 1.6.0. Please don't do this. Red Hat is using the even numbers. I don't know if there is already a 1.6.0 or not but there's certainly no reason to irritate the organization which is providing the network bandwidth for the cygwin release. cgf -- 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/
Re: Request for a version/ revision/ release number for the whole cygwin release/ distribution
On Oct 6 11:09, Christopher Faylor wrote: On Wed, Oct 06, 2004 at 02:47:15PM +0200, Reini Urban wrote: Go with the Redhat scheme and use Cygwin 1.6.0. Please don't do this. Red Hat is using the even numbers. I don't know if there is already a 1.6.0 [...] There is. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader mailto:[EMAIL PROTECTED] Red Hat, Inc. -- 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/
Re: Request for a version/ revision/ release number for the whole Cygwin release/ distribution
On Thu, 30 Sep 2004 22:31:26 -0700, David Christensen wrote: 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 especially like to request that there be a stable distribution. As the person who wrote those FAQ words (with input from several people here), I'd like to go on the record as saying that a stable distribution is a great idea. I *really* don't have time to work on it (heck, I don't even have time to be writing this email), but that doesn't matter, because there's nothing to stop it from happening. Simply start with a snapshot of the current release tree. Make some sort of ISO available or something, and think up a name other to call it than just Cygwin (like, I don't know Yggdrasil StableCygwin 1.0 or Roman Catholic StableCygwin 1.0--I highly recommend using some unique word for Internet searching). Whenever you find a problem with a particular package in your stable release (i.e., rsync EOL) patch your source version, replace the binary package, and make a new ISO. Here's the catch: IFF you gradually find that there is a lot of patching necessary, it will become unmanagable. You can also simply forget about meeting feature requests, because I that there will be too many. People who want features should roll their own, or use the Cygwin Net Release. On the other hand, if it's a success, you can write a guide to what you did and/or do regular releases, like Red Hat does. If that starts happening, get back to us and I guarantee that you will find people more interested. Well, I guess I can only guarantee myself, but I think there are some very big advantages to a stable distribution and that it will pull people in. If it really does turn out to be easy to maintain, it might even make all us maintainers' lives easier. You could start your own mailing lists for people using your John Kerry StableCygwin 1.0 and perhaps segment our traffic a little. Also, just to wrap up, in case it wasn't already clear enough: None of us can and/or want to organize a stable release, or to change the way the Net Release works. -- 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/
Re: Request for a version/ revision/ release number for the whole Cygwin release/ distribution
Hi All... What about calling it B21? : ... From: Joshua Daniel Franklin [EMAIL PROTECTED] Reply-To: Joshua Daniel Franklin [EMAIL PROTECTED] To: [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: Request for a version/ revision/ release number for the whole Cygwin release/ distribution Date: Tue, 5 Oct 2004 21:00:37 -0700 On Thu, 30 Sep 2004 22:31:26 -0700, David Christensen wrote: 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 especially like to request that there be a stable distribution. As the person who wrote those FAQ words (with input from several people here), I'd like to go on the record as saying that a stable distribution is a great idea. I *really* don't have time to work on it (heck, I don't even have time to be writing this email), but that doesn't matter, because there's nothing to stop it from happening. Simply start with a snapshot of the current release tree. Make some sort of ISO available or something, and think up a name other to call it than just Cygwin (like, I don't know Yggdrasil StableCygwin 1.0 or Roman Catholic StableCygwin 1.0--I highly recommend using some unique word for Internet searching). Whenever you find a problem with a particular package in your stable release (i.e., rsync EOL) patch your source version, replace the binary package, and make a new ISO. Here's the catch: IFF you gradually find that there is a lot of patching necessary, it will become unmanagable. You can also simply forget about meeting feature requests, because I that there will be too many. People who want features should roll their own, or use the Cygwin Net Release. On the other hand, if it's a success, you can write a guide to what you did and/or do regular releases, like Red Hat does. If that starts happening, get back to us and I guarantee that you will find people more interested. Well, I guess I can only guarantee myself, but I think there are some very big advantages to a stable distribution and that it will pull people in. If it really does turn out to be easy to maintain, it might even make all us maintainers' lives easier. You could start your own mailing lists for people using your John Kerry StableCygwin 1.0 and perhaps segment our traffic a little. Also, just to wrap up, in case it wasn't already clear enough: None of us can and/or want to organize a stable release, or to change the way the Net Release works. -- 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/ _ FREE pop-up blocking with the new MSN Toolbar get it now! http://toolbar.msn.click-url.com/go/onm00200415ave/direct/01/ -- 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/
RE: Request for a version/ revision/ release number for the whole Cygwin release/ distribution
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of David Christensen Sent: Sunday, October 03, 2004 4:15 AM To: [EMAIL PROTECTED] Subject: RE: Request for a version/ revision/ release number for the whole Cygwin release/ distribution I don't think there are enough potential volunteer man-hours to make such a thing feasible. I disagree. Assume for a moment that all Cygwin project member development efforts can be put into the following bins: 1. Code development. 2. Design documentation. 3. Test suite development. 4. Test suite documentation. 5. Test suite execution and reporting. 6. User documentation. 7. Packaging for distribution. 8. Infrastructure development. 9. Infrastructure administration. 10. Version control/ configuration management of all of the above. 11. Personnel leadership and project management. It would seem that bin #1 is consuming the majority of the effort. I think that by changing priorities and re-allocating people and resources, it should be possible to create integration tests and a stable distribution. Such would increase Cygwin's acceptance and usage for potentially hundreds of millions of people. Is this not a good thing? It seems to me that as it is a volunteer community, the people in question would need to volunteer to be re-allocated. This does not seem to be happening. :-) -- 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/
Re: Request for a version/ revision/ release number for the whole Cygwin release/ distribution
Mike Kenny - BCX - Infrastructure Services wrote: -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of David Christensen Sent: Sunday, October 03, 2004 4:15 AM To: [EMAIL PROTECTED] Subject: RE: Request for a version/ revision/ release number for the whole Cygwin release/ distribution I don't think there are enough potential volunteer man-hours to make such a thing feasible. I disagree. Assume for a moment that all Cygwin project member development efforts can be put into the following bins: Well, there might be plenty of potential volunteer hours, but since it's voluteer, people can prioritize their efforts as they wish... 1. Code development. 2. Design documentation. 3. Test suite development. 4. Test suite documentation. 5. Test suite execution and reporting. 6. User documentation. 7. Packaging for distribution. 8. Infrastructure development. 9. Infrastructure administration. 10. Version control/ configuration management of all of the above. 11. Personnel leadership and project management. It would seem that bin #1 is consuming the majority of the effort. I think that by changing priorities and re-allocating people and resources, it should be possible to create integration tests and a stable distribution. Such would increase Cygwin's acceptance and usage for potentially hundreds of millions of people. Is this not a good thing? Well potential... and potential. Who would use Cygwin and what for? Cygwin doesn't really offer anything that Joe Average needs or even bothers to learn since it's difficult. For advanced users, system operators and such Cygwin gives lot more. But it definitely reduces potentials down. For a corporations there is magic word called tech support. It seems to me that as it is a volunteer community, the people in question would need to volunteer to be re-allocated. This does not seem to be happening. :-) It seems that it isn't happening and I think it takes a whole lot more time and personel to volunteer their time to all those bins. And since many of packages are open source, builts are targeted on *nix systems, primary maintenance happens outside cygwin eg. level of documentation, testing, testcases and such varies greatly. Then there is cygwin specific maintainers that just make sure that package compiles and works okay (as specified by original author(s)) and builds distribution package. And then there is people who work for core of cygwin, cygwin1.dll... Always have to think of target audience. If you're looking something simple you can take a look for TheOpenCD project, OSI licensed software for average users. Or less professional looking GnuWin2 project, also OSI licensed software for advanced propellerheads. Both offer many OSS software as native builds, with nice standard gui installers and such. But how about Cygwin? Cygwin installation provides only basically list of packages and you really have to know what you're doing before you get something useful out. Maybe it would be just enough to produce better installation program, maybe even possiblity to categorize tools like you could just say C and C++ development tools and you get all needed stuff to build programs, maybe even in neat single download package. After that you could name installation package as Cygwin Environment version 99.99 and refer people to download and use that specified package. Hmm... NSIS could even work this out pretty well... I might even try that one if there is enough interest for that. -- Jani Tiainen -- 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/
RE: Request for a version/ revision/ release number for the whole Cygwin release/ distribution
-Original Message- From: cygwin-owner On Behalf Of David Christensen Sent: 03 October 2004 03:15 Would you be interested in mentoring a willing volunteer? Certainly. Just stand still right here for just one minute KER-SQUELCH-SPLAT-SMACK [sound of massive slap round face with a very wet kipper] brushes dust off hands That'll learn 'im! 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/
RE: Request for a version/ revision/ release number for the whole Cygwin release/ distribution
On Mon, 4 Oct 2004, Dave Korn wrote: -Original Message- From: cygwin-owner On Behalf Of David Christensen Sent: 03 October 2004 03:15 Would you be interested in mentoring a willing volunteer? Certainly. Just stand still right here for just one minute KER-SQUELCH-SPLAT-SMACK [sound of massive slap round face with a very wet kipper] brushes dust off hands That'll learn 'im! Umm, this reminded me of a passage in a book I'm reading: You. Name a test to determine whether a recruit is fit to become a marine. The dwarf scratched her trimmed beard. The recruit is tied-- she hastily corrected herself --the recruit /volunteers/ to be tied to a sabre-toothed tiger and shut up in its cave. If the recruit comes out, she passed. If the tiger comes out, she failed. If she comes out riding the sabre-toothed tiger, make her a corporal.[*] I just felt that this sums up the whole volunteering bit nicely. Though perhaps it's time to TITTTL... Igor [*] With apologies to Mary Gentle. -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D. '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! Happiness lies in being privileged to work hard for long hours in doing whatever you think is worth doing. -- Dr. Jubal Harshaw -- 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/
RE: Request for a version/ revision/ release number for the whole Cygwin release/ distribution
-Original Message- From: Igor Pechtchanski Sent: 04 October 2004 15:31 I just felt that this sums up the whole volunteering bit nicely. Though perhaps it's time to TITTTL... Seconded! 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/
Re: Request for a version/ revision/ release number for the whole cygwin release/ distribution
Christopher Faylor writes: The total number of unique subscribers to cygwin, cygwin-apps, cygwin-talk, cygwin-xfree is 2542. That count may fall short by not taking into account those who read, say, gmane.os.cygwin, but do not subscribe to the cygwin list. -- Steven E. Harris -- 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/
RE:[OT] Request for a version/ revision/ release number for the whole Cygwin release/ distribution
On Mon, 4 Oct 2004, Hughes, Bill wrote: Igor Pechtchanski wrote: On Mon, 4 Oct 2004, Dave Korn wrote: ..snip.. Certainly. Just stand still right here for just one minute KER-SQUELCH-SPLAT-SMACK [sound of massive slap round face with a very wet kipper] brushes dust off hands That'll learn 'im! Ha, I've never seen a kipper more than a few ounces, now a fresh cod can easily be over ten pounds And has a harder^W more educational consistency. Umm, this reminded me of a passage in a book I'm reading: You. Name a test to determine whether a recruit is fit to become a marine. The dwarf scratched her trimmed beard. The recruit is tied-- she hastily corrected herself --the recruit /volunteers/ to be tied to a sabre-toothed tiger and shut up in its cave. If the recruit comes out, she passed. If the tiger comes out, she failed. If she comes out riding the sabre-toothed tiger, make her a corporal.[*] I just felt that this sums up the whole volunteering bit nicely. Though perhaps it's time to TITTTL... Igor [*] With apologies to Mary Gentle. Did she write 'Grunts!' ? There was a book I felt a bit uncomfortable laughing at... but I spent a lot of time laughing. Bill That's the book... Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D. '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! Happiness lies in being privileged to work hard for long hours in doing whatever you think is worth doing. -- Dr. Jubal Harshaw -- 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/
Re: Request for a version/ revision/ release number for the whole cygwin release/ distribution
On Mon, Oct 04, 2004 at 08:24:35AM -0700, Steven E. Harris wrote: Christopher Faylor writes: The total number of unique subscribers to cygwin, cygwin-apps, cygwin-talk, cygwin-xfree is 2542. That count may fall short by not taking into account those who read, say, gmane.os.cygwin, but do not subscribe to the cygwin list. Of course. It also doesn't represent all of the people who read via the web or all of the subscriptions which represent an internal mailing list. -- 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/
RE: Request for a version/ revision/ release number for the whole Cygwin release/ distribution
On Sat, 2 Oct 2004, David Christensen wrote: I disagree. Assume for a moment that all Cygwin project member development efforts can be put into the following bins: 1. Code development. 2. Design documentation. 3. Test suite development. 4. Test suite documentation. 5. Test suite execution and reporting. 6. User documentation. 7. Packaging for distribution. 8. Infrastructure development. 9. Infrastructure administration. 10. Version control/ configuration management of all of the above. 11. Personnel leadership and project management. You missed user support, like this mailing list, and package maintainers. Both parties are not usually developers. It would seem that bin #1 is consuming the majority of the effort. I disagree. Along with the massive 3+ developers in bin #1, their are a handfull of mailing list regulars who provide user support, thirty or so package maintainers (not developers; they just act as liasons between users and up stream development communities like rsync), and a FAQ and users guide maintainer. Also, those 3+ developers in bin #1 try for a healthy dash of 2 and 3 when practicle or necessary because of the implementation complexity. Notice the choice of the word maintainer in several contexts above. It accurately conveys that these people don't have time to create content, only maintain what others contribute and coordinate those contributions. I think that by changing priorities and re-allocating people and resources, it should be possible to create integration tests and a stable distribution. Such would increase Cygwin's acceptance and usage for potentially hundreds of millions of people. Is this not a good thing? So, rearranging the efforts of the above ~60 people will give you your desired result? It should be obvious from the responses so far that there are not many of those ~60 people interested in this rearrangement. You vastly over estimate the number of actual contributers to the Cygwin project and their time and skill levels. Let me restate: I am still waiting to hear from whomever fills the role of Cygwin volunteer coordinator. You assume their is such? Are you volunteering? As stated before, you have already heard from all persons who have positions of authority. Now do you understand the size of these vast resources you keep refering to? http://cygwin.com/who.html E.g. Hi, I'm the Cygwin volunteer coordinator. Thank you for offering to volunteer to help with the Cygwin project. Please read the following introductory materials so that you know what to expect and what is expected of you (URL, URL, URL). http://cygwin.com/contrib.html After that, please review the following task list (task board URL?) There used to be one, but it was removed as it was rarely used appropriately. -- Brian Ford Senior Realtime Software Engineer VITAL - Visual Simulation Systems FlightSafety International the best safety device in any aircraft is a well-trained pilot... -- 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/
Re: Request for a version/ revision/ release number for the whole Cygwin release/ distribution
Gary R. Van Sickle wrote: How many people have heard The Two Rules of Customer Service? 1. The customer is always right. The customer is indeed *NOT* always right but the trick is usually to make them *think* there always right. 2. When the customer is wrong, refer to rule #1. Everybody. How many have worked with actual customers and found out that their reputed infallability is vastly overestimated? More to the point: How much did you pay for that Cygwin there? $0? Then you ain't a customer. The best answer to this WRT most Open Source is: If you are dissatisfied with the application then I suggest that you take it back for a *FULL* refund! ;-) -- Why do they sterilize needles for lethal injections? -- 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/
RE: Request for a version/ revision/ release number for the whole Cygwin release/ distribution
-Original Message- From: cygwin-owner On Behalf Of Andrew DeFaria Sent: 04 October 2004 19:19 Gary R. Van Sickle wrote: How many people have heard The Two Rules of Customer Service? 1. The customer is always right. The customer is indeed *NOT* always right but the trick is usually to make them *think* there always right. 2. When the customer is wrong, refer to rule #1. Everybody. How many have worked with actual customers and found out that their reputed infallability is vastly overestimated? More to the point: How much did you pay for that Cygwin there? $0? Then you ain't a customer. The best answer to this WRT most Open Source is: If you are dissatisfied with the application then I suggest that you take it back for a *FULL* refund! ;-) Hell, Open source is _far_ more generous than that. If he's dissatisfied with the application, not only can he have his *FULL* refund, but in fact we'll refund him *DOUBLE*! And he can KEEP the app as well! We won't even insist on having it returned! 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/
RE: Request for a version/ revision/ release number for the whole Cygwin release/ distribution
It would seem that bin #1 is consuming the majority of the effort. I think that by changing priorities and re-allocating people and resources, it should be possible to create integration tests and a stable distribution. Such would increase Cygwin's acceptance and usage for potentially hundreds of millions of people. Is this not a good thing? Speaking for myself, as one of the package maintainers: I'm not open to, nor willing to be, re-allocated. I *volunteered* as a package maintainer in order to fill a particular position in the Cygwin ecosystem. I will continue to fill that position for so long as it is interesting and fun for me to do so. Someone trying to re-allocate me would immediately make the position non-interesting, not-fun, and result in my volunteering my time elsewhere. -Samrobb -- 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/
RE: Request for a version/ revision/ release number for the whole Cygwin release/ distribution
Corinna Vinschen wrote: I'm one of the maintainers of the Cygwin DLL ... [and] about 25 ported software packages. Creating a distribution ... is clearly the job for somebody else. OK Corinna is very busy. All people involved are very busy. Jorg Schaible wrote: Win XP Home SP2 ? So please ensure that you're also running: Wordpad XP SP2 Internet Explorer XP SP2 MS MediaPlayer XP SP2 Version control of hierarchical assemblies usually means that each component, assembly, etc., has it's own revision number. For assemblies, it's version number is incremented whenever it's component list changes (either by adding component(s), removing component(s), or changing component(s); this includes a component revision change). Bill of Material (BOM) systems implement such. The top level version number is commonly a marketing number and implementing with tags applied to all assemblies and components, as supported by the version control system. Whom do you suggest run Cygwin's MRP system? You've indicated that you have no interest in do it, so who are you volunteering for this endeavor? Max Bowsher wrote: You imply a rigid division where none exists. The Cygwin package maintainers are part of the community. OK but what the Cygwin project members want and what the users want isn't necessarily the same thing. And people in hell want icewater. Beggars can't be choosers dude. If you were paying $$$ for Cygwin perhaps your complaints would mean something, but you're not, so the bottom line is they don't. I think a lot of users would welcome a Cygwin stable distribution. I think a few users would welcome it. Most would continue to use the latest available software, which they should. But what either of us think is irrelevant to anything actually happening, considering neither of us is going to do anything to make any of what you talk about actually happen. I think application developers would also welcome it; this could increase the amount of software that runs on Cygwin. It would increase the amount of work application developers (assuming you mean package maintainers) would have to do. More work for no pay has never been welcomed by anybody in the history of the world. 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. Max Bowsher wrote: *EVERYONE* *ELSE* here is a *VOLUNTEER* *TOO*. Don't get upset -- I have had bad experiences volunteering, and just wanted to state my position up front. I took Max's statement to mean that nobody else here will tolerate their time being wasted either. And since you've stated you would at best play a miniscule role in the grand scheme you're envisioning, you're wasting our time and yours. The concept of a 'stable distribution' implies a considerable about of testing and infrastructure. Everyone, including myself, agrees on the intimidating scope of the task. The disagreement is on whether or not it should be undertaken; and if so, how and by whom. There is no disagreement here. If you can't answer how and by whom, you can save your keyboard: the whom is nobody and the how is irrelevant since there's no whom. I don't think there are enough potential volunteer man-hours to make such a thing feasible. I disagree. Assume for a moment that all Cygwin project member development efforts can be put into the following bins: 1. Code development. 2. Design documentation. 3. Test suite development. 4. Test suite documentation. 5. Test suite execution and reporting. 6. User documentation. 7. Packaging for distribution. 8. Infrastructure development. 9. Infrastructure administration. 10. Version control/ configuration management of all of the above. 11. Personnel leadership and project management. Invalid assumtion right off the bat. There are only two bins: 1. Work paid for by those who are willing to put their money where their mouth is. 2. Work done by volunteers who choose what it is they want to work on for themselves. It would seem that bin #1 is consuming the majority of the effort. I think that by changing priorities and re-allocating people and resources, it should be possible to create integration tests and a stable distribution. Since everybody allocates their own resources, your statement doesn't even make any sense. Such would increase Cygwin's acceptance and usage for potentially hundreds of millions of people. Is this not a good thing? There will never be hundreds of millions of people using Cygwin under any circumstances. If you actually believe that, you're off your nut. We have never claimed that Cygwin will never have bugs. Understood. But, I think the current development only distribution has more bug events than
Re: Request for a version/ revision/ release number for the whole Cygwin release/ distribution
Gary R. Van Sickle schrieb: It would increase the amount of work application developers (assuming you mean package maintainers) would have to do. More work for no pay has never been welcomed by anybody in the history of the world. Well, they only good reason to start such a project would be monetary benefits. Besides the simplification of having a (stable) cygwin snapshot release from time to time, where all packages play well together. And I don't see any problems to charge money for such distributions, as long as the GPL and sourceware's additional restrictions (?) are honored. Like every linux distributor makes money from selling CD's and charging for support. As long as on a server (publicly) the snapshot (release) is also provided. -- Reini -- 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/
Re: Request for a version/ revision/ release number for the whole cygwin release/ distribution
On Sun, Oct 03, 2004 at 06:07:18PM +0200, Reini Urban wrote: Well, the only good reason to start such a project would be monetary benefits. Besides the simplification of having a (stable) cygwin snapshot release from time to time, where all packages play well together. And I don't see any problems to charge money for such distributions, as long as the GPL and sourceware's additional restrictions (?) are honored. Like every linux distributor makes money from selling CD's and charging for support. As long as on a server (publicly) the snapshot (release) is also provided. Hey, an actual useful idea for advancing this concept! The Cygwin/X project has a contributions link here: http://x.cygwin.com/donations.html No one has complained about this so far, so I wouldn't mind adding another link for specific cygwin projects at the main site. If anyone is willing to do specific work that benefits cygwin for $$$, I'll set up a web page for PayPal (or whatever) links. I don't think this has to be limited activities related to a monolithic release, though. If someone wants to be paid to develop a full unattended mode for setup.exe that would be cool too. cgf -- 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/
Re: Request for a version/ revision/ release number for the whole Cygwin release/ distribution
On Sat, Oct 02, 2004 at 01:28:52PM -0500, Gary R. Van Sickle wrote: [David Christensen wrote:] Actually, I have already copied my Cygwin package tree to a CD for installing on other computers. I need to review the Cygwin license to see if a third-party distribution is allowed. It's like any other GPL'ed software. Give 'em the source and you're fine. TITTLL. (Sorry, couldn't resist.) -- 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/
RE: Request for a version/ revision/ release number for the whole Cygwin release/ distribution
Thank you for participating in this discussion. It may turn out to be an important issue in the future--however, I think there may be a few general concepts that have been used by participants in the discussion which concepts' meanings are not the same by all participants. This message does not contain any content along the original topic; my purpose in sending it is to try to synchronize concept definitions to aid future topical messages. On 2004-10-02T19:14-0700, David Christensen wrote: ) It also has nothing to do with the open-source movement. ) I disagree. Open-source software advocates claim that the open-source ) approach produces a better software. So, building and releasing an ) open-source software product while failing to do thorough testing ) results in unnecessary (inexcusable?) bugs and problems, which in turn In the open-source development model, there is no formal separation between development, testing, and use. Developers are users; users are testers. There is no formal producer/consumer relationship, and there is no semblance of a vendor/customer relationship. In the case of Cygwin's packaging and the software Cygwin includes, the packagers and developers are users and testers--but so are you. If you find a bug, your position within the community offers you a chance to investigate to whatever degree you are comfortable; to report to the appropriate caretakers directly; and even to implement corrections in many novel ways, stepping beyond the existing caretakers and any infrastructure put in place if you choose. It is your choice, as it requires the expense of your resources. But it does require the expense of your resources. ) Eric Hanchrow wrote: ) For what it's worth, I'm at this very moment moving my company's build ) system away from Cygwin, for precisely reason number 4: I cannot tell ) customers which Cygwin version to get. ) It's worth a lot -- thanks! :-) This derives from the same concept above: There is no vendor/customer relationship in this use of Cygwin. By reporting to a vendor that you, as an individual, are unhappy with a product and are moving to another, you give the vendor useful information as to how the vendor's available resources may be mismanaged. The Cygwin project has limited such resources that its caretakers can manage; reporting unhappiness and a move or threat to move to another piece of software therefore does not have any significant positive effect. ) How many people have heard The Two Rules of Customer Service? ) ) 1. The customer is always right. ) ) 2. When the customer is wrong, refer to rule #1. ) ) When you don't obey the rules, you lose the customer plus anyone he ) talks to. Bye, Eric. Go figure, Cygwin. Eric was not a customer. The Cygwin project lost a user and a potential tester. Practically, it lost the potential feedback Eric could have provided, which feedback could have helped make the distribution better in general. However, if Cygwin's caretakers had attempted to reassign resources to accomodate Eric, without actually having such resources available to assign, it could have lost a lot more than Eric's continued potential feedback could have provided: Upset volunteers, who provide not just potential feedback, but actual development resources. Cygwin's caretakers can not afford to take such actions; it is a choice of which harm is greater, and losing Eric's feedback is evaluated as the lesser of two harms. ) Christopher Faylor wrote: ) You received replies from two people in authority and one from the ) maintainer of the setup program. ) Let me restate: I am still waiting to hear from whomever fills the role ) of Cygwin volunteer coordinator. E.g. Hi, I'm the Cygwin volunteer ) coordinator. Thank you for offering to volunteer to help with the There is no volunteer coordinator. Volunteers generally offer specific resources and operate within a set of de facto standard procedures and loose formal protocols. ) Wow. David: Where are we gonna round up all these bodies? And by ) we I mean you, because nobody else is going to do it. ) If we make volunteering for Cygwin a positive, enjoyable, and ) success-filled experience for people of all levels of skill, then more ) and more people will volunteer. Unfortunately for this, I and perhaps many other Cygwin contributors have our backgrounds in Computer Science and/or open-source project management, not in human interaction planning. We can slowly evolve to the state you desire, but it is not a process that can be performed on any time table or through simple fiat. With that said, if you have any specific suggestions for modifying or extending procedures for interacting with volunteers*, it will help move the iterative process. * Keep in mind that procedures for interacting with volunteers is a formal way of labelling how we all work together, as we are all volunteers. ) Brian Dessent wrote: ) It would be one thing if you were offering to spear-head this
Re: Request for a version/ revision/ release number for the whole Cygwin release/ distribution
David Christensen wrote: [EMAIL PROTECTED]: 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. Every O/S and application I've used had a release number for the whole thing; Cygwin should as well. I would especially like to request that there be a stable distribution. Why? Because: [snipped out reasons] You're confusing (like it happens with Linux distros also) two things. There is kernel, in this case Cygwin.dll, and then there is applications, like bash, cat, ls etc. Of course there exists distributions that have some common number, like Fedora Core 2 or Debian 3.0r2, but those just mean that if you take them out of box they probably work together. But that's not always the case. And rarely is. 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. David 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. Well, you mean that you can give time but not waste it..? Isn't that an idea of volunteering - waste extra time you have. What latter came up is that if you see eg. Debian that is consired to be stable among distributions it's also damn old. Quote from The current stable distribution of Debian GNU/Linux is version 3.0r2, codenamed woody. It was released on November 21st, 2003. and base system is as old as Debian GNU/Linux 3.0 (a.k.a. woody) was released on 19th of July, 2002. So you see that being stable also means being old, because you have to test, fix, test and fix again. Well, what about defining that stable means availability for 99% of time? It really means that cygwin would fail for 3.65 days, every year... And that's a lot for mission critical system. Even 99,5% would mean about 1.8 days offline time... Well that's the about standards. Now have you even planned how to accept initially packages for testing, fixing, and finally accept packages for stable release? Defining process what you have tought could help a lot. But it would be great to have, at least one mentioned some other post, unattented install. It would be great to say that install these packages, maybe only select a proper mirror but otherwise it would do the trick and install one predefined Cygwin setup. One side note: If you develop software for customers (or public audience), where are the sources for published software..? -- Jani Tiainen -- 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/
RE: Request for a version/ revision/ release number for the whole Cygwin release/ distribution
[EMAIL PROTECTED]: Thank you all for your replies thus far. I suspected that my posting would generate traffic. :-) I would especially like to request that there be a stable distribution. This wish was inspired by my positive experiences with Debian stable -- e.g. feature frozen, unit and integration tested, with updates limited to bug and security fixes. Please note that Debian is a volunteer effort: http://www.debian.org/devel/join/ If they can do it, I bet we can too. 1. I use Cygwin for ... mission-critical backup chores. I don't use Cygwin at customer sites; it's failed me on my personal systems so I can't risk it on client machines. I view this as a huge waste of potential. I do not have the knowledge or resources to do unit and integration testing of (a subset of) Cygwin. I believe the task to be too big for any one person. So, let's all cooperate -- many hands make light work. I was recently bitten by the cron-2.6.2 EOF issue ... correction -- rsync-2.6.2 EOL issue. ... integration testing of Cygwin as a whole. ... Has anybody else noticed that software engineers tend to forget testing, while hardware engineers consider it mandatory? Every software engineer should take a Verilog (or VHDL) class and be converted, as was I. Both my software development process and the end result have improved greatly since I began writing software and its test suite concurrently. I do understand that creating a good integration test suite is a substantial and never-ending undertaking. Furthermore, testing does not prove correctness -- the game is how many 9's can you achieve for the given resources?. That said, little or no testing is not the correct answer. Every complex system needs integration testing. The Cygwin library and package developers are in the best position to create the first draft integration test suite(s) for their work(s). From there, testing needs to be done by second pairs of eyes, with ongoing developer coordination and support, to get the maximum benefit (e.g. correctness). So, each developer needs to be paired up with one or more testers. Unfortunately, software developer is commonly viewed as the hot, sexy role while software tester is commonly viewed as the menial, expendable role. Fortunately, there are still people, such as myself, who appreciate and enjoy the test role. Perhaps this is where my volunteer offer can be first applied. Their may be others of similar ilk lurking on this list, waiting for the opportunity. ... I would like to be able to burn Cygwin X.Y.Z onto a CD or DVD ... Actually, I have already copied my Cygwin package tree to a CD for installing on other computers. I need to review the Cygwin license to see if a third-party distribution is allowed. p.s. I hereby volunteer my time to work on implementing my request. I'm still waiting to hear from somebody in authority. Do I need to post to cygwin-developers and/or cygwin-apps? http://www.cygwin.com/faq/faq_3.html#SEC25 I understand that cannot possibly lead the effort to achieve my request; I don't have the skills or the time. I'm looking for a part-time position under the guidance of a leader who can mastermind a solution and feed me pieces to build and/or test. My skill set includes C, Make, Perl, RCS/CVS, web programming, database programming, Unix systems programming, Unix and Windows system administration, etc.: http://www.holgerdanske.com/dpchrist/ David -- 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/
Re: Request for a version/ revision/ release number for the whole cygwin release/ distribution
On Sat, Oct 02, 2004 at 12:03:09AM -0700, David Christensen wrote: cygwin mailing list address deleted There is no reason to include the email address in your messages. That just adds spam fodder to the archives. p.s. I hereby volunteer my time to work on implementing my request. I'm still waiting to hear from somebody in authority. Do I need to post to cygwin-developers and/or cygwin-apps? You received replies from two people in authority and one from the maintainer of the setup program. I see that you are subscribed to the mailing list so you should have seen these messages. Please respond to the points that have been made already rather than responding only to yourself. I understand that cannot possibly lead the effort to achieve my request; I don't have the skills or the time. I'm looking for a part-time position under the guidance of a leader who can mastermind a solution and feed me pieces to build and/or test. My skill set includes C, Make, Perl, RCS/CVS, web programming, database programming, Unix systems programming, Unix and Windows system administration, etc.: http://www.holgerdanske.com/dpchrist/ So far, no one has volunteered to lead this project. If there is someone out there, they'll have to announce themselves here. If there really is a huge clamor for this type of stable cygwin, I would expect that there would be one person out there who'd be interested in seeing it happen. From my personal experience with free software, I don't think it's likely that you're going to get much of a response given the I can't do this. I want someone else to do it type of message. Free software is usually advanced by people taking the initiative themselves, not by unknown people showing up in a mailing list and exhorting others to carry out their plans. If you are really interested in this maybe you should consider it a learning experience and volunteer to lead the project yourself. cgf -- 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/
RE: Request for a version/ revision/ release number for the whole Cygwin release/ distribution
On Oct 1 05:08, Gary R. Van Sickle wrote: 1. Roll up your sleeves, get to work, and let the list know when you're done. The maintainers (yes, I'm looking at you Chris) will at best see this as a threat to their little fifedom, and the only help you'll get will be in the form of snide comments and passive-aggression. Those who aren't openly hostile to your idea will likey rather work on other things. So, proactively you begin with the sniding comments. That's the spirit! Well, maybe I'm becoming JM, but I don't see any snideness there. You will note that my message, call it what you will, appears to have gotten through to a certain someone. For the moment at least. I was not referring to you Corinna if that's at issue, hence the quotes on the maintainers. -- Gary R. Van Sickle Brewer. Patriot. -- 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/
RE: Request for a version/ revision/ release number for the whole Cygwin release/ distribution
[EMAIL PROTECTED]: Thank you all for your replies thus far. I suspected that my posting would generate traffic. :-) I would especially like to request that there be a stable distribution. This wish was inspired by my positive experiences with Debian stable -- e.g. feature frozen, unit and integration tested, with updates limited to bug and security fixes. And I've had the same positive experience with Windows XP stable... plus tons of Windows Updates, plus SP1, plus tons of Windows updates, plus SP2 (Plus Cygiwn of course ;-)). And those guys get paid. That sort of massive infrastructure is what you're requesting, and only offering to donate part-time help to (from what I can tell) simply run tests somebody else has prepared. Please note that Debian is a volunteer effort: http://www.debian.org/devel/join/ If they can do it, I bet we can too. I know somebody could, that's not the issue. The issues are: 1. Who? 2. What would their motivation to do so be? Especially considering... 3. It's a herculean task that as several have pointed out already is not really acheivable (i.e., some bugs, even catastrophic ones, can still crawl under the door no matter how well you've locked it). 1. I use Cygwin for ... mission-critical backup chores. I don't use Cygwin at customer sites; it's failed me on my personal systems so I can't risk it on client machines. I view this as a huge waste of potential. Well guy, what *hasn't* failed someone on mission-critical something-or-other? There is no Debian Never-Fails Edition, is there? I do not have the knowledge or resources to do unit and integration testing of (a subset of) Cygwin. Then we have part of the answer to #1 above: Who == Somebody other than you. I would like somebody other than me to go to work for me in the morning, but what do you think the chances are of that happening? I believe the task to be too big for any one person. It's also too big to simply wish it into existence. So, let's all cooperate -- many hands make light work. The many hands already have more work than they can handle fixing the known bugs. I was recently bitten by the cron-2.6.2 EOF issue ... correction -- rsync-2.6.2 EOL issue. ... integration testing of Cygwin as a whole. ... Has anybody else noticed that software engineers tend to forget testing, while hardware engineers consider it mandatory? Yep. Every software engineer should take a Verilog (or VHDL) class and be converted, as was I. Both my software development process and the end result have improved greatly since I began writing software and its test suite concurrently. I do understand that creating a good integration test suite is a substantial and never-ending undertaking. Furthermore, testing does not prove correctness -- the game is how many 9's can you achieve for the given resources?. That said, little or no testing is not the correct answer. Right, it isn't. Rubbing sticks together to create fire isn't the correct answer to building a fire either, but such is the era in which we find ourselves. Every complex system needs integration testing. The Cygwin library and package developers are in the best position to create the first draft integration test suite(s) for their work(s). No, test development should be done by people not involved with the development of the software under test, or you have a conflict of interest. From there, testing needs to be done by second pairs of eyes, with ongoing developer coordination and support, to get the maximum benefit (e.g. correctness). So, each developer needs to be paired up with one or more testers. Wow. David: Where are we gonna round up all these bodies? And by we I mean you, because nobody else is going to do it. Unfortunately, software developer is commonly viewed as the hot, sexy role while software tester is commonly viewed as the menial, expendable role. Fortunately, there are still people, such as myself, who appreciate and enjoy the test role. Perhaps this is where my volunteer offer can be first applied. Their may be others of similar ilk lurking on this list, waiting for the opportunity. My guess is there isn't, or they'd already be developing tests and executing them. ... I would like to be able to burn Cygwin X.Y.Z onto a CD or DVD ... Actually, I have already copied my Cygwin package tree to a CD for installing on other computers. I need to review the Cygwin license to see if a third-party distribution is allowed. It's like any other GPL'ed software. Give 'em the source and you're fine. p.s. I hereby volunteer my time to work on implementing my request. I'm still waiting to hear from somebody in authority. No you aren't, you've heard from all of them and then some. Do I need to post to cygwin-developers and/or cygwin-apps?
Re: Request for a version/ revision/ release number for the whole Cygwin release/ distribution
David Christensen wrote: This wish was inspired by my positive experiences with Debian stable -- e.g. feature frozen, unit and integration tested, with updates limited to bug and security fixes. Please note that Debian is a volunteer effort: http://www.debian.org/devel/join/ If they can do it, I bet we can too. Quick reality check: Debian has over 1300 registered developers -- vetted, trusted package maintainers with CVS commit access. They probably have tens of thousands of clueful users that report bugs and follow up as necessary, and many hundreds of thousands of installations from which to take reports and collect stats about bugs. They have an elaborate infrastructure for their 12 supported platforms, and god knows how many hundreds of mailing lists and sub-communities. And of course the user groups, donated corporate support, etc. Cygwin barely has 1300 _total mailing list subscribers_. At last count there were less than 1k people subscribed to the main Cygwin list, and another 400 or so on digest mode. If I had to guestimate the number of developers who actively develop and patch Cygwin it would be between 5 and 10, with probably another additional 20 or 30 total package maintainers. The numbers just aren't comparable. It would be one thing if you were offering to spear-head this and forge ahead to new ground, but I'd like it but can't personally donate leadership comes off sounding kind of weak. Brian -- 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/
Re: Request for a version/ revision/ release number for the whole cygwin release/ distribution
On Sat, Oct 02, 2004 at 12:03:02PM -0700, Brian Dessent wrote: David Christensen wrote: This wish was inspired by my positive experiences with Debian stable -- e.g. feature frozen, unit and integration tested, with updates limited to bug and security fixes. Please note that Debian is a volunteer effort: http://www.debian.org/devel/join/ If they can do it, I bet we can too. Quick reality check: Debian has over 1300 registered developers -- vetted, trusted package maintainers with CVS commit access. They probably have tens of thousands of clueful users that report bugs and follow up as necessary, and many hundreds of thousands of installations from which to take reports and collect stats about bugs. They have an elaborate infrastructure for their 12 supported platforms, and god knows how many hundreds of mailing lists and sub-communities. And of course the user groups, donated corporate support, etc. Cygwin barely has 1300 _total mailing list subscribers_. At last count there were less than 1k people subscribed to the main Cygwin list, and another 400 or so on digest mode. If I had to guestimate the number of developers who actively develop and patch Cygwin it would be between 5 and 10, with probably another additional 20 or 30 total package maintainers. It's more like 3+ real developers. The total number of unique subscribers to cygwin, cygwin-apps, cygwin-talk, cygwin-xfree is 2542. I was using Fedora as an example but the concept is the same. Bringing up Debian reminds me that the other thing that happens in this kind of scenario is politics. Again, I saw some of this in Fedora but it was exacerbated by the strange relationship between Fedora and Red Hat. I've never paid close attention to Debian but I've heard that it has all sorts os laws and bylaws for dealing with contention. I suppose you could just duplicate those for cygwin. Or maybe you could try to go the XFree86 route. That would be interesting. The biggest obstacle, though, is that so far no one is lining up for this new plan. You obviously need people who think it's a good idea if you want to progress. Well, another obstacle is that the original proposer doesn't seem to be reading email... That's not a good sign either. cgf -- 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/
Re: Request for a version/ revision/ release number for the whole Cygwin release/ distribution
Gary R. Van Sickle wrote: No, test development should be done by people not involved with the development of the software under test, or you have a conflict of interest. Not entirely true. There's whitebox testing -- where knowledge of internals is used to craft the test; this is often done by the developer(s). Then there's blackbox testing -- where only the External Interface documentation is used to design the test; this is where the developer(s) should not be involved. Both are useful. But that's a side issue. On the main topic of this thread, I'm agnostic. If somebody wants to do it, all well and good. If their tests reveal bugs in my packages, I will apply any patches they generate. But I don't have the time or desire to spearhead -- or even participate -- in this effort; my hands are full right now with enough cygwin tasks... -- Chuck -- 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/
RE: Request for a version/ revision/ release number for the whole Cygwin release/ distribution
Gary R. Van Sickle wrote: No, test development should be done by people not involved with the development of the software under test, or you have a conflict of interest. Not entirely true. There's whitebox testing -- where knowledge of internals is used to craft the test; this is often done by the developer(s). Then there's blackbox testing -- where only the External Interface documentation is used to design the test; this is where the developer(s) should not be involved. I know, but if the developers are also developing the testing (be it white or black-box), you still have a conflict of interest. Better than nothing? Sure. But not as good as they have it in that Ideal World in which none of us live. Both are useful. But that's a side issue. On the main topic of this thread, I'm agnostic. If somebody wants to do it, all well and good. If their tests reveal bugs in my packages, I will apply any patches they generate. But I don't have the time or desire to spearhead -- or even participate -- in this effort; my hands are full right now with enough cygwin tasks... I think you echo the position of all except perhaps the OP there. -- Gary R. Van Sickle -- 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/
RE: Request for a version/ revision/ release number for the whole Cygwin release/ distribution
Thank you all for your comments. I have tried to respond to each person who replied, but may have omitted those where their topic is already covered below. Corinna Vinschen wrote: I'm one of the maintainers of the Cygwin DLL ... [and] about 25 ported software packages. Creating a distribution ... is clearly the job for somebody else. OK Corinna is very busy. Jorg Schaible wrote: Win XP Home SP2 ? So please ensure that you're also running: Wordpad XP SP2 Internet Explorer XP SP2 MS MediaPlayer XP SP2 Version control of hierarchical assemblies usually means that each component, assembly, etc., has it's own revision number. For assemblies, it's version number is incremented whenever it's component list changes (either by adding component(s), removing component(s), or changing component(s); this includes a component revision change). Bill of Material (BOM) systems implement such. The top level version number is commonly a marketing number and implementing with tags applied to all assemblies and components, as supported by the version control system. Max Bowsher wrote: You imply a rigid division where none exists. The Cygwin package maintainers are part of the community. OK but what the Cygwin project members want and what the users want isn't necessarily the same thing. I think a lot of users would welcome a Cygwin stable distribution. I think application developers would also welcome it; this could increase the amount of software that runs on Cygwin. 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. Max Bowsher wrote: *EVERYONE* *ELSE* here is a *VOLUNTEER* *TOO*. Don't get upset -- I have had bad experiences volunteering, and just wanted to state my position up front. The concept of a 'stable distribution' implies a considerable about of testing and infrastructure. Everyone, including myself, agrees on the intimidating scope of the task. The disagreement is on whether or not it should be undertaken; and if so, how and by whom. I don't think there are enough potential volunteer man-hours to make such a thing feasible. I disagree. Assume for a moment that all Cygwin project member development efforts can be put into the following bins: 1. Code development. 2. Design documentation. 3. Test suite development. 4. Test suite documentation. 5. Test suite execution and reporting. 6. User documentation. 7. Packaging for distribution. 8. Infrastructure development. 9. Infrastructure administration. 10. Version control/ configuration management of all of the above. 11. Personnel leadership and project management. It would seem that bin #1 is consuming the majority of the effort. I think that by changing priorities and re-allocating people and resources, it should be possible to create integration tests and a stable distribution. Such would increase Cygwin's acceptance and usage for potentially hundreds of millions of people. Is this not a good thing? We have never claimed that Cygwin will never have bugs. Understood. But, I think the current development only distribution has more bug events than users care to experience. I'd like to have a stable choice. If you are using it for mission-critical stuff, you should be performing appropriate tests in a testing environment before deploying new version to your production environment. That advice it common to any mission-critical system, not just Cygwin. Agreed. I took the risk on my personal systems and paid the price. This isn't the first time. It would be nice if it were the last. Yes, there is a lack of integration testing of the distribution as a whole. How can you test something as diverse as entire distribution? Pretty much only by putting it out there and letting people play with it, and seeing where it breaks. My approach for testing large systems is to test from the bottom up -- test the smallest practical pieces (unit tests), then assemblies (integration tests), then assemblies of assemblies (integration tests), etc., on up the hierarchy until you reach the top-level assembly (with the top-level integration tests). You can certainly burn Cygwin onto a CD right now. Yes; and I have, thank-you-very-much. :-) Dave Korn wrote: http://cygwin.com/acronyms#PCYMTNQREAIYR Is there a way to do it on MS Outlook 2003 SP1, other than manually deleting e-mail addresses? 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
Fixing quoting in Outlook (Was RE: Request for a version/ revision/ release number for the whole Cygwin release/ distribution)
On Sat, 2 Oct 2004, David Christensen wrote: Thank you all for your comments. I have tried to respond to each person who replied, but may have omitted those where their topic is already covered below. [snip] Dave Korn wrote: http://cygwin.com/acronyms#PCYMTNQREAIYR Is there a way to do it on MS Outlook 2003 SP1, other than manually deleting e-mail addresses? Searching the mailing list for the above acronym will bring up a bunch of threads with the discussion on how to do this in various mailers. In particular, they will mention the QuoteFix plugin for MS Outlook. A Google search for Outlook 2003 QuoteFix returns some pages that seem to indicate that QuoteFix is now compatible with Outlook 2003. All of the above could have been done by anyone with the knowledge that this mailing list is archived. Igor P.S. You're not doing anyone a favor by bunching up replies to various messages into one message -- for one, it breaks threading. Please don't do that. -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D. '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! Happiness lies in being privileged to work hard for long hours in doing whatever you think is worth doing. -- Dr. Jubal Harshaw -- 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/
Re: Fixing quoting in Outlook (Was RE: Request for a version/ revision/ release number for the whole cygwin release/ distribution)
On Sun, Oct 03, 2004 at 12:09:24AM -0400, Igor Pechtchanski wrote: On Sat, 2 Oct 2004, David Christensen wrote: Thank you all for your comments. I have tried to respond to each person who replied, but may have omitted those where their topic is already covered below. [snip] Dave Korn wrote: http://cygwin.com/acronyms#PCYMTNQREAIYR Is there a way to do it on MS Outlook 2003 SP1, other than manually deleting e-mail addresses? Searching the mailing list for the above acronym will bring up a bunch of threads with the discussion on how to do this in various mailers. In particular, they will mention the QuoteFix plugin for MS Outlook. A Google search for Outlook 2003 QuoteFix returns some pages that seem to indicate that QuoteFix is now compatible with Outlook 2003. All of the above could have been done by anyone with the knowledge that this mailing list is archived. Igor P.S. You're not doing anyone a favor by bunching up replies to various messages into one message -- for one, it breaks threading. Please don't do that. I had a long (and probably mean) response to this message that Igor responded to but I think Igor's above advice illustrates the basic problem here. David, you expressed that you don't know anything about cygwin works, how our current release process works, who runs the project, or how maintainers do their job. You seem to be under the impression that, for example, the rsync maintainer spends a lot of time on rsync development. You also didn't appear to know how to use setup.exe to downgrade your rsync when you had a problem. None of the above is a punishable offense but these facts do make it hard to take your arguments seriously. On top of that, your response contained cliches and generalities. For example, your answer to the question How do you get people to volunteer was You make them want to volunteer. With answers like that we'll be here a long time. Most of us (all of us who are responsible for cygwin) are technical here. Technical people are more likely to be swayed by details than rhetoric or homilies. Remember, that the people in charge are already technical professionals and most of us are quite familiar with what goes into making a stable release. If we weren't then it has been adequately explained by various notables here. What you need to provide now is a a rationale for how you are going to pull people into the fold and an idea of how you are proposing it will all work. I think you need to do some research and present a formal plan. And, in your plan, please try to avoid cliches like the customer is always right. There are no customers here (see the previously mentioned URL) and, as cliches go, that one is so obviously false that it doesn't really bear repeating. If you think that there is a way to get people to want to volunteer, then spell it out. As I said (and as I said a year ago), I'm willing to provide resources on the site that hosts cygwin.com but I'm not going to waste time setting things up until it is obvious that there is something solid behind this effort. It sure doesn't look like there is anything remotely solid now and given the email traffic so far, I can't even see how you can get there from here. -- Christopher Faylor spammer? - [EMAIL PROTECTED] Cygwin Co-Project Leader[EMAIL PROTECTED] TimeSys, Inc. -- 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/
Re: Request for a version/ revision/ release number for the whole Cygwin release/ distribution
David Christensen wrote: If we can build a fully automated Cygwin stable test suite and parallelize it across many computers (wishful thinking: SETI screen saver), it may be possible to do 100% testing of all changes prior to release -- major, minor, and updates. Fortunately for all the other major software projects like Redhat/Debian, their installer tools can be automated. The cygwin setup.exe is the sole supported means for installing and removing packages, and it requires user intervention. Yes, I know there are some command line parameters that are undocumented that you can kludge up an automated solution with, but I've never really seen anyone step up and say that they are working or even supported. From reading bug reports on the list, one of the major areas that Cygwin could be improved is just minor little issues that occur during setup. Oops, package x wasn't installed but is required. Oh, looks like that postinstall script has a minor bug that causes it to hang. And so on... Those are the kind of things that I think it would be great to solve (e.g. a nightly automated stock base install, with a test harness that ensures that stuff that should work on a base install does work) but at this point the whole setup infrastructure just isn't there. Perhaps that would be a managable sub-goal to focus on first -- separating setup into a scriptable backend and GUI frontend. I know it has been discussed before but it's no trivial undertaking. Really, I think everyone agrees that it would be great to have what you're describing... But the problem is that it requires a lot of initiative on somebody's part, and currently the people that would be most qualified to steer that initiative are too busy to do so. Brian -- 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/
Re: Request for a version/ revision/ release number for the whole cygwin release/ distribution
On Sat, Oct 02, 2004 at 09:49:29PM -0700, Brian Dessent wrote: David Christensen wrote: If we can build a fully automated Cygwin stable test suite and parallelize it across many computers (wishful thinking: SETI screen saver), it may be possible to do 100% testing of all changes prior to release -- major, minor, and updates. Fortunately for all the other major software projects like Redhat/Debian, their installer tools can be automated. The cygwin setup.exe is the sole supported means for installing and removing packages, and it requires user intervention. Yes, I know there are some command line parameters that are undocumented that you can kludge up an automated solution with, but I've never really seen anyone step up and say that they are working or even supported. From reading bug reports on the list, one of the major areas that Cygwin could be improved is just minor little issues that occur during setup. Oops, package x wasn't installed but is required. Oh, looks like that postinstall script has a minor bug that causes it to hang. And so on... Those are the kind of things that I think it would be great to solve (e.g. a nightly automated stock base install, with a test harness that ensures that stuff that should work on a base install does work) but at this point the whole setup infrastructure just isn't there. Perhaps that would be a managable sub-goal to focus on first -- separating setup into a scriptable backend and GUI frontend. I know it has been discussed before but it's no trivial undertaking. Really, I think everyone agrees that it would be great to have what you're describing... But the problem is that it requires a lot of initiative on somebody's part, and currently the people that would be most qualified to steer that initiative are too busy to do so. Good points. If you read fark.com, you'll note that sometimes news stories are posted with an additional still no cure for cancer tag, e.g. Fish fart scientists win Nobel Prize, still no cure for cancer If we were going to be improving cygwin so that more people used it and there were fewer complaints then there is a fair amount of low hanging fruit that could be grabbed. Improving setup.exe is one improvement (adding more help to it, clarifying some buttons, overhauling the UI). Improving cygwin's documentation (adding a new user's guide, maybe?) is another. Adding new tests to cygwin's test suite and running tests on an automated basis (an old chestnut from cygwin-developers that no one has ever stepped up for) is another one. I'd love for any new cygwin bug to be checked in with an addition to the cygwin test suite. We could look into ways of making openssh installation idiot-proof. We could create our own service manager that just had to be installed once and then managed all of cygwin's services. I could complete the fifo implementation in cygwin (it's not that far from finished). If we have limited resources then there are a lot of tasks that I'd like to see which I think would have a bigger impact developing a stable release. Maybe it's a false dilemma to see things this way and there is a group of people who'd love to do release engineering and QA for a monolithic cygwin release but can't help out with some of the more obvious problems that plague cygwin now. If you're out there, this is the time to step up. cgf -- 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/
RE: Request for a version/ revision/ release number for the whole Cygwin release/ distribution
I would like to request that this policy be reversed -- that there be a version number for the entire Cygwin release. Every O/S and application I've used had a release number for the whole thing; Cygwin should as well. I would especially like to request that there be a stable distribution. 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. 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. 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. David 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. Yikes, prepare yourself for one heck of a tantrum from certain regular(s) on the list! But tantrums aside, I can tell you pretty much for a fact that this isn't going to happen unless you do it all yourself, almost certainly as a project unconnected with cygwin proper. You'd have to at a minimum: 1. Develop and run apropriate integration tests, a herculean task in and of itself, especially considering there is nothing of this nature in place now for the entire project (though the cygwin DLL and many apps of course have 'make test's, but it sounds like that would not be sufficient for your very high standards). You *might* get *some* support from the maintainers on this, but you'd certainly be doing 99.44% of the heavy lifting. 2. Maintain the tested binaries in a cvs repository, so you could tag them for particular cygwin releases. This would be the easy part, but you'll be setting up, hosting, and maintaining this repository yourself, guaranteed. 3. Develop and maintain an installer package for the whole bajillion megabytes of cygwin+everything that runs on cygwin. You could probably cobble together some combination of a single-file installer ala InnoSetup and the cygwin setup program + your own setup.ini. Again, you'll get pretty much zero help here. 4. You'll have to come up with a versioning scheme that minimizes confusion between the cygwin version and your distro's version. You'd probably want to call it something like David's Cygwin Distro Version X.XX instead of Cygwin X.X.X, because the latter is pretty much just wrong. I'm sure that if you were to do all this, you could probably have a nice little cottage industry burning and selling Cygwin distros on CD/DVD. I personally don't use cygwin this way, as don't a lot of other people. I use whatever's newest unless forced to do otherwise (i.e. a bug is found), and I have no need for the bulk of the multitude of cygwin packages. I'd do one of three things if I were you: 1. Roll up your sleeves, get to work, and let the list know when you're done. The maintainers (yes, I'm looking at you Chris) will at best see this as a threat to their little fifedom, and the only help you'll get will be in the form of snide comments and passive-aggression. Those who aren't openly hostile to your idea will likey rather work on other things. 2. Work on part #1 above, but intended as a pre-latest-release screen for normal packages. Again, that'd be a massive task, and the individual package maintainers are probably not going to be very interested if they'd have to do any work beyond running a script. 3. Abandon all hope of anything like this happening. Testing is the bastard child of software (especially open source), and integration testing is the bastard child of testing. Nobody is going to volunteer to do this regardless of how many people express their opinions on the matter. Does it run? Ship it! ain't just for commercial software. I don't want to discourage you here, what you suggest as I say would have value to many people. But again, you'd have to be the one to do it, with little cooperation and/or help from anybody else. I wish you well. -- Gary R. Van Sickle -- 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/
Re: Request for a version/ revision/ release number for the whole Cygwin release/ distribution
David Christensen wrote: [EMAIL PROTECTED]: 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. Every O/S and application I've used had a release number for the whole thing; Cygwin should as well. I would especially like to request that there be a stable distribution. 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. 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. 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. You imply a rigid division where none exists. The Cygwin package maintainers are part of the community. 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. *EVERYONE* *ELSE* here is a *VOLUNTEER* *TOO*. The concept of a 'stable distribution' implies a considerable about of testing and infrastructure. I don't think there are enough potential volunteer man-hours to make such a thing feasible. Make no mistake, it is a *lot* of work. We have never claimed that Cygwin will never have bugs. If you are using it for mission-critical stuff, you should be performing appropriate tests in a testing environment before deploying new version to your production environment. That advice it common to any mission-critical system, not just Cygwin. Yes, there is a lack of integration testing of the distribution as a whole. How can you test something as diverse as entire distribution? Pretty much only by putting it out there and letting people play with it, and seeing where it breaks. You can certainly burn Cygwin onto a CD right now. Max. -- 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/
RE: Request for a version/ revision/ release number for the whole Cygwin release/ distribution
-Original Message- From: cygwin-owner On Behalf Of David Christensen Sent: 01 October 2004 06:31 [EMAIL PROTECTED]: 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
Re: Request for a version/ revision/ release number for the whole Cygwin release/ distribution
On Oct 1 14:16, Dave Korn wrote: 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. Absolutely. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader mailto:[EMAIL PROTECTED] Red Hat, Inc. -- 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/
Re: Request for a version/ revision/ release number for the whole cygwin release/ distribution
On Thu, Sep 30, 2004 at 10:31:26PM -0700, David Christensen wrote: cygwin blah.. http://cygwin.com/acronyms/#PCYMTNQREAIYR 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. Every O/S and application I've used had a release number for the whole thing; Cygwin should as well. I would especially like to request that there be a stable distribution. As others have pointed out, this has come up before. Here's one discussion: http://cygwin.com/ml/cygwin/2003-04/msg01449.html My offer to set up space on sourceware.org (aka sources.redhat.com aka cygwin.com) and establish a mailing list or mailing lists still holds. We could add a stable release tag to the main web page, too. All that we need is someone to maintain this beast. To reiterate what I said in the above thread, I'm, personally, not interested in undertaking this kind of release effort, especially given the limited number of cygwin package maintainers, all of whom have day jobs. I'm even less inclined now than I was before since I watched the pain of getting Fedora releases out the door when I was at Red Hat. The last time this came up, some people were going to attempt this but the effort seemed to vanish almost immediately. However, if there is now again more interest, then I'll again repeat the offer. Please don't underestimate the amount of work involved, however. I do understand why people would want someone to produce a stable release in which all packages have been tested. However, even given that, there will always be problems. Having been involved in Red Hat's RHEL support, I know that a monolithic release is not a panacea. 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. This assumes that somehow the cron-2.6.2 EOF issue (I'm not familiar with this and don't recall seeing it mentioned here) would have been caught in final testing. You can't make that assumption. It's entirely possible that problems like this could slip into a mega distribution. (Again, I speak from experience) Given that this is possible, what would you then suggest for a release policy? Should we release all of cygwin again to fix the cron EOF problem? Or should we release a hot fix just for cron? If we are going to be releasing a major release then we can't do it quickly, so you suffer as someone runs through complete integration testing. If we are going to be releasing hot fixes then that's not very different from the way things are handled now. I think your best bet is to follow Dave Korn's advice and generate a stable release that is right for your own situation. Use that and only uprade intelligently, i.e., follow the cygwin list to look for trends or problems before deciding to run 'setup.exe'. -- Christopher Faylor spammer? - [EMAIL PROTECTED] Cygwin Co-Project Leader[EMAIL PROTECTED] TimeSys, Inc. -- 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/
Re: Request for a version/ revision/ release number for the whole Cygwin release/ distribution
On 10/01/2004 at 12:31:34 AM, [EMAIL PROTECTED] wrote: Every O/S and application I've used had a release number for the whole thing; Cygwin should as well. --- end of excerpt --- At a minimum, I think that's quite an oversimplification and perhaps factually untrue? Have you used a Linux distribution for example? There's a single release number, but its really rather meaningless, because the first thing you do is install updates to various packages (possibly including the kernel). That's very similar to cygwin. You have a base version of the cygwin DLL, and version number for each package. I suspect that the best you'll have is to explicitly test and ship your product with a specific version of the packages that you use. -- 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/
RE: Request for a version/ revision/ release number for the whole cygwin release/ distribution
-Original Message- From: cygwin-owner On Behalf Of Christopher Faylor Sent: 01 October 2004 17:24 This assumes that somehow the cron-2.6.2 EOF issue (I'm not familiar with this and don't recall seeing it mentioned here) He meant rsync, not cron, and he meant EOL, not EOF, but apart from that... http://www.cygwin.com/ml/cygwin-announce/2004-09/msg00036.html 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/
Re: Request for a version/ revision/ release number for the whole cygwin release/ distribution
On Fri, Oct 01, 2004 at 11:52:15AM -0500, Fred Kulack wrote: On 10/01/2004 at 12:31:34 AM, cygwin-owner wrote: Every O/S and application I've used had a release number for the whole thing; Cygwin should as well. --- end of excerpt --- At a minimum, I think that's quite an oversimplification and perhaps factually untrue? Have you used a Linux distribution for example? There's a single release number, but its really rather meaningless, because the first thing you do is install updates to various packages (possibly including the kernel). That's very similar to cygwin. You have a base version of the cygwin DLL, and version number for each package. I suspect that the best you'll have is to explicitly test and ship your product with a specific version of the packages that you use. Yeah, I've always thought of the way that Cygwin does things as more of a feature than a bug. Cygwin's current policies do put the onus on the end user to figure out what's best for their use, but, really, that is true of any large software release. It's probably a lot more obvious with cygwin. As I said, I very am familiar with the effort that goes into releasing Red Hat's Enterprise Linux product and I'm somewhat familiar with the Fedora Project. I think that the Fedora project is closer to what is being requested for Cygwin. Unlike Cygwin, for Red Hat Fedora or RHEL, you don't normally run 'up2date', 'yum update', apt get, or whatever to pull down the next *major* version of emacs. You only get security errata or fixes for serious bugs. That's nice if that's all that you care about but it means that there are programmers somewhere who are noticing security problems and backporting fixes from the newest versions of emacs into the older versions that shipped with the stable release. That's a job that no one enjoys. I don't think we have any volunteers here for that. Another problem with Fedora and RHEL is that updating to the next major release isn't always supported without wiping out your installation and reinstalling. This is because it is very hard to track dependencies in everything that has changed in the course of development. Little things like switching from XFree86 to Xorg or using udev instead of devfs can cause problems in unanticipated ways, creating support headaches. If we did start releasing Cygwin in this way then we might have similar problems since people will not be updating incrementally and we would not be seeing problems when they occur. Instead we'd be seeing problems months after we made a change. Fedora has various flavors of development and testing repositories that you can connect to if you want to get the latest and greatest, so you can satisfy the cravings to always be on the cutting edge. Unfortunately Fedora has a much more technically active user base than cygwin does. Fedora is a much sexier product than Cygwin. This is illustrated, IMO, by the fact that the traffic on the Fedora lists dwarfs the cygwin lists. That means that there might be a couple of people working on emacs and there will be many more people testing things to make sure that they are stable. I don't think it is inconceivable that some kind of similar activities could spring up around cygwin, on a smaller scale. Maybe all that it would take are one or two people willing to spend a lot of effort in generating stable releases. Then the current cygwin release would just be a development channel for the stable release. While it's not inconceivable, I don't think it is very likely, though, and I think past conversations on the cygwin list show this. -- Christopher Faylor spammer? - [EMAIL PROTECTED] Cygwin Co-Project Leader[EMAIL PROTECTED] TimeSys, Inc. -- 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/
Re: Request for a version/ revision/ release number for the whole cygwin release/ distribution
On Fri, Oct 01, 2004 at 01:15:25PM -0400, Christopher Faylor wrote: As I said, I very am familiar with the effort that goes into releasing am very cgf (who only sees these things after hitting 'y' or when perusing the archives months later...) -- 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/
Re: Request for a version/ revision/ release number for the whole Cygwin release/ distribution
For what it's worth, I'm at this very moment moving my company's build system away from Cygwin, for precisely reason number 4: I cannot tell customers which Cygwin version to get. -- The one thing that unites all human beings, regardless of age, gender, religion, economic status or ethnic background, is that deep down inside, we all believe that we are above average drivers. -- Dave Barry -- 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/
Re: Request for a version/ revision/ release number for the whole cygwin release/ distribution
On Fri, Oct 01, 2004 at 01:22:56 -0400, Christopher Faylor wrote: On Fri, Oct 01, 2004 at 01:15:25PM -0400, Christopher Faylor wrote: As I said, I very am familiar with the effort that goes into releasing am very cgf (who only sees these things after hitting 'y' or when perusing the archives months later...) Wow, that's *some* time dilation you're experiencing! :-) Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D. '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! Happiness lies in being privileged to work hard for long hours in doing whatever you think is worth doing. -- Dr. Jubal Harshaw -- 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/
Re: Request for a version/ revision/ release number for the whole cygwin release/ distribution
On Fri, Oct 01, 2004 at 04:54:36PM -0400, Igor Pechtchanski wrote: On Fri, Oct 01, 2004 at 01:22:56 -0400, Christopher Faylor wrote: On Fri, Oct 01, 2004 at 01:15:25PM -0400, Christopher Faylor wrote: As I said, I very am familiar with the effort that goes into releasing am very (who only sees these things after hitting 'y' or when perusing the archives ^^ months later...) Wow, that's *some* time dilation you're experiencing! :-) You understand the meaning of the word or right? cgf -- 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/
Re: Request for a version/ revision/ release number for the whole Cygwin release/ distribution
On Fri, 1 Oct 2004, Eric Hanchrow wrote: For what it's worth, I'm at this very moment moving my company's build system away from Cygwin, for precisely reason number 4: I cannot tell customers which Cygwin version to get. Stock answer: use what's current Cygwin is an ever-changing project and it's really best for all concerned to keep up with the flow. Yes, it may be a little painful if you haven't refreshed in a while (say, from the b20 days :), but you will have something current and the maintainers are more likely to help out with solving a problem (should you have any). We use Cygwin for our NT builds at work. One developer hadn't updated in over a year and was starting to encounter some strange interactions with the latest Windows Service Pack. He did a refresh to current Cygwin stuff, had to update one env var (CYGWIN), and things were smooth sailing. There were some new things he'd been wishing for that magically appeared with the refresh too boot :) If you are advocating Cygwin for a customer who is using your products, then it really is your responsbility to keep current and make sure things are working with the latest Cygwin packages. This is true, reguardless of which OS/distro you are using. This will help your customers in the long run, because you are being vigilant and helping them when they have problems. It's part of customer service. Besides, it's fairly painless to run setup and simply let it upgrade existing packages. And, if you really must have a static image/snapshot of Cygwin, then keep the setup.ini that you used for your own work as well as the locally downloaded packages and offer that to your customers. This kind of solution has been attempted before by others (see the archives). The real problem is that no matter what you snapshot, it will become out of date very quickly, and if you have problems, the stock reply from every Cygwin maintainer will be upgrade to what's current first, then we'll look at your problem. This sentiment is fairly prevalent in many software businesses. Anyway, just my $0.02 -- Peter A. Castro [EMAIL PROTECTED] or [EMAIL PROTECTED] Cats are just autistic Dogs -- Dr. Tony Attwood -- 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/
Re: Request for a version/ revision/ release number for the whole cygwin release/ distribution
On Fri, 1 Oct 2004, Christopher Faylor wrote: On Fri, Oct 01, 2004 at 04:54:36PM -0400, Igor Pechtchanski wrote: On Fri, Oct 01, 2004 at 01:22:56 -0400, Christopher Faylor wrote: On Fri, Oct 01, 2004 at 01:15:25PM -0400, Christopher Faylor wrote: As I said, I very am familiar with the effort that goes into releasing am very (who only sees these things after hitting 'y' or when perusing the archives ^^ months later...) Wow, that's *some* time dilation you're experiencing! :-) You understand the meaning of the word or right? Usually, when I actually notice it. :-) Sorry for the noise. Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D. '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! Happiness lies in being privileged to work hard for long hours in doing whatever you think is worth doing. -- Dr. Jubal Harshaw -- 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/
Re: Request for a version/ revision/ release number for the whole Cygwin release/ distribution
Peter A. Castro wrote: to keep up with the flow. Yes, it may be a little painful if you haven't refreshed in a while (say, from the b20 days :), but you will have Ah. Cygwin B20.1. Man, those were the days. Cygwin was practically perfect in every way, bugfree, and featureful. It even made coffee! I miss B20. sniff 'Course, apparently the guy who started this thread misses B20 too -- those were the days of a single monolithic cygwin release with a single version number. If it wasn't in the full.exe installer, it wasn't available (not that you'd want anything else once you tasted your first cup of B20 coffee!) -- unless you went to disreputable third party sites like cygutils. :-) (Speaking of cygutils, Peter, be sure to read the private email I just sent you) -- Chuck http://users.ece.gatech.edu/~cwilson/cygutils/OBSOLETE/index.html -- 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/
Re: Request for a version/ revision/ release number for the whole cygwin release/ distribution
On Fri, Oct 01, 2004 at 06:05:06PM -0400, Charles Wilson wrote: Peter A. Castro wrote: to keep up with the flow. Yes, it may be a little painful if you haven't refreshed in a while (say, from the b20 days :), but you will have Ah. Cygwin B20.1. Man, those were the days. Cygwin was practically perfect in every way, bugfree, and featureful. It even made coffee! I miss B20. sniff 'Course, apparently the guy who started this thread misses B20 too -- those were the days of a single monolithic cygwin release with a single version number. If it wasn't in the full.exe installer, it wasn't available (not that you'd want anything else once you tasted your first cup of B20 coffee!) -- unless you went to disreputable third party sites like cygutils. :-) And releases sometimes didn't happen for more than a year so if there was a problem with bash, you had to wait for the whole cygwin release to be respun. The full.exe's were generated by a guy at Cygnus who knew InstallShield and we had to wait for his time to be freed up before a new release would be made available. Of course, I knew how to run InstallShield, too, but I didn't know the secret handshake that would allow one to upload things to the web site. Eventually, I sent email to the CEO asking if we couldn't loosen things up a little. He said, yes, we got a volunteer to write a new installer, and the rest is history. Of course, marketing said wait a minute a couple of months later but the source was already out of the bag by that point. cgf -- 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/
Request for a version/ revision/ release number for the whole Cygwin release/ distribution
[EMAIL PROTECTED]: 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. Every O/S and application I've used had a release number for the whole thing; Cygwin should as well. I would especially like to request that there be a stable distribution. 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. 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. 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. David 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. -- 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/
