From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10591 invoked by alias); 10 Nov 2008 06:06:36 -0000 Received: (qmail 10497 invoked by uid 22791); 10 Nov 2008 06:06:35 -0000 X-Spam-Check-By: sourceware.org Received: from out5.smtp.messagingengine.com (HELO out5.smtp.messagingengine.com) (66.111.4.29) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 10 Nov 2008 06:05:31 +0000 Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id E25061AC3F1 for ; Mon, 10 Nov 2008 01:05:28 -0500 (EST) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by compute1.internal (MEProxy); Mon, 10 Nov 2008 01:05:28 -0500 Received: from [192.168.1.3] (user-0cej09l.cable.mindspring.com [24.233.129.53]) by mail.messagingengine.com (Postfix) with ESMTPSA id 8205529139; Mon, 10 Nov 2008 01:05:28 -0500 (EST) Message-ID: <4917CF24.8070200@cwilson.fastmail.fm> Date: Mon, 10 Nov 2008 06:06:00 -0000 From: Charles Wilson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.8.1.17) Gecko/20080914 Thunderbird/2.0.0.17 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: Mailing List: CygWin-Apps Subject: Re: cygport-0.9.3 in release-2 References: <4906B2F8.4000708@users.sourceforge.net> <747eg4dsfpl4befpo8gb4qkgo3sm0d8fbi@4ax.com> <747eg4dsfpl4befpo8gb4qkgo3sm0d8fbi-e09XROE/p8c@public.gmane.org> <4907C0F1.2040005@cwilson.fastmail.fm> <4914ED2E.3000106@cwilson.fastmail.fm> <49168071.3050405@users.sourceforge.net> <49175419.5020409@cwilson.fastmail.fm> <4917790A.8040400@users.sourceforge.net> <4917A078.9090200@cwilson.fastmail.fm> <4917B664.2080703@users.sourceforge.net> In-Reply-To: <4917B664.2080703@users.sourceforge.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Mailing-List: contact cygwin-apps-help@cygwin.com; run by ezmlm Precedence: bulk Sender: cygwin-apps-owner@cygwin.com List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Mail-Followup-To: cygwin-apps@cygwin.com X-SW-Source: 2008-11/txt/msg00065.txt.bz2 Yaakov (Cygwin Ports) wrote: >> It only breaks the ABI (B?) if you do it the way you suggested: >> http://cygwin.com/ml/cygwin/2008-05/msg00038.html > > Yes, the concept is the same: ABI breakage affects previously-built > source packages but doesn't necessarily break API (IOW the .cygport > wouldn't need to be changed, but you'd need to fetch() from scratch). > API breakage affects the programmer, i.e. the .cygport itself would > require a change. Ack. >> There's really no "rule" like '-d ${CVS_MODULE##*/}' that is universally >> applicable: the module name and the -d option (if present) are >> orthogonal controls. You don't want to tie them together. > >> The way my patch does it, there is no API breakage -- but you have a new >> API entry point [the new CVS_DIR variable]. The price of API >> preservation is a proliferation of new ones; just ask Bill Gates. > > I should learn about API preservation from Micro$oft?!? Are you joking? > http://en.wikipedia.org/wiki/Criticism_of_Windows_Vista#Software_compatibility Um, yeah. That WAS the joke. Vista (and the old DOS-vs-Lotus123 wars) notwithstanding, the long-term joke about w32api is that Microsoft went to extreme lengths to not break existing apps; rather than change an API, they'd add 57 new ones (all those ...Ex() functions). With Vista (and arguably, when they started pushing .NET), API compatibility went out the window. But there were 13 years between Win95 and EOL-XP, with a major kernel change underneath -- and the w32api kept plugging away (getting bigger, and bigger, and bigger...) See: Strategy Letter II: Chicken and Egg Problems http://www.joelonsoftware.com/articles/fog0000000054.html "Windows 95? No problem. Nice new 32 bit API, but it still ran old 16 bit software perfectly. Microsoft obsessed about this, spending a big chunk of change testing every old program they could find with Windows 95. Jon Ross, who wrote the original version of SimCity for Windows 3.x, told me that he accidentally left a bug in SimCity where he read memory that he had just freed. Yep. It worked fine on Windows 3.x, because the memory never went anywhere. Here's the amazing part: On beta versions of Windows 95, SimCity wasn't working in testing. Microsoft tracked down the bug and added specific code to Windows 95 that looks for SimCity. If it finds SimCity running, it runs the memory allocator in a special mode that doesn't free memory right away. That's the kind of obsession with backward compatibility that made people willing to upgrade to Windows 95." Of course, this article (written four years later, same author) How Microsoft Lost the API War http://www.joelonsoftware.com/articles/APIWar.html is about how that USED to be true of Microsoft, but isn't true any longer. They'd lost "the backwards-compatibility religion," as of 2004. ('Course, one of the pieces of evidence -- in 2004 -- was...wait for it...Longhorn. That's right, our friend Vista! Hence your wiki page Criticism_of_Windows_Vista#Software_compatibility) > OTOH one can definitely learn from GNOME, whose developer platform has > maintained API compatiblity for 6 years while steadily adding new > features every six months. Right. Adding a new feature -- an API entry point, such as CVS_DIR -- doesn't break anything that doesn't use it. Ditto gnome_fancy_new_file_chooser() so long as gnome_boring_old_file_chooser() is still there. > I have been trying to maintain ABI/API stability, although I wouldn't be > surprised if I broke something along the way. /stability/ is different than /compatibility/. The former implies a resistance to ANY change, backwards-compatible or not. A corpse is "stable". I agree you have succeeded admirably in maintaining cygport's /stability/. >> The benefit of allowing some mechanism to pass a -d option to the cvs >> checkout is that I can ensure that my cvs.cygclass-generated origsrc >> tarball has the same directory layout as a make-dist-generated one. > >> So, it's probably moot for all current packages. > > Agreed. > > IOW it's purely hypothetical. I haven't found a case where this would > be necessary either. If you do find something, I'll be happy to look at > it, but cygport development has always been driven by practical usage. YOUR practical usage. MY practical usage has, well, taken a back seat, to your theoretical ideas about software design. It's taken over two years of regular and repeated complaints, to get grudging acceptance of changes that /almost/-but-not-quite support features I had working in Nov 2006. Features I implemented because I had an actual -- practical -- need for them: I couldn't use cygport effectively to support certain packages without them. Forgive me if I view platitudes about how cygport development is "driven by practical usage" with a somewhat jaundiced eye. Don't get me wrong; I appreciate that you created cygport in the first place -- it was a brilliant idea, and put the execrable gbs in its well-earned grave. And I definitely appreciate all your work with cygwin-ports and now cygwin-X. But this cygport "patch acceptance cycle" has, well, not exactly been a shining example of open source development; very much the cathedral, and nothing resembling a bazaar. -- Chuck