This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

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

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 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, with ongoing updates only
for bug and security fixes.  The major and/or minor numbers only change
when user-visible features and interfaces change.  Given that Cygwin is
also a software development environment, API's also need to be treated
as features for purposes of numbering.

>> 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.  Bug fixes and security fixes are glossed over as an
expected part of the deal.

> However, on the assumption that you mean rsync, the problem
> presumably happened when you upgraded to the latest version, yes?

The issue appeared sometime in August.  My guess is that it was caused
by an update to some other package, because when I went to down-rev to
rsync-2.6.1, I didn't have it in my local package library.  But, I'm no
Cygwin expert and could be completely confused.

> 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

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

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

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?

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

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

> As others have pointed out, this has come up before.

As I suspected.  I did try digging in the mailing list archive, but only
the last year or so.

> My offer to set up space on (aka
> aka 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.

Thank you for the offer. :-)  You have anticipated future needs.

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

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

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

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

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

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.

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

> Please respond to the points that have been made already rather than
> responding only to yourself.

In progress.

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,


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

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

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

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,

> 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.  In practicality, I've never had a problem
with RH 4.1, 5.0, 6.2, 7.3 or Debian 3.0.

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

> 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)?  ;-)

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

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

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

> ... 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,
and most importantly: why.

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.

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.

> Well, another obstacle is that the original proposer doesn't seem to
> be reading email...  That's not a good sign either.

I've been trying to catch-up...

Charles Wilson wrote:
> 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...

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


Unsubscribe info:
Problem reports:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]