Mail Archives: cygwin-developers/2001/03/08/15:00:12
On Thu, Mar 08, 2001 at 06:32:21PM +0300, Egor Duda wrote:
>>> >Those around me always complain the release version of Cygwin
>>> >DLL is updated too often, buggy and unstable. Please consider
>>> >more careful release management.
>
>i think separating 'stable' and 'development' branches can help a bit.
>i don't know about Chris and Corinna and others, but speaking of
>myself, i almost always can say, whether my patch is a bugfix and
>should go to the stable branch or feature addition, and should go to
>the development one. i understand that maintaining two branches and
>merging changes is extra pain, and that fixing some bug may require
>some major rewrite of signal or tty handling code, but, nevertheless,
>i'd like to see
This would be more work than I am willing to take on. I'm already
maintaining an internal-to-Red Hat stable branch which will someday be
1.2.0 as well as 19 or 20 other packages, in some fashion. I don't want
to take on the additional responsibility of managing another branch,
making releases on the other branch, announcing releases on the other
branch, tracking problems on the branch, etc.
The current development model has been modelled after linux. We produce
periodic updates numbered n.n.n and we also provide "prereleases" in the
form of snapshots. Our stable releases are, unfortunately, only available
from Red Hat, but, in reality, there is little difference between a Red
Hat stable release and version N.N.N of a net release. The current stable
release at Red Hat is based on 1.1.6, I believe.
If people are not availing themselves of the snapshots or building cygwin
from the sources then there is little that we can do to rectify that
problem. Or, I suppose, we could augment setup.exe to have some kind
of "install cygwin snapshot option" since the current method of having
to download a snapshot and install it may be beyond the capabilities of
many people.
And, maybe that is where the problem lies. It is obvious that the
Cygwin project is, by default, a consumer project attracting people with
a low average level of computer competency. If there is any barrier to
getting something done (like familiarity with gzip, for instance), then
we will not see anybody trying a snapshot. Of course, if the person
trying the snapshot is unfamiliar with gzip, it is unlikely that they
will be able to offer much in the way of feedback for the snapshots.
So, like any free software project, we have to rely on power users for
feedback and support. There are a few people fielding questions in the
Cygwin mailing list and I am amazed at their patience and diplomacy.
They are much appreciated and I daily kick myself for not measuring up
to their level of grace in my own responses on the list.
What we seem to be lacking are people who are willing to contribute time
in the way of patches, debugging, and maintenance. It seems that either
everyone is "too busy", "not interested", or they "don't know how".
There's not much that you can do about the first two but the third one
just takes effort that few seem willing to provide. Oddly enough just
about every one of the 69 people on this list has pledged that they were
going to be contributing something to Cygwin when I approved their
membership here. How many people do you see contributing, though?
This is one of the reasons that I am thrilled to see somebody like Egor
contributing code that attempts to improve tty and console handling.
This is some of the hairiest code in Cygwin but he's somehow managed to
figure out how to fix things there. I assume that this is because he is
undaunted by complexity, knows how to use a debugger, and understands
that source code is source code and is always imminently understandable.
I guess the bottom line is that Cygwin, or the challenge of improving
Cygwin, is important to some of us and not very important to others.
I will try to keep that in mind in my future responses. I will not
expect everyone else to be interested in finding solutions but I'll be
grateful when that rare individual steps forward and makes an attempt
either by contributing code/documentation or providing enough details
that we can at least try to track the bug down.
In retrospect, I think I've probably been too hard on people here who
report bugs without suggesting fixes. I'll stop doing that although,
I won't stop *gently* asking that they take a stab at fixing problems
themselves.
So, thanks for the suggestion Egor. I don't think I want to go this
way, though.
cgf
- Raw text -