RE: Request for a version/ revision/ release number for the whole Cygwin release/ distribution

["Gary R. Van Sickle" <g dot r dot vansickle at worldnet dot att dot net>]

> 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 users care to 
> experience.  I'd like to have a "stable" choice.
> 

You don't seem to be getting the key issue here: If *you* would like
something that doesn't exist in Cygwin, *you* are going to have to pick up
an axe and start chopping.  You cannot wish anything, especially something
so ridiculously daunting as something like what you propose, into existence.

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

Then you better stop using computers, friend.  To paraphase a phrase, the
wonder is not that software generally works well, the wonder is that
software works at all.  We are in the stone age of software development.
And wishing it weren't so don't make it not so.

> 
> > 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).
> 

Then it seems to me you should get to work!  You have a clear if mile-high
view of the basics there, so start testing stuff.

> 
> > You can certainly burn Cygwin onto a CD right now.
> 
> Yes; and I have, thank-you-very-much.  :-)
> 

Well?  So you've got what you want, quitcher bichen! ;-)

> > 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?
> 
> I think there is a need for two distributions:
> 
> 1.  development -- the current system.
> 
> 2.  stable -- feature frozen, quality assured,

Assured by whom?  Who takes on that liability?

> 
> >> 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.
> 
> You guys are splitting hairs.  Most people see Red Hat Linux 
> 4.1, 5.0, 7.3, 9, etc., Windows NT, 2000, XP, etc., and it's 
> something that they can understand.

And something that has absolutely no meaning.

>  Bug fixes and security 
> fixes are glossed over as an expected part of the deal.
> 

And result in the "absolutely no meaning" part indicated above.

> > And you think this is the cygwin project's or rsync maintainer's 
> > fault?
> 
> I think the rsync issue points out a meta-problem -- 
> incorporation of library and/or package updates into the 
> Cygwin release without requiring overall integration testing 
> leads to broken stuff.  Until the meta-problem is addressed, 
> people who want stability are in for a bumpy ride.
>

Strap yourself in! ;-)
 
> 
> > 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?
> 
> It's my home network, so willing or not, I took the risk and 
> paid the price.  Now that I know more, I am more cautious.
> 

Once bitten, twice shy.  Makes a certain amount of sense.  Looking a gift
horse in the mouth really doesn't.

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

They make a lot of claims that have no basis in fact.  Welcome to the real
world my friend.

>  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 hurts the 
> public image of the entire open-source software movement.
> Open-source projects are supposed to aspire to a higher 
> standard, not a lower standard.
> 

Then do something about it.  Note that "do" != "wish somebody else would
do".

> 
> Let me put it another way and tie it in to volunteerism -- 
> did you guys volunteer so that your name would be on junk or 
> on quality?
> 

I was drafted.

;-)

> 
> > if you wanted to set up a company in the business of making Cygwin 
> > distros, you could do so ...
> 
> Is that an off-the-cuff remark, or are you corporate counsel 
> for whomever owns Cygwin and you're granting me a license to 
> create my own Cygwin distribution, including using the 
> trademarked name?
> 

Dude, come on.

> 
> > I myself maintain an approved distribution for internal use ...
> > I've been keeping an eye on the mailing list, and when it 
> seemed to me 
> > that the dll was going through a fairly stable patch, I rsync'd a 
> > local mirror.  And that's it.  If any packages turn out to 
> have major 
> > bugs or security holes, and even then _only_ if those 
> problems impact 
> > on the users who I have to support, then I'll update them.  If 
> > something new is released, and there is a demand for it 
> from my users, 
> > then I'll add it.  But anything that works, I'm not going to fix.
> 
> I would like to avoid duplication of effort.  If I have my 
> Cygwin distribution, you have yours, and dozens (hundreds? 
> thousands?) of others have theirs, wouldn't we all be better 
> served by coordinating our efforts and sharing in the 
> benefits?  Just imagine the quality we could achieve with so 
> many brains developing test vectors against the current 
> stable distribution.  :-)
> 

"Do" is also != "Imagine".

> > To reiterate what I said in the above thread, I'm, personally, not 
> > interested in undertaking this kind of release effort, ...
> 
> Would you be interested in mentoring a willing volunteer?
>

Hehhehee.
 
> 
> > This assumes that somehow the [rsync]-2.6.2 [EOL] issue ... 
> would have 
> > been caught in final testing.
> 
> Here is how I test my use of rsync -- I do an md5sum on the 
> rsync source box (Debian) and save it to a file, rsync 
> everything to the destination box (WinXP, Cygwin), do an 
> md5sum on the destination box and save it to another file, 
> and then diff the two md5sum files.  Add a little Perl and 
> Test::Harness and you've got an integration test.
> 

Integrate that test into the rsync distro somehow and submit a patch.  One
small step for Cygwin, one giant leap for Cygwin-kind.

> 
> > 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?
> 
> Assuming no user-visible changes other than correction of a 
> bug or a security flaw, I propose that it would be an update 
> for Cygwin "stable".
> 

CAUTION: Slippery Slope Ahead.

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

Wow.  Well, nobody can accuse you of thinking small!  Trouble is, ideas are
like... bellybuttons: everyone has one, and they are usually full of lint.

> 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!  :-)
> 

How?

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

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.

> When you don't obey the rules, you lose the customer plus 
> anyone he talks to.  Bye, Eric.  Go figure, Cygwin.
> 

