[Mostly to Charles Wilson] Upgrading Cygwin's CVS

Charles Wilson cwilson@ece.gatech.edu
Mon Jan 13 03:04:00 GMT 2003


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@gnu.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/



More information about the Cygwin mailing list