This is the mail archive of the
mailing list for the Cygwin project.
RE: Request for a version/ revision/ release number for the whole Cygwin release/ distribution
- From: Daniel Reed <n at ml dot org>
- To: cygwin at cygwin dot com
- Date: Sun, 3 Oct 2004 14:51:27 -0400 (EDT)
- Subject: RE: Request for a version/ revision/ release number for the whole Cygwin release/ distribution
- Reply-to: cygwin at cygwin dot com
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
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
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
) > 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 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?
If you propose and lead a project of any scope, you may attract contributors
based solely on the merits of the project. You may find that they are
neither influenced by or even cognizant of your own background, even if you
try to make a point of announcing it!
People will follow because they believe that the work you are coordinating
needs to be done, and that they can contribute. If nobody follows, it is
because one or both of those requirements have not been met by anyone aware
of your project. In this case you will have to choose between changing the
goals and methods of the project; expanding the domain of exposure to a
wider audience; or reducing your need for other parties to contribute
(possibly by dropping the project altogether).
) 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.
This only applies to the management of assignable resources. The Cygwin
project has very few assignable resources.
Daniel Reed <firstname.lastname@example.org> http://people.redhat.com/djr/ http://naim.n.ml.org/
"True nobility lies not in being superior to another man, but in being
superior to one's previous self."
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html