Mail Archives: cygwin/2003/01/05/14:45:55
Max Bowsher wrote:
> Data point: I'm running cvs-1.11.4 compiled OOTB.
> Admittedly thats in flatfile-dbm emulation mode (MY_NBDM), but I need that
> to work with repositories using that mode.
>
> Am I right in saying that your patches consist of cosmetically updating
> cygwin32 -> cygwin, and enabling the use of gdbm?
There's also a bunch of fixes (in my withdrawn 1.11.2) to work with
modern autotools (at the time, they were still using ac-2.13 and am-1.5;
I see that as of 1.11.3 they are now using ac-2.53 and am-1.6.3, which
is a nice step forward)
Plus, in my port the gdbm stuff is now a configure option all by itself
-- in chuck-1.11.2, it doesn't hijack the MY_NDBM framework for its own
use as it did in chuck-1.11.0. To do this, all dbm_* calls thru-out
have been replaced with DBM_* macros, which are #defined appropriately
depending on configure options.
All of this was an effort to "harmonize" the gdbm-support stuff so that
it could be incorporated into the official mainline sources...
>>[No, I don't have a lot of respect for people who contemptuously
>>ignore patches without even the courtesy of a response...after a
>>couple of reminders over several weeks...]
>
>
> Yes, thats pathetic.
...and the effort was wasted. After the third or fourth reminder, I
finally did get a response, which basically boiled down to "we don't
take patches directly from programmers". They want all cvs patches to
be vetted by many many users somewhere AWAY from their own development.
(never mind that my patch HAS been used by many many cygwin users for a
few years) E.g. Red Hat uses the "foo" patch for several releases, and
"foo" proves itself -- then and only then would the cvs people consider
incorporating it into their tree. (but the cygwin "distribution"
doesn't count, apparently) It's similar to Linus' policy during
code-slush/feature-freeze periods, but cvs uses that policy ALL the time.
Unfortunately, given Cygwin's unique status, I am both a "programmer"
and a "distributor" (of THE cvs for cgywin). I pointed that out, but it
didn't sway them. So it was obvious that my patches would never be
accepted unless I somehow convinced Red Hat or Mandrake or Debian... to
use them first for a few years. And why would Red Hat's Linux
distribution folks, or the other Linux distributions, accept patches
intended to help cvs compile cleanly on Cygwin? [Red Hat (Linux)
*maybe* given their ownership of cygwin -- but still not very damn
likely; would they possibly destabilize(*) cvs on their core product in
order to help cygwin, even tho the cygwin developers (e.g. me) could
just keep shipping a fork?]
Screw that. I punted.
(*) from Red Hat Linux's perspective. The patches are very stable, but
"Gee, if the cvs developers won't accept these patches, then there must
be SOMETHING wrong with them -- and they certainly don't help us
(Linux)". It's a catch-22.
>>Anyway, I'm stunned to hear that the bozos running the cvs project
>>actually got around to releasing TWO new versions (1.11.3 and 1.11.4).
>
>
> Ah, you may be unsurprised to hear that 1.11.4 was simply fixing windows
> build regressions in 1.11.3, and was released the next day.
> On the other hand, you might be stunned by the release announcement, which
> says: thanks for the patches from X, Y and Z!
That is a stunner. Of course, I can't seem to find any record on any
mailing list archive *@cvshome or bug-cvs AT gnu DOT org of exactly how X Y and
Z got their patches to the core developers. I'm starting to think the
cvs people do their development on IRC or via some non-public medium.
They just don't seem to really do things the open-source way...although
in their defense, it seems that they have recently begun using
issue-tracking based on bugzilla.
> Extra bugfixes are always good. I just hope that cvsnt syncs with original
> cvs soon (still being based on 1.11.1).
Yes, I'm going to ask about that on the cvsnt mailing list -- and will
try to help them do so if they are willing. But not yet. :-)
--Chuck
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
- Raw text -