Eric "cannot tell customers which Cygwin version to get".  Nobody even knows
what that means.  Furthermore, the onus is on him to figure out a way to
answer that question, or arrange things so that the question never gets
asked.  The onus is not on Cygwin volunteers to take care of his customers.

> Peter A. Castro wrote:
> > Stock answer: use what's current
> > ... 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.
> 
> Understood.  Creation of a "stable" distribution will require 
> additional maintainance effort.  But, because the user will 
> be reporting a bug against what should be a more stable 
> environment, perhaps the debugging will be easier.
> 

No, it won't.

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

You're vastly overestimating the formality of the Cygwin project, like by
three or four orders of magnitude.

>  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).
> After that, please review the following task list (task board 
> URL?) and contact the task requestor for the tasks that you 
> have an interest in helping with."
> 

www.cygwin.com

> Gary R. Van Sickle wrote:
> > 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,
> 
> Yes.
> 
> 
> > and only offering to donate part-time help to (from what I 
> can tell) 
> > simply run tests somebody else has prepared.
> 
> No.  I'll help build, feed, and clean up after the monster -- 
> whatever is needed -- but I'm an Igor and not a Dr. Frankenstein.
> 

That's exactly what I said: You want to paint the broad strokes, and have a
Mysterious Stranger do all the real work.

> 
> > 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).
> 
> It's a matter of choices:
> 
> 1.  The current Cygwin volunteers.
> 

...have all expressed disinterest.

> 2.  The success Cygwin will enjoy by having a stable 
> distribution that is publicly applauded and widely used.
> 

...is a complete and utter pipe-dream.

> 3.  The sooner we get started, the sooner it will become a 
> reality.  The first goal is one nine (e.g. 90%), then two 
> nines (99%), then three, etc..
> 

Here we agree, if by "we" you meant "I".

> 
> > Well guy, what *hasn't* failed someone on mission-critical 
> something- 
> > or-other?  There is no "Debian Never-Fails Edition", is there?
> 
> In principal, you're right.

QED.

>  In practicality, I've never had 
> a problem with RH 4.1, 5.0, 6.2, 7.3 or Debian 3.0.
> 

Somebody must have had problems, or there would never have been a need for
5.0.  Or 6.2.  Or 7.3.

You just got lucky.

> > 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?
> 
> So long as you don't expect a paycheck, I'm sure your 
> employer can arrange that.  ;-)
> 

I'm glad you're getting the point: As long as you expect nothing to happen,
you don't have to do any work.

> 
> > It's also too big to simply wish it into existence.
> 
> How about 1M+ little wishes (or however many lines of source 
> code go into Cygwin)?  ;-)
> 

A bajillion little wishes, ten bajillion, it all adds up to zero work done.
You know that.

> 
> > The many hands already have more work than they can handle 
> fixing the 
> > known bugs.
> 
> The only solution I can think of is to make a list, 
> prioritize it, and get started.  The need for tests will 
> drive the need for documentation, which will clarify 
> everyone's understanding of what we're building, which will 
> make it possible for us all to help each other succeed.  The 
> key is effective communication and organization of people.
> 

No, the key is bodies to do the work.  So far you have a confirmed nobody,
and won't do anything yourself.  Full stop dude, your Grand Unified Test
Theory is DOA.

> 
> > 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.
> 
> Given two sticks, a suitable rock, a piece of vine or root, 
> and some kindling, you can make a fire surprisingly fast.
> 

Ever tried it?  Even the British military suggests you not waste your time,
even in a survival situation.

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

Heheheheeee, well dude, you aren't just not in Kansas anymore, you're not
even on the same planet!

More importantly, and tellingly, you didn't answer the "we" == "you"
question.

> 
> > ... what more skills do you think are required to do this?  
> If you're 
> > reasonably proficient in all these, it seems to me that your skills 
> > are not the issue.
> 
> I lack the specific knowledge of how Cygwin is designed and 
> implemented,

Welcome to the club.  Now what?

> and most importantly: why.
> 

You don't know why Cygwin exists?

> Brian Dessent wrote:
> > 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.
> 
> Would you, or any of the Cygwin developers, follow a leader 
> who doesn't know how and why Cygwin is built, or all the 
> issues involved in creating an alternate, parallel distribution?
> 
> 
> But, I can play the role of pointy-haired manager if you 
> really, really want me to.  Muahahahaha!  ;-)
> 
> 
> I'm just trying to be realistic, and admit my limitations.
> 

All but the most important limitation: you're unable to convince anybody to
do the work you want done for you, gratis.

> Christopher Faylor wrote:
> > 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.
> 
> It will take time to grow support.  Successes and a positive 
> public facing will attract more volunteers.
> 

How are you going to show any "sucesses" of a project which has no bodies
doing the necessary work?  You're simply dreaming friend.

> > 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...
> 
> Another developer who is buried alive.
> 
> 
> Question:  is it better to add one more feature/fix one more 
> bug, or to cut the scope of work, chuck out the unstable 
> stuff, and crank up the quality of what remains?

Fix one more bug and/or add one more feature.

>  I've been 
> at several Silicon Valley companies that broke their (and my) 
> backs on the former; I succeed in my personal projects by 
> doing the latter.
> 
> 
> There is a saying in consulting engineering, "fast, cheap, 
> good -- pick any two".  Cygwin is "free", so cheap is a 
> given.  So the choice is fast or good.  I prefer good.  
> Therefore, I don't expect it to be fast.

And now we're all confused.

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