ImageMagick/Graphicsmagick

Charles Wilson cygwin@cwilson.fastmail.fm
Mon Dec 22 13:21:00 GMT 2003


fedora@studio.imagemagick.org wrote:
> As the lead developer of ImageMagick I would like to clear up a few
> misconceptions being stated on this list.
> 
>   1. Harold L Hunt II says: This package [GraphicsMagick] will replace
>      ImageMagick for various reasons. One of those reasons is that the
>      GM folks are committed to provide ABI stability and proper version
>      numbers, whereas IM is not making such a commitment and has already
>      made various arbitrary changes to ABI version numbers.
> 
>      This is something Bob Friensenhahn is trying to convince people of
>      but it is simply not true. 

But you HAVE made arbitrary changes in the ABI version numbers.  I know 
this because I BUILT the IM CVS sources back in November 2002 -- and the 
library was versioned using libtool's '-release' syntax (resulting in a 
library named cygMagick-5-5-2.dll).  Almost a year later, I updated to 
present CVS IM, and rebuilt, and got a library versioned using libtool's 
'-version-info' syntax, and a dll named cygMagick-X.dll (I don't 
remember, now, what 'X' was).

Being a good netizen, I decided to look thru the CVS history to discover 
when this change was made, and then if possible search the ChangeLog and 
IM mailing lists around that date for the reasons for that change 
(especially since, given the structure of the IM library directory tree 
and module/plugins, it seemed *to me* that the change was ill-advised; 
but I wanted to investigate the issue before raising a question that MAY 
have already been considered.)

Unfortunately, I discovered that (a) the current IM CVS has ZERO history 
before March 2003, and (b) that the change I was investigating occured 
during the 'dead zone' between November 2002 and March 2003.

So, we have an ABI change (on cygwin, the NAME of the DLL is PART of the 
ABI) that is not discussed, not documented, and the history of which was 
expunged from the public record.

If that's not an 'arbitrary change to ABI version numbers' then I'm a 
monkey.

And I really really had no dog in this race.  At the time I did my 
investigation, I was strongly biased in favor of IM -- I thought GM was 
an add-on to IM, and that we needed IM before we could add GM as an 
optional plugin.

Then I find missing CVS history, accusations of copyright infringement 
flying both ways like snow in a blizzard.  Honestly, at that point I 
just wanted to piss on both projects...

> http://studio.imagemagick.org/ states
>      our project goal of: ImageMagick's focus is on performance,
> 		 minimizing bugs, and providing stable APIs and ABIs.  Bob Friensenhahn
>      does not speak for ImageMagick.  He tends to diminish ImageMagick in
>      various mailing lists I assume in order to promote his ImageMagick
>      clone project, GraphicsMagick.

I don't know what Bob's motivations are, and I do not presume to speak 
for him or to be able to read his mind.  BUT, I've dealt with him on the 
libtool mailing list for over two years, and he's seemed to be a 
relatively sane guy in all of those dealings.

>   2. Daniel Reed says: GaphicsMagick is a feature-for-feature
>      replacement of ImageMagick.  This is simply not true.  GraphicsMagick
>      is missing many features that ImageMagick has and if you run
>      a program or script against the two you will in many cases get
>      different results.

Perhaps.  I don't know -- and I don't really care.  All I care about is, 
on the cygwin platform, (a) does it work, (b) is it packaged properly, 
and (c) [for libraries] does it provide a stable path for future 
upgrades and coexistence between multiple installed versions.  This last 
point is partly a (cygwin) packaging issue, and partly an upstream ABI 
issue.

Now, from my POV, I knew that Bob uses cygwin, AND uses it as a primary 
testbed for libtool and [IM/GM]-w-libtool on cygwin, and that therefore 
IF there were problems with package stability/coexistence/etc on cygwin, 
we had a high likelihood of getting our patches into GM (or libtool, if 
necessary).

As the only thing I had to judge IM on was the fact that years of CVS 
history were removed from the net subsequent to a dispute between 
developers over the propriety of certain code inclusion...that just 
didn't reflect well on the IM development process, and made me concerned 
about how any patches we submitted to IM would fare.

Plus: Forks are bad.  Forks are hard.  Forks just plain suck.  Thus you 
don't fork unless you've got a really good reason.  And a guy who, based 
on my prior dealings in the context of another project, seemed 
relatively sane, chose to take that path...

So I put my weight behind a switch to GM.  And that _seemed_ to have 
some influence on Harold, the only volunteer we had to maintaine ANY of 
these packages.  But Harold is his own man, and makes his own decisions...

[post edit: now that I've read the related thread on cygwin-apps, Harold 
says his decision was grounded in the code, and not on "rhetoric". 
Obviously that means my rhetoric wasn't persuasive either.  That'll pop 
the ol' swelled ego...  :-) ]

>   3. Daniel Reed says: I considered ImageMagick's to be votes for
>      GraphicsMagick.  Why vote at all if you are going to usurp the votes?
>      A vote for ImageMagick should remain with ImageMagick.  If you want
>      votes for GraphicsMagick have a separate vote.

Because we only have one volunteer maintainer, and he was only going to 
maintain one or the other, not both.  It made sense for our platform to 
switch the votes over -- and anyone who wanted to object ("I like IM and 
hate GM") certainly could have done so.  It's not like we're using 
secret ballots or anything.  Really, this is a weak argument.

> If you choose to support GraphicsMagick instead of ImageMagick, fine.  However,
> base your decision on facts, not misconceptions.

Okay, removing all spin from yourself and from Bob, we're left with the 
following facts:

1) you removed years of IM's CVS history from public access after a 
dispute over the propriety of certain code in the baseline.

2) there have indeed been undocumented changes to IM's ABI and library 
versioning, as established by my personal experience with your product.

3) GraphicsMagick is a fork of the IM baseline, which began around 
November 2002 subsequent to the dispute in #1.

4) There does appear to be some cross-polination between the two 
projects, even after the fork.

5) We have one volunteer to maintain *A* package.  He has decided to 
stick with GM, not IM.  That's HIS decision, not mine, yours, or anybody 
elses.  And as others have said, you are welcome to ITP an IM package 
for inclusion, **provided** it does not conflict with, and "plays nicely 
with" existing cygwin packages (like GM).  And don't worry, if Harold is 
unreasonable, we'll be watching.

Right, Harold? :-)

--
Chuck



--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/



More information about the Cygwin mailing list