128502 - Setup mozilla/image or /ill (image loading library)

Status: RESOLVED DUPLICATE of bug 66984

(Core :: Graphics: ImageLib, defect)

Description

[Dawn Endico]

We've been talking about this forever but i don't see where anyone has actually
filed a bug yet. Lets get this done before 1.0 so we're not stuck with this
silly name forever.

Comment 1

[Dawn Endico]

Attachment: patch 1 of 2

Comment 2

[Dawn Endico]

Attachment: patch 1 of 2

Comment 3

[Dawn Endico]

Attachment: patch 1 of 2 (*again*)

Comment 4

[Dawn Endico]

Attachment: patch 2 of 2

There's still a bug in this (or possibly the other) patch. I must have 
missed a DEPTH somewhere because the symlinks to image libraries indirect
by one level too many and the build doesn't work. i.e. it links to
../../../blah
when it should link to ../../blah

neither of these are tested on mac or windows yet although i've made (some of)
the necessary changes.

Comment 5

[Stuart Parmenter]

maybe it is just me, but I don't really see any point in changing the directory
name.  It has been there now for a year and changing it is only going to confuse
those working on it.

Comment 6

[Brendan Eich [:brendan]]

I don't see this justifying effort till after 1.0.

We've been over the "trade-offs" before -- the name is offensive to some in the
community, while humorous to others; more important to me and dbaron, it does
not autocomplete well (it's next to libpref under modules, and modules is
deprecated, that means don't put new code there!); it's obscure, so others who
want to help with image-fu have to be in on the joke.

We have vestigial gfx2 along with libpr0n, and in the long run, we should get
rid of foo2 that claims to take over what foo did (the view manager is a
successful example to emulate).  Just littering the tree with in-jokes and foo2s
is not a good practice, and I think we should do some clean up here -- after 1.0.

/be

Comment 7

[rbs]

Nice change. I was thinking of doing a talk and have a window in the background
with "ls -lR mozilla" during the talk to give an idea of all the energy that
goes into making these browsers that are today familiar to so many people. I am
afraid I will have to delete libpr0n before hand if the name is retained as the
audience might wonder what else is going on elsewhere... It looks like it is
worth having the patch in.

Comment 8

[Glenn Randers-Pehrson]

I mentioned this a long time back.  The response I got was that the real
name wasn't libpr0n but libimg2.  However, as long as the directory is
libpr0n, libpr0n is the real name.  Unfortunately it inhibits me somewhat
from making contributions, since I cannot brag to my boss about it or let
my family, friends, or the county sheriff know about it.  I've been submitting
patches that involve libpng, but not patches to libpr0n itself.  I have a
patch, for example, that would resolve bug 125436, that I'll submit once the
library name is changed.

Comment 9

[Stuart Parmenter]

whaaaaaaaaah

Comment 10

[Brendan Eich [:brendan]]

Ok, it's after 1.0 and the trunk is frozen.  The only argument against a rename
is the merge pain for the 1.0 branch.  That still may be compelling, although
perhaps ,v symlinks in the CVS repository could solve it.  Leaf?

/be

Comment 11

[Glenn Randers-Pehrson]

Dawn says:
> We've been talking about this forever...

Actually, not a lot.  There is bug 66984 which was marked "won't fix" 6 minutes
after it was opened and "verified" 3 minutes after that.  It was discussed a bit
in comments 1-6 of bug 66967, and in my input and some response in comments
46-49 of bug 18594 which was off-topic for that particular bug, I guess.  I
don't see any evidence that the choice of name "libpr0n" has had sufficient
review.  It's just a fait accompli (see comment #18 of bug 73535).

Glenn

Comment 12

[rbs]

[randeg, you have misread the comment -- note that it was Dawn who filed the
bug.]

Please, let's do the rename to nuture a high level of professional in all
aspects of the product.

At first, renaming was said to be too early (bug 79607 comment 2), then, after
dragging on, it was said to have been there too long (comment 5), and now
(comment 9).

It is hard not to infer from this that the intentaion to rename has really never
been there, and that the foot dragging was on purpose.

Since there have been similar tasks (e.g., the split of content+layout into two
directories - bug 43142, and there are even thoughts to remerge - bug 106161),
technical considerations aren't really a barrier for the renaming.

Comment 13

[hacker formerly known as [e-mail]]

Whaaaaaaaah, indeed.  When someone actually has a build patch or something that
needs review, then /msg me.  (If we really don't have anything better to waste
our collective time on, I have a few issues I can bring up to staff.)
  

Comment 14

[Glenn Randers-Pehrson]

I don't think it's a waste of time to remove a barrier to potential
corporate support of the library.

Dawn did provide patches.  If you think the new directory name (image) is too
boring, s/image/iguana/ or s/image/komodo/ or something before applying
them.   Glenn

Comment 15

[tor]

Anyone want to lead this?  The beginning of a release cycle (read: now) would
be an ideal time to perform this sort of renaming.

Comment 16

[rbs]

ping'ing alecf because of the opportunity for merging the DLLs:
e.g., mozilla/image = mozilla/jpeg (no need to keep jpeg as a root dir anymore)
  + imglib2.dll + imgicon.dll + imgmng.dll

[reminder: mozilla/image is brendan/staff's suggested dir name for holding
these]

Comment 17

[Alec Flett]

The general approach sounds good but I'm wary on trying to consolidate the
actual image decoder with the mozilla glue (i.e. merging libjpeg with libimg2) -
mozilla/image sounds great to me.

Comment 18

[Christian :Biesinger (don't email me, ping me on IRC)]

rbs: fwiw, we have other image libraries elsewhere in the tree, in modules/libimg/

Comment 19

[rbs]

All the more confusing. Yet another good incentive after all to house them under
mozilla/image/*.

Comment 20

[Christian :Biesinger (don't email me, ping me on IRC)]

so... what should mozilla/image look like? something like this?
image/
  libraries/
    libpng/
    libjpeg/
    libmng/
  decoders
  src
  public
  macbuild
  build

Comment 21

[rbs]

Something like that seems fine with me. Whoever does the patch might have a
variation, perhaps.

Comment 22

[Stuart Parmenter]

this bug is a dup

*** This bug has been marked as a duplicate of 66984 ***

Comment 23

[Glenn Randers-Pehrson]

Nine minutes (the time it took to open, close and verify bug #66984)
was not sufficient discussion of this proposal..  I object to this tactic,
unless you are willing to reopen 66984.

The name libpr0n and the accompanying libpr0n web site is a stupid stupid
offensive joke (IMO) and inhibits some people, myself included, from working
on files in the libpr0n directory.   Glenn

Comment 24

[rbs]

Re-opening because closing the bug means that there is no interest. Whereas
there is still interest to move to mozilla/image.

Comment 25

[Alec Flett]

I too object to the use of seafood in directory names.

Comment 26

[Stuart Parmenter]

this bug IS a dup.  If you don't like the current resolution on the other bug,
then thats your problem.  re-resolving as a duplicate.

*** This bug has been marked as a duplicate of 66984 ***

Comment 27

[rbs]

Changing title to reflect the consolidation that is proposed. Up to the bug
owner to re-assign to the [e-mail] if he is not intending to take any
action, and marking helpwanted if somebody else can pickup the torch.

Comment 28

[Stuart Parmenter]

taking this bug

Comment 29

[Stuart Parmenter]

.

Comment 30

[rbs]

.

Comment 31

[rbs]

taking myself.

Comment 32

[Stuart Parmenter]

I'm the module owner and there is no way I'm going to give you approval to make
this change.  Leave this bug marked as a dup.  Any further conversations should
take place in the original bug.

*** This bug has been marked as a duplicate of 66984 ***

Comment 33

[rbs]

Please leave this bug alone! Your module can be isolated outside of
mozilla/image, In either case, wait until a patch that touches your module is
submitted.

Comment 34

[Stuart Parmenter]

this bug *IS* a dup and I will continue marking it as such.

*** This bug has been marked as a duplicate of 66984 ***

Comment 35

[Hixie (not reading bugmail)]

First of all, Pavlov is correct, it is a duplicate. If you want to discuss this,
do it in the other bug.

Secondly, I have yet to understand why "libpr0n" is offensive, or why it would
block corporate contributions. Hell, it was originally written in a large part
by someone working for a corporation!

Thirdly, there is no point trying to write a patch for this -- a patch was
already written once (March of last year) and it was denied by the module owner.

Please continue any conversation in bug 66984.

Comment 36

[Glenn Randers-Pehrson]

Perhaps "libpr0n" standing alone isn't offensive.  But in connection
with the libpr0n web site (the first hit returned by Google), with which
I believe you are familiar, it is.

In the real world where I worked, heads have rolled for making jokes that seem
similarly innocuous.  The jokester and two levels of his supervision found
themselves out of work, on the grounds of creating a hostile work environment.

Incidentally I agree with you that the proper course is to reopen
bug #66984, if that would be allowed.

Glenn

Comment 37

[rbs]

You guys are leaving aside certain facts. There are two aspects:
1) renaming libpr0n which is still in the air due to the module owner's obstinacy.
2) setup a mozilla/image which has _already_ received [e-mail]'s
approval. This second item was an upshot in the course of discussing #1, but it
is like what you get in trade union bargaining. You _keep_ what you get and you
reserve the right to make a case for other things later.

By making #2 a duplicate of the current WONTFIX #1, the module owner is revoking
what has already been approved by [e-mail].

You can do #1 without doing #2. Conversely, you can do #2 without doing #1.
libpr0n is a set of  decoders whereas mozilla/image is meant to consolidate
other things such as the current mozilla/jpeg, mng, etc, excluding libpr0n if
the  module owner remains obstinate about it, and if staff doesn't decide otherwise.
I do not want to lose #2 which has already been OK'ed. If you thing the earlier
comments make this bug a duplicate, I am going to open a separate bug.

Comment 38

[Stuart Parmenter]

I don't think you understand.  Staff isn't going to give approval for a new
toplevel directory that only contains PNG and JPEG.  There is no reason to put
MNG there since we are removing it.  This also doesn't solve this bug since the
neither libpng or libjpeg are under the libpr0n directory and it doesn't help
anyone who "can't work on it because of a directory name."  Because of these
reasons, this bug is in fact a duplicate.  You tried to change this bug in to a
seperate bug by renaming the summary, but at the core, this bug is exactly the same.

While talking with dbaron today, he indicated that external libraries such as
libpng and libjpeg perhaps belonged under modules/.  It seems to me like they
belong under other-licenses/.  Assuming one of these two is in fact the case, it
makes absolutely no sense what so ever to create a new directory to hold those
libraries.

"image" and "images" are both ambiguous names.  Anyone new to the project would
think that this directory consisted of image files, not an image library.  I
don't like "imagelib", "libimage", or any abbreviations of those.  So far no one
has come up with a name that isn't ambiguous and that properly describes what it
does.  "ill" (image loading library) might work... dbaron suggested "i".

Comment 39

[Brendan Eich [:brendan]]

I was involved in OK'ing mozilla/image, but that was then -- a while ago.  Now,
we've got lots of real work to do: new app architecture, Gecko architecture
fixes, etc.  I don't see any point in renaming or reorganizing the tree now. 
For mozilla2.0, yes, absolutely.

rbs, I know this is important to you, but I hope you'll consider the above and
mark this bug Future, if not close it as INVALID.  Sorry to renege, times have
changed and we haven't the luxury of fiddling with directory names.

A few more points:

Since I and others agreed to mozilla/image, others have objected to that name's
vagueness.  They have a point.  For mozilla2.0, we'll want to address that
objection.  So I'm not sure a bug with the Summary of this one is even worth
keeping around.

I'm pretty sure no one will be fired from a job involving mozilla.org code over
modules/libpr0n being a subdirectory in the tree, but *concrete* evidence to the
contrary should be sent to me, in private.

Some people are offended by the (tired, to my eyes) ersatz-socialist-realist
look of mozilla.org and its logos.  As with libpr0n, we've had requests to get
rid of that look.  In my opinion, anyone who was a victim of communism, or who
knows a little history of the 20th century, should feel a little creeped out, to
say the least.  Nazi logos are anathema except for comic-book villains and when
labeling one's political enemies, but somehow the other kind of totalitarian
socialist system (the internationalist one, not the nationalist one), whose
followers killed tens of millions, gets off without a laugh, or no comment, and
people who object (whether kooks or not) are ridiculed.

Having said all that, while I think mozilla.org is in need of a logo/look
face-lift, such a change (so too, a libpr0n renaming) remains a low-priority
goal right now, and for more than a few milestones.

BTW, modules is not a good place for any new code.  It's a left-over from the
first Netscape modularity attempt, circa 1996.

/be

Comment 40

[rbs]

> "ill" (image loading library) might work...

Mozilla's "/sick"? what a name... this got me laughing. Funnier/better than what
is there right now. This open bug keeps the thinking going on, and provides a
starting point for the wider consolidation, as opposed to the dead-end of the
other cavalier WONTFIX bug.

Marking Future for now per brendan request, hoping pavlov will help with this later.

Comment 41

[Bobby Holley (:bholley)]

This is indeed a dupe. But I think that now that the dust has settled, we can re-open that other bug. ;-)