Mail Archives: cygwin/2003/12/22/00:46:08
fedora AT studio DOT imagemagick DOT 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/
- Raw text -