This is the mail archive of the cygwin-apps mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: cygport-0.9.3 in release-2


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]