All users were logged out of Bugzilla on October 13th, 2018

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

RESOLVED DUPLICATE of bug 66984

Status

()

RESOLVED DUPLICATE of bug 66984
17 years ago
7 years ago

People

(Reporter: endico, Assigned: rbs)

Tracking

({helpwanted})

Trunk
Future
helpwanted
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments, 2 obsolete attachments)

(Reporter)

Description

17 years ago
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.
(Reporter)

Comment 1

17 years ago
Created attachment 72098 [details] [diff] [review]
patch 1 of 2
(Reporter)

Comment 2

17 years ago
Created attachment 72099 [details] [diff] [review]
patch 1 of 2
(Reporter)

Comment 3

17 years ago
Created attachment 72100 [details] [diff] [review]
patch 1 of 2 (*again*)
(Reporter)

Updated

17 years ago
Attachment #72098 - Attachment is obsolete: true
(Reporter)

Updated

17 years ago
Attachment #72099 - Attachment is obsolete: true
(Reporter)

Comment 4

17 years ago
Created attachment 72101 [details] [diff] [review]
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

17 years ago
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.
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
(Assignee)

Comment 7

17 years ago
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.

Updated

17 years ago
Priority: -- → P3
Target Milestone: --- → mozilla1.2alpha

Comment 8

17 years ago
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.
Blocks: 125436

Comment 9

17 years ago
whaaaaaaaaah
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
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

Updated

17 years ago
No longer blocks: 125436
(Assignee)

Comment 12

17 years ago
[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.
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.)
  
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

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

Comment 16

16 years ago
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

16 years ago
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.
rbs: fwiw, we have other image libraries elsewhere in the tree, in modules/libimg/
(Assignee)

Comment 19

16 years ago
All the more confusing. Yet another good incentive after all to house them under
mozilla/image/*.
so... what should mozilla/image look like? something like this?
image/
  libraries/
    libpng/
    libjpeg/
    libmng/
  decoders
  src
  public
  macbuild
  build
(Assignee)

Comment 21

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

Comment 22

16 years ago
this bug is a dup

*** This bug has been marked as a duplicate of 66984 ***
Status: NEW → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → DUPLICATE
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
(Assignee)

Comment 24

16 years ago
Re-opening because closing the bug means that there is no interest. Whereas
there is still interest to move to mozilla/image.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---

Comment 25

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

Comment 26

16 years ago
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 ***
Status: REOPENED → RESOLVED
Last Resolved: 16 years ago16 years ago
Resolution: --- → DUPLICATE
(Assignee)

Comment 27

16 years ago
Changing title to reflect the consolidation that is proposed. Up to the bug
owner to re-assign to the nobody@mozilla.org if he is not intending to take any
action, and marking helpwanted if somebody else can pickup the torch.
Status: RESOLVED → REOPENED
Keywords: helpwanted
Resolution: DUPLICATE → ---
Summary: rename mozilla/modules/libpr0n to mozilla/image → Setup mozilla/image

Comment 28

16 years ago
taking this bug
Assignee: leaf → pavlov
Status: REOPENED → NEW

Comment 29

16 years ago
.
Status: NEW → RESOLVED
Last Resolved: 16 years ago16 years ago
Resolution: --- → WONTFIX
(Assignee)

Comment 30

16 years ago
.
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
(Assignee)

Comment 31

16 years ago
taking myself.
Assignee: pavlov → rbs
Status: REOPENED → NEW
(Assignee)

Updated

16 years ago
OS: Linux → All
Priority: P3 → --
Target Milestone: mozilla1.2alpha → ---

Comment 32

16 years ago
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 ***
Status: NEW → RESOLVED
Last Resolved: 16 years ago16 years ago
Component: Build Config → ImageLib
Resolution: --- → DUPLICATE
(Assignee)

Comment 33

16 years ago
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.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---

Comment 34

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

*** This bug has been marked as a duplicate of 66984 ***
Status: REOPENED → RESOLVED
Last Resolved: 16 years ago16 years ago
Resolution: --- → DUPLICATE
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.
Status: RESOLVED → VERIFIED
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
(Assignee)

Comment 37

16 years ago
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 staff@mozilla.org'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 staff@mozilla.org.

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.
Status: VERIFIED → REOPENED
Resolution: DUPLICATE → ---

Comment 38

16 years ago
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".
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
(Assignee)

Comment 40

16 years ago
> "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.
Summary: Setup mozilla/image → Setup mozilla/image or /ill (image loading library)
Target Milestone: --- → Future
QA Contact: granrosebugs → imagelib
This is indeed a dupe. But I think that now that the dust has settled, we can re-open that other bug. ;-)
Status: REOPENED → RESOLVED
Last Resolved: 16 years ago7 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 66984
You need to log in before you can comment on or make changes to this bug.