MNG+JNG and me

0 views
Skip to first unread message

Greg K.

unread,
Oct 12, 2003, 6:58:45 AM10/12/03
to
I am considering returning to Mozilla QA. For those who want to know, I left the project after libmng’s removal both because I objected to the removal and, more importantly, because good questions about the action were at best insufficiently responded to, and at worst simply ignored. I had — and have — no recourse, so I left.

Though answers have eventually been obtained to some questions related to libmng’s removal, what is still not clear to me is the rationale behind the action and whether or not the rationale has been satisfied.

Let me briefly summarize what I understand.
  1. libmng’s Mozilla maintainer and original integrator, tor, relinquished that role. Thus the integration was left without a maintainer (tor, bug 195280, comment 0).
  2. Though libmng’s disk footprint is not surprising given its’ functionality (tor, bug 195280 comment 6), libmng’s developer nevertheless offered to reduce this footprint as much as possible (Juyn, bug 195280, comment 24) and, indeed, it has been significantly reduced (Randers-Pehrson, bug 18574, comment 266).
  3. There is a gulf between the value placed on MNG+JNG’s feature set by a large part of the community (602 votes for bug 18574 as of this writing) and by key libmng developers (Parmenter, bug 195280 comment 69).
Certain other things remain unclear, however.
  1. Was there a requirement to reduce imglib’s disk footprint? What were the details of the requirement? Were savings achieved in any other area than libmng? What has been the result of the requirement?
  2. Have imglib or Gecko gained or retained any embeddors as a result of the removal?
  3. Was there an initiative to reduce Mozilla’s footprint overall? If so, what other areas were targeted for reduction, and what other reduction has been achieved?
  4. How was the target size of 50 KB (Parmenter, Bug 204520, comment 65) computed? If that number is unachievable (Randers-Pehrson, Bug 204520, comment 65) without crippling MNG+JNG, is it nonnegotiable?
  5. Could achievement of this target result in restoration to Seamonkey and Firebird without removing libpng? Have Camino and other embeddors not presently including MNG+JNG been consulted about what their requirements for inclusion would be?
  6. Are libimg’s maintainers and Mozilla.org’s drivers satisfied with the process followed, in regards to both the removal itself as well as communication before and after the fact? Will the same process be followed in the future in similar circumstances?
-- 
Greg K.
greg hyphen usenet at greg dot tcp dot see oh em

Boris Zbarsky

unread,
Oct 12, 2003, 1:20:57 PM10/12/03
to
Greg K. wrote:

I'm only responding to the point I know something about; don't construe
the lack of a response to the rest to mean anything.

> 3. Was there an initiative to reduce Mozilla’s footprint overall?

Yes, as part of performance work (less stuff to read off disk at
startup, less memory taken up, etc). In addition, some embedding
clients on memory-strapped platforms (think PlayStation 2) needed to be
able to run Gecko+OS+whatever in low-memory conditions (think 32MB for
the whole deal).

> If so, what other areas were targeted for reduction

Anything that could be reduced.

> and what other reduction has been achieved?

Two weeks ago I could have answered this question, but the tinderbox
move seems to have lost the old mZ test data (which is unfortunate). In
summary, the core libraries have gotten a few hundred kilobytes smaller
over the last several months, even ignoring the whole imglib issue.
layout alone has gotten at least 50-60k smaller (I distinctly recall
reductions of that size going in; there may have been more, since I only
tend to remember checkins over the last few weeks).

I've filed a bug to see about restoring the old test data; if that
happens you can take a look at the graph yourself and correlate the
reductions with corresponding checkins.

-Boris

Greg K.

unread,
Oct 12, 2003, 5:30:46 PM10/12/03
to
Errata:

Greg K. wrote:
> 3. There is a gulf between the value placed on MNG+JNG’s feature set


> by a large part of the community (602 votes for bug 18574 as of
> this writing) and by key libmng developers (Parmenter, bug 195280
> comment 69).

That should read bug 195280, comment 59.

> 4. How was the target size of 50 KB (Parmenter, Bug 204520, comment


> 65) computed? If that number is unachievable (Randers-Pehrson, Bug
> 204520, comment 65) without crippling MNG+JNG, is it nonnegotiable?

Randers-Pehrson's comment is actually Bug 204520, comment 68.

Greg K.

unread,
Nov 4, 2003, 3:09:17 AM11/4/03
to
Boris Zbarsky wrote:

> I'm only responding to the point I know something about; don't construe
> the lack of a response to the rest to mean anything.

Thanks for the response, Boris. Unfortunately, since nobody else
responded to the rest, I won’t be returning after all.

Peter Lairo

unread,
Nov 5, 2003, 4:30:46 PM11/5/03
to
Greg K. said on 04.11.03 09:09:

> Boris Zbarsky wrote:
>
>> I'm only responding to the point I know something about; don't
>> construe the lack of a response to the rest to mean anything.
>
> Thanks for the response, Boris. Unfortunately, since nobody else
> responded to the rest, I won’t be returning after all.

This is a sad state of affairs for mozilla. I can't believe nobody from
the "foundation" had the dignity to respond to such a well formulated
post. :(

--
Regards,

Peter Lairo

Boris Zbarsky

unread,
Nov 5, 2003, 6:29:49 PM11/5/03
to
Peter Lairo wrote:

> This is a sad state of affairs for mozilla. I can't believe nobody from
> the "foundation" had the dignity to respond to such a well formulated
> post. :(

The post asked for technical information. I suspect that none of the
people who had the relevant information read this newsgroup (which is
indeed unfortunate, but not surprising).

-Boris

Gervase Markham

unread,
Nov 6, 2003, 5:19:56 AM11/6/03
to
Peter Lairo wrote:

> This is a sad state of affairs for mozilla. I can't believe nobody from
> the "foundation" had the dignity to respond to such a well formulated
> post. :(

Who from the Foundation would you expect to know the answers to Greg's
questions?

I also think it's sad that he's leaving, and am very sad about the MNG
mess, but there's nothing I personally can do about it. :-(

Gerv

Peter Lairo

unread,
Nov 6, 2003, 8:50:54 AM11/6/03
to
Gervase Markham on 06.11.03 11:19 wrote:

> Peter Lairo wrote:
>
>> This is a sad state of affairs for mozilla. I can't believe nobody
>> from the "foundation" had the dignity to respond to such a well
>> formulated post. :(
>
> Who from the Foundation would you expect to know the answers to Greg's
> questions?

Anyone with an "mozilla.org" e-mail address, that's who I would expect.
Not necessarily to answer the questions, but to *address* them.
Something like: "Your questions seem valid and important. I don't have
the answers myself, but as an official member of the foundation i see it
as my responsibility to find out who does, and attempt to resolve this
issue."

If you cannot address such an important issue because you don't know
*who* in the foundation is holding the lid on it or who would have the
answers, then there is a serious communication problem in the foundation.

> I also think it's sad that he's leaving, and am very sad about the MNG
> mess, but there's nothing I personally can do about it. :-(

If not you, then who?

This seems to bring up a deficiency in the organisational structure of
the foundation. There should be some org-chart on a web page *clearly*
outlining the levels and areas of responsibility.
--
Peter Lairo

Michael Lefevre

unread,
Nov 6, 2003, 9:41:26 AM11/6/03
to
On 2003-11-06, Peter Lairo <Pe...@Lairo.com> wrote:
> Gervase Markham on 06.11.03 11:19 wrote:
>
>> Peter Lairo wrote:
>>
>>> This is a sad state of affairs for mozilla. I can't believe nobody
>>> from the "foundation" had the dignity to respond to such a well
>>> formulated post. :(
>>
>> Who from the Foundation would you expect to know the answers to Greg's
>> questions?
>
> Anyone with an "mozilla.org" e-mail address, that's who I would expect.

Your expectations aren't justified in mozilla's case - not everyone with a
mozilla.org e-mail address has the same status.

> Not necessarily to answer the questions, but to *address* them.
> Something like: "Your questions seem valid and important. I don't have
> the answers myself, but as an official member of the foundation i see it
> as my responsibility to find out who does, and attempt to resolve this
> issue."

You're assuming that it's possible to "find out who does".

> If you cannot address such an important issue because you don't know
> *who* in the foundation is holding the lid on it or who would have the
> answers, then there is a serious communication problem in the foundation.

I'm not sure it's entirely a communication issue - you're assuming that
the "who" is clearly defined.

[snip]


> This seems to bring up a deficiency in the organisational structure of
> the foundation. There should be some org-chart on a web page *clearly*
> outlining the levels and areas of responsibility.

That would be good. The current stuff at
http://www.mozilla.org/about/roles.html and the pages linked from there is
not very clear about the roles and responsibilities of Mozilla staff,
drivers, module owners and super-reviewers, who seem to have rather
fuzzily defined and somewhat overlapping roles, not to mention that the
linked pages are anything from 6 months to 2 years out of date.

Looking at the beta website, it seems as if this stuff may all be
disappearing in favour of a section that just talks about "we", "us" and
"Mozilla", which makes the website look better but leaves people
completely in the dark about how Mozilla works. The developer section
about still talks about super-reviewers and module owners but that doesn't
make a lot of sense when the groups aren't defined.

--
Michael

Peter Lairo

unread,
Nov 6, 2003, 10:19:28 AM11/6/03
to
Michael Lefevre on 06.11.03 15:41 wrote:
> On 2003-11-06, Peter Lairo <Pe...@Lairo.com> wrote:
>>Gervase Markham on 06.11.03 11:19 wrote:
>>>Peter Lairo wrote:
>>>
>>>>This is a sad state of affairs for mozilla. I can't believe nobody
>>>>from the "foundation" had the dignity to respond to such a well
>>>>formulated post. :(
>>>
>>>Who from the Foundation would you expect to know the answers to Greg's
>>>questions?
>>
>>Anyone with an "mozilla.org" e-mail address, that's who I would expect.
>
>
> Your expectations aren't justified in mozilla's case - not everyone with a
> mozilla.org e-mail address has the same status.

Where are the various statuses outlined?

>>Not necessarily to answer the questions, but to *address* them.
>>Something like: "Your questions seem valid and important. I don't have
>>the answers myself, but as an official member of the foundation i see it
>>as my responsibility to find out who does, and attempt to resolve this
>>issue."
>
> You're assuming that it's possible to "find out who does".

There must be someone "who does" know the answer, even if the answer is:
"Nobody at the foundation has the expertise to make this decision. You
seem to have the needed expertize. Do as you see fit - while keeping us
appraised."

There *must* be a "the-buck-stops-here" person. I thought it would be
one of the paid stff, like ASA.

>>If you cannot address such an important issue because you don't know
>>*who* in the foundation is holding the lid on it or who would have the
>>answers, then there is a serious communication problem in the foundation.
>
> I'm not sure it's entirely a communication issue - you're assuming that
> the "who" is clearly defined.

If it isn't, then that role should be clearly defined ASAP.

>>This seems to bring up a deficiency in the organisational structure of
>>the foundation. There should be some org-chart on a web page *clearly*
>>outlining the levels and areas of responsibility.
>
> That would be good. The current stuff at
> http://www.mozilla.org/about/roles.html and the pages linked from there is
> not very clear about the roles and responsibilities of Mozilla staff,
> drivers, module owners and super-reviewers, who seem to have rather
> fuzzily defined and somewhat overlapping roles, not to mention that the
> linked pages are anything from 6 months to 2 years out of date.
>
> Looking at the beta website, it seems as if this stuff may all be
> disappearing in favour of a section that just talks about "we", "us" and
> "Mozilla", which makes the website look better but leaves people
> completely in the dark about how Mozilla works. The developer section
> about still talks about super-reviewers and module owners but that doesn't
> make a lot of sense when the groups aren't defined.

An undesirable state of affairs indeed. :(

--
Peter Lairo

Michael Lefevre

unread,
Nov 6, 2003, 10:45:55 AM11/6/03
to
On 2003-11-06, Peter Lairo <Pe...@Lairo.com> wrote:
> Michael Lefevre on 06.11.03 15:41 wrote:
>> On 2003-11-06, Peter Lairo <Pe...@Lairo.com> wrote:
>>>Gervase Markham on 06.11.03 11:19 wrote:
>>>>Peter Lairo wrote:
>>>>
>>>>>This is a sad state of affairs for mozilla. I can't believe nobody
>>>>>from the "foundation" had the dignity to respond to such a well
>>>>>formulated post. :(
>>>>
>>>>Who from the Foundation would you expect to know the answers to Greg's
>>>>questions?
>>>
>>>Anyone with an "mozilla.org" e-mail address, that's who I would expect.
>>
>> Your expectations aren't justified in mozilla's case - not everyone with a
>> mozilla.org e-mail address has the same status.
>
> Where are the various statuses outlined?

They're not, AFAIK. The staff page doesn't even include all the staff,
AFAICS.

[snip]


> There must be someone "who does" know the answer, even if the answer is:
> "Nobody at the foundation has the expertise to make this decision. You
> seem to have the needed expertize. Do as you see fit - while keeping us
> appraised."
>
> There *must* be a "the-buck-stops-here" person. I thought it would be
> one of the paid stff, like ASA.

Well, the buck would ultimately stop with Mozilla staff (not particularly
Asa), yes (and now with the Mozilla Foundation). Staff/drivers did indeed
say "do as you see fit" - and the person saw fit to drop MNG and not
accept it back for not-clearly-specified reasons. At that point there
wasn't a clear way forward and neither the module owner nor staff/drivers
were communicating much.

>> I'm not sure it's entirely a communication issue - you're assuming that
>> the "who" is clearly defined.
>
> If it isn't, then that role should be clearly defined ASAP.

I agree. The question is whether the Mozilla folks see the need to review
all this stuff. Another point is that Firebird is operating in a rather
different way to how Mozilla/Seamonkey is operating, with less procedural
niceties and documentation happening and a much smaller number of people
able to make changes (so rather than having several people from a large
group of varying competance looking at each bit of code, you have a small
number of people who are trusted to make changes without review)

--
Michael

Boris Zbarsky

unread,
Nov 6, 2003, 11:08:50 AM11/6/03
to
Michael Lefevre wrote:
> The developer section
> about still talks about super-reviewers and module owners but that doesn't
> make a lot of sense when the groups aren't defined.

Super-reviewers:
http://www.mozilla.org/hacking/reviewers.html

Module owners: http://www.mozilla.org/owners.html

In both cases, the page is the first hit for the relevant term on
mozilla.org.

And yes, owners.html is reasonably up-to-date nowadays (it hasn't been
in the past). There are still a few @netscape.com addresses on there,
but for the most part all the people who are still active have updated
addresses on this page.

How are these groups not defined, exactly? ;)

-Boris

Robert O'Callahan

unread,
Nov 6, 2003, 12:00:16 PM11/6/03
to
Greg K. wrote:
> 3. Was there an initiative to reduce Mozilla’s footprint overall? If

> so, what other areas were targeted for reduction, and what other
> reduction has been achieved?

Let me add something to what bz said here. We've reduced the size (and
improved the performance) of gklayout.so/dll significantly, not by
cutting functionality but with time consuming and tedious simplification
of the code. For example, search bonsai for the checkins associated with
bug 190375. On the other hand, efforts to reduce the size of the MNG
code have focused on adding #ifdefs to change the set of features, but
there has been little or no effort to simplify the code itself. In fact,
Glenn is actively against doing that: see
http://bugzilla.mozilla.org/show_bug.cgi?id=204520#c38
in particular,
> The main reason that it is a lot larger than libpng is that libmng is
> writtin in a 21st century coding style that doesn't worry much about
> 10s of kilobytes of code size.
It's OK for Glenn to have that philosophy, but we don't share it.

To be honest, I was originally pushing drivers to restore MNG in the
default configuration, but this comment shook my confidence in the
quality of the code, and made me back off.

Also, a closer look at the MNG spec reveals that it's baroque and is a
lot more than just "animated PNGs". For example, consider the MAGN chunk:
http://png.unicast.org/pub/mng/spec/mng-lc.html#x18
> MAGN chunk rationale
> Q. Why not just use a BASI chunk to encode solid-color rectangles?
> A. The MAGN chunk also allows encoding of gradient-filled rectangles.
> Q. Why not just use PNG to encode gradient-filled rectangles?
> A. While PNG can encode vertical and horizontal gradients fairly
> efficiently, it cannot do diagonal ones efficiently, and none are as
> efficient as a 30-byte MAGN chunk plus a 4-pixel PNG.
So, the MNG designers consider it important for MNG to do diagonal
gradients efficiently --- and this is mandatory in the *Low-Complexity*
MNG profile! This shook my confidence in the design of the MNG format.

One thing missing from your summary of the situation is that we
(drivers) did say we're willing to have the MNG code back in the tree,
but that hasn't happened because there is no volunteer to maintain the
libmng-libimg glue code. Until such a volunteer steps forward this MNG
issue isn't going anywhere.

Rob

Michael Lefevre

unread,
Nov 6, 2003, 12:44:23 PM11/6/03
to
On 2003-11-06, Boris Zbarsky <bzba...@mit.edu> wrote:
> Michael Lefevre wrote:
>> The developer section
>> about still talks about super-reviewers and module owners but that doesn't
>> make a lot of sense when the groups aren't defined.
>
> Super-reviewers:
> http://www.mozilla.org/hacking/reviewers.html
>
> Module owners: http://www.mozilla.org/owners.html
>
> In both cases, the page is the first hit for the relevant term on
> mozilla.org.

I was referring to the new beta website, but evidently was not correct
- I see that I had simply not looked hard enough - the pages are there:
http://website-beta.mozilla.org/about/roles.html
http://website-beta.mozilla.org/hacking/reviewers.html , they are just no
longer linked from http://website-beta.mozilla.org/about/ . I don't see any
obvious links to the roles page except for the site map, and the page is
unchanged from the current site, so the various issues with it are still
there.

> And yes, owners.html is reasonably up-to-date nowadays (it hasn't been
> in the past). There are still a few @netscape.com addresses on there,
> but for the most part all the people who are still active have updated
> addresses on this page.

It may be better than it was, but I would hesitate to say that any page
that says that most Module Owners work for Netscape is "reasonably
up-to-date". :) Having up to date addresses for people that are active is
good, but not having inactive people listed at all, and having text that
reflected the list, would be better...

Having re-read the text on the Module Owners page, it does set out some
stuff that module owners are expected to do and what Mozilla staff will do
if there's disagreement - neither of which happened in any reasonable
timeframe in the case of the MNG argument.

--
Michael

Simon Paquet

unread,
Nov 6, 2003, 2:25:13 PM11/6/03
to
On 6 Nov 2003 17:44:23 GMT, Michael Lefevre wrote:

>> And yes, owners.html is reasonably up-to-date nowadays (it hasn't been
>> in the past). There are still a few @netscape.com addresses on there,
>> but for the most part all the people who are still active have updated
>> addresses on this page.
>
>It may be better than it was, but I would hesitate to say that any page
>that says that most Module Owners work for Netscape is "reasonably
>up-to-date". :) Having up to date addresses for people that are active is
>good, but not having inactive people listed at all, and having text that
>reflected the list, would be better...

...inactive/abandoned modules like Vixen or QT-GFX should also be removed. (I
guess that they're inactive/abandoned because their directories no longer exist
on the tree)

There are also some projects of which I'm not sure if they are still
used/maintained or if they still exist. The progress window module which resides
in http://lxr.mozilla.org/mozilla/source/modules/progress is an example. Is that
still an active project?

Ciao
Simon
--
In its default setup, Windows XP on the Internet amounts to a car
parked in a bad part of town, with the doors unlocked, the key in
the ignition and a Post-It note on the dashboard saying, "Please
don't steal this." (Washington Post)

Brendan Eich

unread,
Nov 6, 2003, 2:42:55 PM11/6/03
to Robert O'Callahan
One other point: mail dri...@mozilla.org if you want drivers to better
account for their decisions. Posting to m.seamonkey is, alas, not
guaranteed to reach any driver in a timely fashion. This doesn't mean
drivers don't have the "dignity" to reply, obviously, and it's silly
(Peter Lairo) to assume that's the case.

/be

Boris Zbarsky

unread,
Nov 6, 2003, 2:46:35 PM11/6/03
to
Boris Zbarsky wrote:
>> and what other reduction has been achieved?
>
> Two weeks ago I could have answered this question, but the tinderbox
> move seems to have lost the old mZ test data

bryner is the man and has restored the old data. See
http://axolotl.mozilla.org/graph/query.cgi?tbox=comet.mozilla.org&testname=codesize_embed&autoscale=1&size=&units=bytes&ltype=&points=&showpoint=2003%3A11%3A06%3A11%3A20%3A52%2C13135115&avg=0&days=300
for the last 300 days of "core library" codesize (all the data we have,
really). The core has shrunk by about 600-700 kB in that timeframe.

The corresponding "all, not just core" graph is
http://axolotl.mozilla.org/graph/query.cgi?tbox=comet.mozilla.org&testname=codesize&autoscale=1&size=&units=bytes&ltype=&points=&showpoint=2003%3A11%3A06%3A11%3A20%3A29%2C20832096&avg=0&days=300
but this is far less useful since it includes all sorts of things that
don't ship with the default builds (eg all the test apps).

-Boris

Boris Zbarsky

unread,
Nov 6, 2003, 5:44:13 PM11/6/03
to
Boris Zbarsky wrote:
> The module owner made a decision. It was disputed. Staff said that the
> code should go back in once the module owner is happy with it...
>
> What's a "reasonable timeframe" in your mind, given that most of the
> people involved have day jobs?

Note that I'm not disputing your "reasonable timeframe" assertion (I
happen to agree that response on the issue was slow to come), but I'd
like to know what you consider "reasonable".

-Boris

Boris Zbarsky

unread,
Nov 6, 2003, 5:40:26 PM11/6/03
to
Michael Lefevre wrote:
> It may be better than it was, but I would hesitate to say that any page
> that says that most Module Owners work for Netscape is "reasonably
> up-to-date". :)

You read the text? ;) Most people just want to look at the module of
interest...

> Having re-read the text on the Module Owners page, it does set out some
> stuff that module owners are expected to do and what Mozilla staff will do
> if there's disagreement - neither of which happened in any reasonable
> timeframe in the case of the MNG argument.

The module owner made a decision. It was disputed. Staff said that the

code should go back in once the module owner is happy with it...

What's a "reasonable timeframe" in your mind, given that most of the
people involved have day jobs?

-Boris

Brendan Eich

unread,
Nov 6, 2003, 8:31:56 PM11/6/03
to Greg K.
Greg K. wrote:

> I am considering returning to Mozilla QA. For those who want to know,
> I left the project after libmng’s removal both because I objected to
> the removal and, more importantly, because good questions about the
> action were at best insufficiently responded to, and at worst simply
> ignored. I had — and have — no recourse, so I left.
>
> Though answers have eventually been obtained to some questions related
> to libmng’s removal, what is still not clear to me is the rationale
> behind the action and whether or not the rationale has been satisfied.


Hi Greg, sorry I missed your posting; I've fallen way behind on
m.seamonkey, and I bet most other dri...@mozilla.org have too. I
suggest you mail drivers directly in the future when calling for
accountability.

> Let me briefly summarize what I understand.
>

> 1. libmng’s Mozilla maintainer and original integrator, tor,


> relinquished that role. Thus the integration was left without a
> maintainer (tor, bug 195280, comment 0).
>

That's the main problem.

> 1. Though libmng’s disk footprint is not surprising given its’


> functionality (tor, bug 195280 comment 6), libmng’s developer
> nevertheless offered to reduce this footprint as much as
> possible (Juyn, bug 195280, comment 24) and, indeed, it has been
> significantly reduced (Randers-Pehrson, bug 18574, comment 266).
>

It still duplicates PNG, without having the miles of testing that libpng
has had. We could probably switch PNG implementations over the course
of a major milestone, so this isn't a showstopper, but we shouldn't have
two PNG implementations in the default builds for long.

> 1. There is a gulf between the value placed on MNG+JNG’s feature


> set by a large part of the community (602 votes for bug 18574 as
> of this writing) and by key libmng developers (Parmenter, bug
> 195280 comment 69).
>

I keep saying this in bug after bug, at the risk of sounding
"anti-XForms" or (here) "anti-MNG". Votes don't fix bugs or own code.
Drivers can't include something that's unowned. Drivers have said we'd
be willing to take a reduced-footprint MNG subset, provided there's an
owner. Speaking for myself, I would host the whole MNG source, as an
optional extension, if its glue with libpr0n were actually maintained by
an owner.

> Certain other things remain unclear, however.
>

> 1. Was there a requirement to reduce imglib’s disk footprint? What


> were the details of the requirement? Were savings achieved in
> any other area than libmng? What has been the result of the
> requirement?
>

The reasons of the module (Image Handling: MNG) owner (t...@acm.org) for
MNG removal are given in
http://bugzilla.mozilla.org/show_bug.cgi?id=195280#c0.

I know of no requirements from drivers for imglib disk footprint reduction.

In general, disk footprint matters because (based on Mozilla and
Netscape experience) 10 minutes is around the knee in the curve where
download failures take off, and every 30 seconds shaved off around there
helps (Firebird is slightly above 10 minutes on narrowband). I'm
parroting others who have the experience reported here, but the 10
minutes knee makes some intuitive sense given how long phone calls last,
the likelihood that a kid or roommate picks up the phone, etc.

MNG is not particularly bad in terms of disk footprint; nothing is. The
problem (as with code footprint) is that every little bit helps, and we
can't include everything in the default build.

> 1. Have imglib or Gecko gained or retained any embeddors as a
> result of the removal?
>

Since we can't rewind reality and run the other experiment, who knows?
C'mon, there's no way to say.

But footprint matters. Gecko can't be all things to all people, and it
wasn't the last cookie it ate that made it big. MNG is simply not used
on the web, so justifying iincluding it in the default builds based on
what people actually browse is difficult, even counting those 600+ bug
voters.

If we had an animated-PNG-only subset of MNG, I think drivers would want
it, at a reasonable footprint increment over PNG, to avoid animated GIFs
in skins. But again, no one has offered to develop and own such a subset.

> 1. Was there an initiative to reduce Mozilla’s footprint overall?


> If so, what other areas were targeted for reduction, and what
> other reduction has been achieved?
>

Boris answered this with data.

> 1. How was the target size of 50 KB (Parmenter, Bug 204520, comment
> 65) computed?
>

SWAG.

> 1. If that number is unachievable (Randers-Pehrson, Bug 204520,


> comment 65) without crippling MNG+JNG, is it nonnegotiable?
>

Only if subsetting MNG is non-negotiable.

> 1. Could achievement of this target result in restoration to


> Seamonkey and Firebird without removing libpng?
>

Probably.

> 1. Have Camino and other embeddors not presently including MNG+JNG


> been consulted about what their requirements for inclusion would be?
>

No.

> 1. Are libimg’s maintainers and Mozilla.org’s drivers satisfied


> with the process followed, in regards to both the removal itself
> as well as communication before and after the fact? Will the
> same process be followed in the future in similar circumstances?
>

I doubt anyone is satisfied with everything that happened. Although the
imglib owners gave lots of warning, the cvs removal was not right, in my
opinion. The resistance to subsetting, and the insistence on "21st
century coding style" on the part of MNG's owners wasn't good, either.
There's plenty to improve on here, all around.

/be

Glenn Randers-Pehrson

unread,
Nov 6, 2003, 11:19:00 PM11/6/03
to
Robert O'Callahan <rob...@ocallahan.org> wrote in message news:<bodu5j$hq...@ripley.netscape.com>...

> Greg K. wrote:
> > 3. Was there an initiative to reduce Mozilla’s footprint overall? If
> > so, what other areas were targeted for reduction, and what other
> > reduction has been achieved?
>
> Let me add something to what bz said here. We've reduced the size (and
> improved the performance) of gklayout.so/dll significantly, not by
> cutting functionality but with time consuming and tedious simplification
> of the code. For example, search bonsai for the checkins associated with
> bug 190375. On the other hand, efforts to reduce the size of the MNG
> code have focused on adding #ifdefs to change the set of features, but
> there has been little or no effort to simplify the code itself. In fact,
> Glenn is actively against doing that: see
> http://bugzilla.mozilla.org/show_bug.cgi?id=204520#c38

Part of my effort this past summer was to look for areas that could be
rewritten to occupy a smaller footprint, and rewrite them. For example,
the mng initialization routine was compressed from about 40 routines to
one. The *discussion* of MNG reduction in bugzilla focussed on changing
the set of features because that is where there are choices to be made.
The footprint-reduction-without-feature-reduction saves about 90kbytes.
But since that still left us at over 200k, we had to discuss removing
features.

> in particular,
> > The main reason that it is a lot larger than libpng is that libmng is
> > writtin in a 21st century coding style that doesn't worry much about
> > 10s of kilobytes of code size.
> It's OK for Glenn to have that philosophy, but we don't share it.

That's not my philosophy. It's just what I found when I started looking
carefully at libmng.

> One thing missing from your summary of the situation is that we
> (drivers) did say we're willing to have the MNG code back in the tree,
> but that hasn't happened because there is no volunteer to maintain the
> libmng-libimg glue code

No *acceptable" volunteer.

Michael Lefevre

unread,
Nov 7, 2003, 7:48:10 AM11/7/03
to
On 2003-11-06, Boris Zbarsky <bzba...@mit.edu> wrote:
> Michael Lefevre wrote:
>> It may be better than it was, but I would hesitate to say that any page
>> that says that most Module Owners work for Netscape is "reasonably
>> up-to-date". :)
>
> You read the text? ;) Most people just want to look at the module of
> interest...

Sure - I'm trying to look at this from a "potential developer / outsider
wanting to know how this stuff works" point of view, rather than from the
point of view of someone that has managed to figure out how things work by
watching newsgroups, bugzilla and IRC for a few months.

>> Having re-read the text on the Module Owners page, it does set out some
>> stuff that module owners are expected to do and what Mozilla staff will do
>> if there's disagreement - neither of which happened in any reasonable
>> timeframe in the case of the MNG argument.
>
> The module owner made a decision. It was disputed. Staff said that the
> code should go back in once the module owner is happy with it...

Or, AIUI, when the module owner is happy with a person that will maintain
it.

> What's a "reasonable timeframe" in your mind, given that most of the
> people involved have day jobs?

For a response, maybe 3 or 4 days. If that response is "we're aware
there's an issue here, we'll think about it and post something within the
next 3 weeks", or "the person that needs to deal with this is busy with
something else and won't be back until X date" that's fine. The issue is
when there's just no response at all for weeks.

That the MNG thing was going to be an issue was clear in at least early
May, if not earlier - comment 57 in bug 195280 says dbaron wasn't aware of
an "official" reply from drivers at that point. There was then a further
3 or 4 weeks of argument, and, still with no official response from
drivers (AFAIK) and with questions about maintainers floating around, the
code was removed from the tree entirely. Given the amount of argument
that was happening in public, there should have been a response from
drivers somewhere public before that.

AFAIK, there wasn't a public response from drivers after that either -
Gerv attempted some mediating (I dunno whether that was a decision made by
staff/drivers or if he just decided to do it himself) and didn't get a
response from Pavlov for more than a month (which I also wouldn't say was
a reasonable timeframe...).

I don't see why it has to be (if I understand this correctly) that drivers
studiously ignore issues like this until they get asked to do something by
email - they could/should have stepped in before the code was even
removed, organised a discussion between drivers, the imglib owners and the
MNG people, and reached some kind of conclusion about the way forward.
You can't manage conflicts by keeping quiet and hoping they will go
away.

--
Michael

Gervase Markham

unread,
Nov 7, 2003, 7:48:21 AM11/7/03
to
Peter Lairo wrote:
> Gervase Markham on 06.11.03 11:19 wrote:
>> Who from the Foundation would you expect to know the answers to Greg's
>> questions?
>
> Anyone with an "mozilla.org" e-mail address, that's who I would expect.

That's just not true. For example:

" Are libimg’s maintainers and Mozilla.org’s drivers satisfied with
the process followed, in regards to both the removal itself as
well as communication before and after the fact? "

I am neither a driver nor a libimg maintainer, so I certainly can't
answer that question.

> Not necessarily to answer the questions, but to *address* them.
> Something like: "Your questions seem valid and important. I don't have
> the answers myself, but as an official member of the foundation i see it
> as my responsibility to find out who does, and attempt to resolve this
> issue."

Peter, you may not have noticed, but I've put a lot of effort into
attempting to resolve the MNG issue. To the possible annoyance of other
staff members, I have brought it up repeatedly in staff meetings. Where
we are now is where we are now, after all that.

>> I also think it's sad that he's leaving, and am very sad about the MNG
>> mess, but there's nothing I personally can do about it. :-(
>
> If not you, then who?
>
> This seems to bring up a deficiency in the organisational structure of
> the foundation. There should be some org-chart on a web page *clearly*
> outlining the levels and areas of responsibility.

It's fairly clear. tor and pav are responsible for libimg. libmng is (or
would be) part of libimg. Therefore you need to consult them about the
situation. Be prepared for a testy reply, as they have made their views
very clear in several bugs.

Gerv

Gervase Markham

unread,
Nov 7, 2003, 7:51:50 AM11/7/03
to
Robert O'Callahan wrote:

> One thing missing from your summary of the situation is that we
> (drivers) did say we're willing to have the MNG code back in the tree,
> but that hasn't happened because there is no volunteer to maintain the
> libmng-libimg glue code. Until such a volunteer steps forward this MNG
> issue isn't going anywhere.

Just to clarify: at least one person has stepped forward but was not
considered acceptable to the libimg maintainers.

Gerv

Gervase Markham

unread,
Nov 7, 2003, 7:49:36 AM11/7/03
to
Michael Lefevre wrote:

> They're not, AFAIK. The staff page doesn't even include all the staff,
> AFAICS.

It does. It doesn't include all the people on the st...@mozilla.org
email alias, but it does include all the staff.

>>There *must* be a "the-buck-stops-here" person. I thought it would be
>>one of the paid stff, like ASA.

The buck stops with Brendan for technical issues, and Mitchell for
non-technical issues.

Gerv

Peter Lairo

unread,
Nov 7, 2003, 8:32:41 AM11/7/03
to
Gervase Markham said on 07.11.03 13:48:

> Peter Lairo wrote:
>
>> Gervase Markham on 06.11.03 11:19 wrote:
>>
>>> Who from the Foundation would you expect to know the answers to
>>> Greg's questions?
>>
>>
>> Anyone with an "mozilla.org" e-mail address, that's who I would expect.
>
>
> That's just not true. For example:
>
> " Are libimg’s maintainers and Mozilla.org’s drivers satisfied with
> the process followed, in regards to both the removal itself as
> well as communication before and after the fact? "
>
> I am neither a driver nor a libimg maintainer, so I certainly can't
> answer that question.

You can "address" it.

>> Not necessarily to answer the questions, but to *address* them.
>> Something like: "Your questions seem valid and important. I don't have
>> the answers myself, but as an official member of the foundation i see
>> it as my responsibility to find out who does, and attempt to resolve
>> this issue."
>
>
> Peter, you may not have noticed, but I've put a lot of effort into
> attempting to resolve the MNG issue. To the possible annoyance of other
> staff members, I have brought it up repeatedly in staff meetings. Where
> we are now is where we are now, after all that.

I hadn't noticed, sorry for that. Thank you for attempting to resolve
this in the foundation. Too bad the others couldn't/wouldn't find a
better solution and method of handling this.

>>> I also think it's sad that he's leaving, and am very sad about the
>>> MNG mess, but there's nothing I personally can do about it. :-(
>>
>>
>> If not you, then who?
>>
>> This seems to bring up a deficiency in the organisational structure of
>> the foundation. There should be some org-chart on a web page *clearly*
>> outlining the levels and areas of responsibility.
>
>
> It's fairly clear. tor and pav are responsible for libimg. libmng is (or
> would be) part of libimg. Therefore you need to consult them about the
> situation. Be prepared for a testy reply, as they have made their views
> very clear in several bugs.

It seems perhaps tor and pav shouldn't have that role/power. Has that
been considered? Are there others who would be better qualified?

--
Regards,

Peter Lairo

Simon Paquet

unread,
Nov 7, 2003, 9:52:54 AM11/7/03
to
On Fri, 07 Nov 2003 14:32:41 +0100, Peter Lairo wrote:

>>>> I also think it's sad that he's leaving, and am very sad about the
>>>> MNG mess, but there's nothing I personally can do about it. :-(
>>>
>>> If not you, then who?
>>>
>>> This seems to bring up a deficiency in the organisational structure of
>>> the foundation. There should be some org-chart on a web page *clearly*
>>> outlining the levels and areas of responsibility.
>>
>> It's fairly clear. tor and pav are responsible for libimg. libmng is (or
>> would be) part of libimg. Therefore you need to consult them about the
>> situation. Be prepared for a testy reply, as they have made their views
>> very clear in several bugs.
>
>It seems perhaps tor and pav shouldn't have that role/power. Has that
>been considered? Are there others who would be better qualified?

Peter, I don't know if you noticed it, but at the moment we have to few
developers and definitely not too many. So there's obviously not much choice
when looking for another module owner.

I also think that you are very rude here. I agree with you that Tor and Pavlov
have made a wrong decision in the "mng-crisis", but we all know that they had
their reasons for this and most of them were very good. In addition they've been
libimg-maintainers for a very long time and have done a terrific job there. I
think it's unfair to consider, that they should give up there roles, just
because they made a decision we both don't agree with.

Michael Lefevre

unread,
Nov 7, 2003, 9:53:30 AM11/7/03
to
On 2003-11-07, Peter Lairo <Pe...@Lairo.com> wrote:
> Gervase Markham said on 07.11.03 13:48:
>> Peter Lairo wrote:
>>
>>> Gervase Markham on 06.11.03 11:19 wrote:
>>>
>>>> Who from the Foundation would you expect to know the answers to
>>>> Greg's questions?
>>>
>>> Anyone with an "mozilla.org" e-mail address, that's who I would expect.
>>
>> That's just not true. For example:
>>
>> " Are libimg’s maintainers and Mozilla.org’s drivers satisfied with
>> the process followed, in regards to both the removal itself as
>> well as communication before and after the fact? "
>>
>> I am neither a driver nor a libimg maintainer, so I certainly can't
>> answer that question.
>
> You can "address" it.

To his credit, Gerv frequently does at least attempt to address things -
doesn't necessarily help if he can't get things to happen either. You get
to go "great, someone at mozilla.org is addressing the issue", and then
you discover that 4 weeks later they still haven't had a response from the
person they're trying to talk to because the person they're talking to
doesn't think it's any of their business.

[snip]


>> It's fairly clear. tor and pav are responsible for libimg. libmng is (or
>> would be) part of libimg. Therefore you need to consult them about the
>> situation. Be prepared for a testy reply, as they have made their views
>> very clear in several bugs.
>
> It seems perhaps tor and pav shouldn't have that role/power. Has that
> been considered? Are there others who would be better qualified?

I don't think it would take long to consider - I guess you may consider
that part of the problem - but there are already too few people willing to
take on those roles. You'd not only need to find someone better qualified
(and I don't think anyone is doubting their technical qualifications) but
someone better qualified and willing to take on the role (including having
a bunch of people shouting at you all the time via email and bugzilla),
for not much return (certainly no money). If anyone knows someone better
qualified who wants to be a module owner, I think there are modules with
owners that aren't doing anything at all, which is a worse situation...

--
Michael

Michael Lefevre

unread,
Nov 7, 2003, 10:01:28 AM11/7/03
to
On 2003-11-07, Gervase Markham <ge...@mozilla.org> wrote:
> Michael Lefevre wrote:
>
>> They're not, AFAIK. The staff page doesn't even include all the staff,
>> AFAICS.
>
> It does. It doesn't include all the people on the st...@mozilla.org
> email alias, but it does include all the staff.

I guess it depends who is considered staff and who isn't, but knowing that
much is a help. So what kind of people are on the staff@ alias that
aren't staff?

and I've read elsewhere that ben, mscott and choffman were hired by the
foundation - what's their status if they're not staff? Also might be
interesting to know which staff are paid and/or full-time and which
aren't.

--
Michael

Boris Zbarsky

unread,
Nov 7, 2003, 11:14:06 AM11/7/03
to
Michael Lefevre wrote:
> For a response, maybe 3 or 4 days. If that response is "we're aware
> there's an issue here, we'll think about it and post something within the
> next 3 weeks", or "the person that needs to deal with this is busy with
> something else and won't be back until X date" that's fine. The issue is
> when there's just no response at all for weeks.

Yeah, fair enough... This is actually pretty similar to "patch review
limbo" where people don't even get around to commenting that they won't
have time to review the patch (something I think everyone has been
guilty of now and then).

Part of the problem is the sheer volume of bugmail and stuff to do --
you decide something is not critical "right now", refile the mail to
your "to do" list, and three weeks later discover that it's become
critical all of a sudden. :(

> You can't manage conflicts by keeping quiet and hoping they will go
> away.

Agreed.

-Boris

Brendan Eich

unread,
Nov 7, 2003, 10:27:20 PM11/7/03
to newsre...@michaellefevre.com
Michael Lefevre wrote:

>Given the amount of argument
>that was happening in public, there should have been a response from
>drivers somewhere public before that.
>
>

Yes, drivers screwed up there. We were not all aware of the impending
CVS removal, and we were expecting not to have to intervene. Or maybe
we were just dreading having to intervene. There's some truth to the
idea that some drivers were hoping that the people responsible for the
pieces of code would actually come to an understanding without drivers
using their authority. That would be nice, but it wasn't in the cards.

/be


Brendan Eich

unread,
Nov 7, 2003, 10:38:21 PM11/7/03
to newsre...@michaellefevre.com
Michael Lefevre wrote:

>and I've read elsewhere that ben, mscott and choffman were hired by the
>foundation - what's their status if they're not staff?
>

They're all on staff (chofmann, not choffman, FYI -- frequently
misspelled, maybe we should have an email alias for both ;-).

> Also might be
>interesting to know which staff are paid and/or full-time and which
>aren't.
>
>

The paid staff are:

part time: mitchell;
full time: asa, ben, brendan, chofmann, dbaron, leaf, mscott, myk, and
after next Wednesday, jst.

You may know that blizzard is paid by Red Hat to work on Mozilla at
least part-time, and he's staff too, so he's "paid", but not by the
Mozilla Foundation.

/be

Neil Marshall

unread,
Nov 7, 2003, 10:56:17 PM11/7/03
to
Brendan Eich wrote:

> The paid staff are:
>
> part time: mitchell;
> full time: asa, ben, brendan, chofmann, dbaron, leaf, mscott, myk, and
> after next Wednesday, jst.
>

Is gervase?
I always though he was cause he has a mozilla.org email...

Brendan Eich

unread,
Nov 8, 2003, 1:09:02 AM11/8/03
to Neil Marshall
Neil Marshall wrote:


Gerv is not paid staff, which was what I enumerated, but he is on
staff. Obviously (I hope, from this thread) there are unpaid staff as
well as paid staff. See
http://www.mozilla.org/about/stafflist.html#Staff-Members.

/be

L. David Baron

unread,
Nov 6, 2003, 6:02:29 PM11/6/03
to
On Thursday 2003-11-06 16:40 -0600, Boris Zbarsky wrote:
> Michael Lefevre wrote:
> >It may be better than it was, but I would hesitate to say that any page
> >that says that most Module Owners work for Netscape is "reasonably
> >up-to-date". :)
>
> You read the text? ;) Most people just want to look at the module of
> interest...

It's worth noting that the text was rewritten in October 2001, but the
autogeneration of the page wasn't fixed, so the next auto-update of the
page overwrote the new text.

-David

--
L. David Baron <URL: http://dbaron.org/ >

Greg K.

unread,
Nov 8, 2003, 9:34:40 AM11/8/03
to
Brendan Eich wrote:

> Hi Greg, sorry I missed your posting; I've fallen way behind on
> m.seamonkey, and I bet most other dri...@mozilla.org have too. I
> suggest you mail drivers directly in the future when calling for
> accountability.

Brendan, thanks very much for responding. And thanks to everyone else
who responded as well. I appreciated reading your thoughts on my questions.

I hope to have an opportunity to write a follow-up message later this
weekend.


--
Greg K.
greg hyphen usenet at greg dot tcp dot see oh em

Michael Lefevre

unread,
Nov 8, 2003, 9:54:53 AM11/8/03
to
On 2003-11-08, Brendan Eich <bre...@meer.net> wrote:
> Michael Lefevre wrote:
>
>>and I've read elsewhere that ben, mscott and choffman were hired by the
>>foundation - what's their status if they're not staff?
>
> They're all on staff (chofmann, not choffman, FYI -- frequently
> misspelled, maybe we should have an email alias for both ;-).

Thanks for clarifying that. So (repeating what I said back up the thread),
the staff page doesn't include all the staff and does need updating :)

>> Also might be
>>interesting to know which staff are paid and/or full-time and which
>>aren't.
>
> The paid staff are:
>
> part time: mitchell;
> full time: asa, ben, brendan, chofmann, dbaron, leaf, mscott, myk, and
> after next Wednesday, jst.

Thanks for that information. I didn't know about jst - that is good news
as well :)

by deduction, that would mean gerv, scc, endico, hyatt, sspitzer and
blizzard are staff, but not paid by the foundation (although blizzard is
paid as you noted). and then there's the staff associate members, who I
assume are also not paid - I'm not quite clear of the distinction between
staff and staff associates, but anyway...

--
Michael

Gervase Markham

unread,
Nov 10, 2003, 5:05:13 AM11/10/03
to
Michael Lefevre wrote:

> To his credit, Gerv frequently does at least attempt to address things -
> doesn't necessarily help if he can't get things to happen either. You get
> to go "great, someone at mozilla.org is addressing the issue", and then
> you discover that 4 weeks later they still haven't had a response from the
> person they're trying to talk to because the person they're talking to
> doesn't think it's any of their business.

What a wonderfully succinct summary :-)

Gerv

Peter Lairo

unread,
Nov 10, 2003, 6:20:02 AM11/10/03
to
Michael Lefevre on 07.11.03 15:53 wrote:
> On 2003-11-07, Peter Lairo <Pe...@Lairo.com> wrote:
>
>>Gervase Markham said on 07.11.03 13:48:
>>
>>>Peter Lairo wrote:
>>>
>>>
>>>>Gervase Markham on 06.11.03 11:19 wrote:
>>>>
>>>>
>>>>>Who from the Foundation would you expect to know the answers to
>>>>>Greg's questions?
>>>>
>>>>Anyone with an "mozilla.org" e-mail address, that's who I would expect.
>>>
>>>That's just not true. For example:
>>>
>>>" Are libimg’s maintainers and Mozilla.org’s drivers satisfied with
>>> the process followed, in regards to both the removal itself as
>>> well as communication before and after the fact? "
>>>
>>>I am neither a driver nor a libimg maintainer, so I certainly can't
>>>answer that question.
>>
>>You can "address" it.
>
>
> To his credit, Gerv frequently does at least attempt to address things -
> doesn't necessarily help if he can't get things to happen either. You get
> to go "great, someone at mozilla.org is addressing the issue", and then
> you discover that 4 weeks later they still haven't had a response from the
> person they're trying to talk to because the person they're talking to
> doesn't think it's any of their business.

That's just needlessly evasive and cynical. By "address the issue" i
obviously meant *properly* address the issue. This includes researching
the problem and potentially making a difficult decision. It also means
reporting back to the community what decision/conclusion has been made
and why it was done that way.

Staff needs to address issues like this, even in the result is something
like: "the person qualified/responsible to address this (e.g. module
owner) is not interested and we have no better replacement for him".

OK, (hopefully) everyone already realizes that this issue was addressed
poorly. I just don't think flippant responses are a good idea here (salt
on wound).

--
Peter Lairo

us...@domain.invalid

unread,
Nov 10, 2003, 12:54:35 PM11/10/03
to
Glenn Randers-Pehrson wrote:
> Robert O'Callahan <rob...@ocallahan.org> wrote in message news:<bodu5j$hq...@ripley.netscape.com>...
>
>>Let me add something to what bz said here. We've reduced the size (and
>>improved the performance) of gklayout.so/dll significantly, not by
>>cutting functionality but with time consuming and tedious simplification
>>of the code. For example, search bonsai for the checkins associated with
>>bug 190375. On the other hand, efforts to reduce the size of the MNG
>>code have focused on adding #ifdefs to change the set of features, but
>>there has been little or no effort to simplify the code itself. In fact,
>>Glenn is actively against doing that: see
>>http://bugzilla.mozilla.org/show_bug.cgi?id=204520#c38
...

>>It's OK for Glenn to have that philosophy, but we don't share it.
>
>
> That's not my philosophy. It's just what I found when I started looking
> carefully at libmng.

Here's the full comment again, that you wrote:

> The main reason that it is a lot larger than libpng is that libmng is writtin in
> a 21st century coding style that doesn't worry much about 10s of kilobytes of

> code size. If there are 10 slightly different things to do, it uses 10 slightly
> different functions to do them, while the older libpng would use multpurpose
> functions with internal switches. The libmng style is faster and easier to
> read. Who would have thought saving a few 10k would be critical in an
> application with 25megs of shared libraries? (or 16megs in the case of Firebird?)

It sure sounds like you were fully supportive of the "21st century
coding style". If you're not, that's interesting.

Rob

Brendan Eich

unread,
Nov 10, 2003, 2:37:33 PM11/10/03
to Peter Lairo
Peter Lairo wrote:

> That's just needlessly evasive and cynical. By "address the issue" i
> obviously meant *properly* address the issue. This includes
> researching the problem and potentially making a difficult decision.
> It also means reporting back to the community what decision/conclusion
> has been made and why it was done that way.


Drivers failed to do that, as noted with regret by me, at least. Sorry,
we'll do better next time.

> Staff needs to address issues like this, even in the result is
> something like: "the person qualified/responsible to address this
> (e.g. module owner) is not interested and we have no better
> replacement for him".


What kind of slanted example is that? You may not like the reasoning
behind the decision we did in fact finally reach, but the reasoning had
nothing to do with lack of interest on the part of module owners, or
lack of replacement owners. Drivers are not interested in replacing
libimg owners, especially not to satisfy your interest in bundling MNG
as-is in the default builds.

You ought to separate what you want from what is the right process for
the community to arrive at a particular solution, whether it is the
solution you want.

Staff is not going to override drivers on an issue like this, BTW.

/be

Peter Lairo

unread,
Nov 10, 2003, 3:21:54 PM11/10/03
to
Brendan Eich said on 10.11.03 20:37:

> Peter Lairo wrote:
>
>> That's just needlessly evasive and cynical. By "address the issue" i
>> obviously meant *properly* address the issue. This includes
>> researching the problem and potentially making a difficult decision.
>> It also means reporting back to the community what decision/conclusion
>> has been made and why it was done that way.
>
>
>
> Drivers failed to do that, as noted with regret by me, at least. Sorry,
> we'll do better next time.
>
>> Staff needs to address issues like this, even in the result is
>> something like: "the person qualified/responsible to address this
>> (e.g. module owner) is not interested and we have no better
>> replacement for him".
>
>
>
> What kind of slanted example is that?

I agree that it could be considered *very* slanted. ;)

> You may not like the reasoning
> behind the decision we did in fact finally reach, but the reasoning had
> nothing to do with lack of interest on the part of module owners, or
> lack of replacement owners. Drivers are not interested in replacing
> libimg owners, especially not to satisfy your interest in bundling MNG
> as-is in the default builds.

I'm very glad to hear that drivers would not replace an owner based on
one persons' "interest". ;)

> You ought to separate what you want from what is the right process for
> the community to arrive at a particular solution, whether it is the
> solution you want.

I don't *know* what is the right process for the community as i don't
know all the factors involved. All i can present are my interpretations
based on limited facts. I agree that my conclusions may be flawed. But I
hope that feedback such as mine can provide you guys (and gals) with
*some* insight into what the community is _perhaps_ thinking and where
structural improvements may be benefitial.

> Staff is not going to override drivers on an issue like this, BTW.

Drivers <> (subset of) staff? OK, I'm confused. But it's not so
important to my initial point that someone (official) shoud address
these kinds of issues in the future.

OK, enough rambling.

PS. Next battle: GRE...

--
Regards,

Peter Lairo

Peter Lairo

unread,
Nov 10, 2003, 3:28:37 PM11/10/03
to
us...@domain.invalid said on 10.11.03 18:54:

That sounds like an unfair conclusion to a seemingly well reasoned case.
Also, "faster and easier to read" seem a reasonable trade-off for a few
10k's - hardly a "critical" issue.

PS. Are you aware of http://www.mozilla.org/community-etiquette.html
("No anonymous messages") (damn, that page needs more "anchors")

--
Regards,

Peter Lairo

Brendan Eich

unread,
Nov 10, 2003, 4:42:54 PM11/10/03
to Peter Lairo
Peter Lairo wrote:

> That sounds like an unfair conclusion to a seemingly well reasoned
> case. Also, "faster and easier to read" seem a reasonable trade-off
> for a few 10k's - hardly a "critical" issue.


I'm sorry, no: a few 10k's of code space is not required for readability
or even time performance, in my considered engineering judgment.

Also, the issue here was not 10k's, but 100k's. I respectfully suggest
that you acquaint yourself with the technical issues better before
making such statements.

/be

Christian Biesinger

unread,
Nov 10, 2003, 6:26:27 PM11/10/03
to
Peter Lairo wrote:
> Drivers <> (subset of) staff?

correct, although a few drivers are also staff members, check the
webpage if you want to know which ones.

Peter Lairo

unread,
Nov 11, 2003, 4:22:20 AM11/11/03
to
Brendan Eich said on 10.11.03 22:42:

Well, I *did* use terms like "seems like", "seemingly" and "seem"
precisely because the statements _could_ be incorrect.

If you say they are in fact incorrect, then I'll have to trust your
"considered engineering judgment." ;)

BTW: I was objecting to the seemingly unfair conclusion of "fully
supportive of the "21st century coding style"" without the poster even
*addressing* the statement "faster and easier to read".

For clarification: I thought the *total* MNG file was 100k's. Are you
saying that 100k's are a result of "21st century coding style" (e.g., a
500k file should be reduced to 200k)?

It seems like a rational discussion between staff and Greg K. could
resolve this fairly quickly. If this precise issue is the "deciding
issue", then mabe it can be resolved. :-\

If Greg is more interested in getting MNG back than pressing the issue
of not saving even small amounts of file size, then mabe there is hope
for *all* of us. Greg yields a bit on the coding style, and staff yields
a bit on the MNG-as-it-is-in-mozilla issue. ;)

--
Regards,

Peter Lairo

Glenn Randers-Pehrson

unread,
Nov 11, 2003, 8:06:53 AM11/11/03
to
Peter Lairo <Pe...@Lairo.com> wrote in message news:<boorm6$bk...@ripley.netscape.com>...

Maybe I was fully supportive of the style. Maybe I was being a bit
sarcastic. I don't remember which. But it's interesting that I
spent a large part of the summer rewriting parts of it in my own more
compact style.

> That sounds like an unfair conclusion to a seemingly well reasoned case.
> Also, "faster and easier to read" seem a reasonable trade-off for a few
> 10k's - hardly a "critical" issue.

Indeed it was about 100k or so in libmng-1.0.5; still maybe 10k or so
in libmng-1.0.6 but the returns for recoding are diminishing.

Robert O'Callahan

unread,
Nov 11, 2003, 10:51:42 AM11/11/03
to
Peter Lairo wrote:
> PS. Are you aware of http://www.mozilla.org/community-etiquette.html
> ("No anonymous messages") (damn, that page needs more "anchors")

Sorry, it was a mistake.

Rob

Greg K.

unread,
Nov 12, 2003, 4:30:17 AM11/12/03
to
Peter Lairo wrote:
> It seems like a rational discussion between staff and Greg K. could
> resolve this fairly quickly. If this precise issue is the "deciding
> issue", then mabe it can be resolved. :-\
>
> If Greg is more interested in getting MNG back than pressing the issue
> of not saving even small amounts of file size, then mabe there is hope
> for *all* of us. Greg yields a bit on the coding style, and staff yields
> a bit on the MNG-as-it-is-in-mozilla issue. ;)

I think you meant to say between staff and Glenn. I should point out
that my contribution to Mozilla has never gone beyond bug triage and QA.

Greg K.

unread,
Nov 12, 2003, 7:40:43 AM11/12/03
to
Brendan, thanks very much for responding. I appreciate the value (and scarcity) of your time.

Brendan Eich wrote:
Greg K. wrote:
I am considering returning to Mozilla QA. For those who want to know, I left the project after libmng’s removal both because I objected to the removal and, more importantly, because good questions about the action were at best insufficiently responded to, and at worst simply ignored. I had — and have — no recourse, so I left.

Though answers have eventually been obtained to some questions related to libmng’s removal, what is still not clear to me is the rationale behind the action and whether or not the rationale has been satisfied.
Hi Greg, sorry I missed your posting; I've fallen way behind on m.seamonkey, and I bet most other dri...@mozilla.org have too.  I suggest you mail drivers directly in the future when calling for accountability.
Will do.
Let me briefly summarize what I understand.

   1. libmng’s Mozilla maintainer and original integrator, tor,
      relinquished that role. Thus the integration was left without a
      maintainer (tor, bug 195280, comment 0).
That's the main problem.
It’s also my understanding that one possible maintainer, GRP, was “found unacceptable.” Are any reasons for this known beyond GRP’s known dislike of the term libpr0n?
   1. Though libmng’s disk footprint is not surprising given its’
      functionality (tor, bug 195280 comment 6), libmng’s developer
      nevertheless offered to reduce this footprint as much as
      possible (Juyn, bug 195280, comment 24) and, indeed, it has been
      significantly reduced (Randers-Pehrson, bug 18574, comment 266).
It still duplicates PNG, without having the miles of testing that libpng has had.  We could probably switch PNG implementations over the course of a major milestone, so this isn't a showstopper, but we shouldn't have two PNG implementations in the default builds for long.
Might this be tentatively considered for the 1.7 cycle?

I’m beginning to get an idea of some possible courses of action for the future in Seamonkey.

Course 1 involves formulating a viable subset of MNG for Mozilla’s purposes (and, as well, broader web-specific purposes) and embedding it via libmng along with libpng. This could eventually be superseded by course 2.

Course 2 involves switching out libpng for libmng during a complete .x development cycle. As many unused MNG features as possible are removed and as much easy optimization would be done as feasible in such a time. A test regimen would be developed to ensure libmng’s capability to handle PNG as reliably and efficiently as libpng. Should libmng fail this regimen, the change would be disallowed for the final .x release. The MNG community would be expected to perform as much of this testing as possible.
   1. There is a gulf between the value placed on MNG+JNG’s feature
      set by a large part of the community (602 votes for bug 18574 as
      of this writing) and by key libmng developers (Parmenter, bug
      195280 comment 69).
I keep saying this in bug after bug, at the risk of sounding "anti-XForms" or (here) "anti-MNG".  Votes don't fix bugs or own code.  Drivers can't include something that's unowned.  Drivers have said we'd be willing to take a reduced-footprint MNG subset, provided there's an owner.  Speaking for myself, I would host the whole MNG source, as an optional extension, if its glue with libpr0n were actually maintained by an owner.
I’m under no illusion that votes represent anything more than opinion. With that in mind, though, 600+ votes does suggest to me that the format is valued in and of itself, in its’ present state. (Naturally, I also realize MNG+JNG isn’t the only area with differences in value placed by core Moz developers and the larger community. It just seems like a particularly marked one.)
Certain other things remain unclear, however.

   1. Was there a requirement to reduce imglib’s disk footprint? What
      were the details of the requirement? Were savings achieved in
      any other area than libmng? What has been the result of the
      requirement?
The reasons of the module (Image Handling: MNG) owner (t...@acm.org) for MNG removal are given in http://bugzilla.mozilla.org/show_bug.cgi?id=195280#c0.
True, but each of those points has been or is being addressed by libmng’s owners (other than the subjective ones and the main problem of a lack of owner).
I know of no requirements from drivers for imglib disk footprint reduction.

In general, disk footprint matters because (based on Mozilla and Netscape experience) 10 minutes is around the knee in the curve where download failures take off, and every 30 seconds shaved off around there helps (Firebird is slightly above 10 minutes on narrowband).  I'm parroting others who have the experience reported here, but the 10 minutes knee makes some intuitive sense given how long phone calls last, the likelihood that a kid or roommate picks up the phone, etc.
That makes sense. Would it be useful to mention that somewhere in w.m.o’s Footprint pages.
MNG is not particularly bad in terms of disk footprint; nothing is.  The problem (as with code footprint) is that every little bit helps, and we can't include everything in the default build.
   1. Have imglib or Gecko gained or retained any embeddors as a
      result of the removal?
Since we can't rewind reality and run the other experiment, who knows?  C'mon, there's no way to say.
The reason I ask is that as a relative outsider I normally wouldn’t hear about such things, and it’s the only way to find out. Often I was able to have a sense of what was going on around Moz just by reading dozens of bugs every day, but not always. In the case of MNG, for all I knew some specific embeddors could have complained about it, and decided to stick with Gecko as a result of the removal. Often we outsiders only hear that “a major embeddor” requires something. We don’t know who it is, and we don’t really know what they want.
But footprint matters.  Gecko can't be all things to all people, and it wasn't the last cookie it ate that made it big.  MNG is simply not used on the web, so justifying iincluding it in the default builds based on what people actually browse is difficult, even counting those 600+ bug voters.

If we had an animated-PNG-only subset of MNG, I think drivers would want it, at a reasonable footprint increment over PNG, to avoid animated GIFs in skins.  But again, no one has offered to develop and own such a subset.
I suspect MNG’s developers are mainly trying to avoid revamping their format capriciously. After all, they no doubt invented it to satisfy certain needs. Imagine if Microsoft had gone to PNG’s developers a few years ago and said, ‘we won’t implement anything beyond a basic GIF replacement.’ Would that have meant dumping some or all of 24-bit-color, alpha translucency or gamma correction?
   1. Was there an initiative to reduce Mozilla’s footprint overall?
      If so, what other areas were targeted for reduction, and what
      other reduction has been achieved?
Boris answered this with data.
Yes. Thanks very much again to Boris for restoring the old data.
   1. How was the target size of 50 KB (Parmenter, Bug 204520, comment
      65) computed?
SWAG.
I must admit that makes it sound less credible than in Parmenter’s comment.
   1. If that number is unachievable (Randers-Pehrson, Bug 204520,
      comment 65) without crippling MNG+JNG, is it nonnegotiable?
Only if subsetting MNG is non-negotiable.
I think it would be helpful to see some brief documentation from m.o describing the aspects of MNG that are not wanted, and what specific subset of MNG is wanted.
   1. Could achievement of this target result in restoration to
      Seamonkey and Firebird without removing libpng?
Probably.
Would Hyatt be the one to ask about Firebird? (He’s listed on <http://www.mozilla.org/owners.html>.) How about Seamonkey?
   1. Have Camino and other embeddors not presently including MNG+JNG
      been consulted about what their requirements for inclusion would be?
No.
I will contact Pinkerton and ask him. This isn’t really drivers’ responsibility.
   1. Are libimg’s maintainers and Mozilla.org’s drivers satisfied
      with the process followed, in regards to both the removal itself
      as well as communication before and after the fact? Will the
      same process be followed in the future in similar circumstances?
I doubt anyone is satisfied with everything that happened.  Although the imglib owners gave lots of warning, the cvs removal was not right, in my opinion.  The resistance to subsetting, and the insistence on "21st century coding style" on the part of MNG's owners wasn't good, either.  There's plenty to improve on here, all around.
Could the CVS removal be reversed at this point? That might make Glenn’s continuing work easier, as well as that of those building MNG-enabled builds.

I don’t think anyone will argue that either code readability or code efficiency/compactness are undesirable. In the former instance, the hope is that compilers will compensate by optimizing code at compile time, and in the latter case programmers can compensate by thoroughly documenting code (particularly in arcane passages) with natural-language explanation. Of course, in neither case does the compensation happen nearly enough. This is getting a bit off-topic, though.

Thanks again, Brendan.

Michael Lefevre

unread,
Nov 12, 2003, 8:42:23 AM11/12/03
to
On 2003-11-07, Brendan Eich <bre...@meer.net> wrote:
[snip]

> In general, disk footprint matters because (based on Mozilla and
> Netscape experience) 10 minutes is around the knee in the curve where
> download failures take off, and every 30 seconds shaved off around there
> helps (Firebird is slightly above 10 minutes on narrowband). I'm
> parroting others who have the experience reported here, but the 10
> minutes knee makes some intuitive sense given how long phone calls last,
> the likelihood that a kid or roommate picks up the phone, etc.
[snip]

The trouble with that argument (not that I'm disputing the truth of it),
is that the same thing probably applies to other bits of the code, and the
module owners for those bits aren't acting the same way. If it's a goal to
get rid of unmaintained and/or unnecessarily repetitive code, then why
isn't it being done as a priority in all the modules? If it's not a
universal goal, then why is imglib doing it?

If it's a question of download size, then, although there are ongoing
improvements, download size is clearly not any more at the top of the list
of priorities for the Firebird developers.

For example, Firebird is distributed currently as zip and gzip, and the
files are about 6.0MB (Windows) and 9.1MB (Linux). Using 7zip and bzip2
the sizes drop to about 5.2MB and 8.5MB. It looks inconsistent to make a
big fuss about 10s of KB of MNG code, whilst not giving similar importance
to compression methods (at least on Windows, switching to a less
widely-used compression format without an installer wouldn't be a good
idea, but...).

With decisions for different modules made by different module owners with
their own priorities, you're going to end up with some inconsistancy. I
guess that inconsistancy is easy to perceive as "Mozilla" being unfair
when problems arise. Not that I have any bright ideas on how to solve
that without drivers having to manage everything pro-actively, which I
don't imagine would be workable...

--
Michael

Boris Zbarsky

unread,
Nov 12, 2003, 12:26:39 PM11/12/03
to
Greg K. wrote:
> Yes. Thanks very much again to Boris for restoring the old data.

Bryner did the restoring and deserves the thanks. I just badgered. ;)

> Could the CVS removal be reversed at this point?

The files should be in Attic, as usual....

-Boris

Robert O'Callahan

unread,
Nov 12, 2003, 2:29:33 PM11/12/03
to
Michael Lefevre wrote:
> On 2003-11-07, Brendan Eich <bre...@meer.net> wrote:
> [snip]
>
>>In general, disk footprint matters because (based on Mozilla and
>>Netscape experience) 10 minutes is around the knee in the curve where
>>download failures take off, and every 30 seconds shaved off around there
>>helps (Firebird is slightly above 10 minutes on narrowband). I'm
>>parroting others who have the experience reported here, but the 10
>>minutes knee makes some intuitive sense given how long phone calls last,
>>the likelihood that a kid or roommate picks up the phone, etc.
>
> [snip]
>
> The trouble with that argument (not that I'm disputing the truth of it),
> is that the same thing probably applies to other bits of the code, and the
> module owners for those bits aren't acting the same way. If it's a goal to
> get rid of unmaintained and/or unnecessarily repetitive code, then why
> isn't it being done as a priority in all the modules? If it's not a
> universal goal, then why is imglib doing it?

We've made footprint improvements in many modules. Search bonsai for the
massive "deCOMtamination" patches to see just part of all the work that
has been done. Sorry, but the meme that imglib has been singled out for
special treatment aggravates me because it discounts a whole lot of work
that people (including me) have done.

Also, even if for example no-one was trying to reduce the footprint of
layout, we couldn't punish them by dropping layout. On the other hand
MNG is an optional feature and that's the harsh reality.

Also, the MNG code is admitted by its advocates to be bloated "21st
century coding style" which isn't necessarily true of all modules.

Rob

Brendan Eich

unread,
Nov 12, 2003, 5:27:39 PM11/12/03
to Peter Lairo
Peter Lairo wrote:

> For clarification: I thought the *total* MNG file was 100k's. Are you
> saying that 100k's are a result of "21st century coding style" (e.g.,
> a 500k file should be reduced to 200k)?


Sorry, I didn't mean to say that. What I meant to say was that big,
multiple-profile standards, plus "21st century coding style" (which may
have been a half-joke), add up to a big library -- but only a few
profiles tend to be used widely, or at all, in practice. More
concretely, drivers were interested in only one profile, although I'm
still not sure it exists. It would have been the "animated PNG" format
that people want to use instead of animated GIFs.

/be

Brendan Eich

unread,
Nov 12, 2003, 5:37:52 PM11/12/03
to newsre...@michaellefevre.com
Michael Lefevre wrote:

>The trouble with that argument (not that I'm disputing the truth of it),
>is that the same thing probably applies to other bits of the code,
>

You did read my post at
news://news.mozilla.org:119/3FAAF60C...@meer.net, especially "Gecko

can't be all things to all people, and it wasn't the last cookie it ate

that made it big"?

> and the
>module owners for those bits aren't acting the same way.
>

False, where it matters (where there are active owners, and significant
footprint reductions to make). Almost all of our top owners have made
significant code footprint reductions in the last year. Did you read
bz's post at
news://news.mozilla.org:119/boe7sd$ih...@ripley.netscape.com, and follow
the links there?

/be

Brendan Eich

unread,
Nov 12, 2003, 6:15:17 PM11/12/03
to Greg K.
Greg K. wrote:

>>> Let me briefly summarize what I understand.
>>>
>>> 1. libmng’s Mozilla maintainer and original integrator, tor,
>>> relinquished that role. Thus the integration was left without a
>>> maintainer (tor, bug 195280, comment 0).
>>
>> That's the main problem.
>
> It’s also my understanding that one possible maintainer, GRP, was
> “found unacceptable

> <http://bugzilla.mozilla.org/show_bug.cgi?id=18574#c270>.” Are any
> reasons for this known beyond GRP’s known dislike of the term /libpr0n/?


My understanding of what happened was that Glenn refused to work on
libpr0n code because of that name. That disqualified him from owning
the MNG glue code that must go in libpr0n. If I'm misinformed, someone
will correct me (gently, I'm sure ;-). I agree we should rename libpr0n
(along with other misnamed and mislocated directories), but it can't be
a showstopper to owning a pre-existing piece of glue for one image
format family.

The module owners may have other reasons that I don't know about, or
can't represent well. They can speak up if necessary, but the libpr0n
issue was primary, as I understand it.

>> It still duplicates PNG, without having the miles of testing that
>> libpng has had. We could probably switch PNG implementations over
>> the course of a major milestone, so this isn't a showstopper, but we
>> shouldn't have two PNG implementations in the default builds for long.
>
> Might this be tentatively considered for the 1.7 cycle?


Might what be considered? Dropping the PNG implementation we've been
shipping for a long time in favor of the one in the MNG code that we no
longer host, build, or ship? Why would we switch PNG implementations
now, or at any point, without some strong motivation?

> I’m beginning to get an idea of some possible courses of action for
> the future in Seamonkey.
>
> Course 1 involves formulating a viable subset of MNG for Mozilla’s
> purposes (and, as well, broader web-specific purposes) and embedding
> it via libmng along with libpng. This could eventually be superseded
> by course 2.
>
> Course 2 involves switching out libpng for libmng during a complete .x
> development cycle. As many unused MNG features as possible are removed
> and as much easy optimization would be done as feasible in such a
> time. A test regimen would be developed to ensure libmng’s capability
> to handle PNG as reliably and efficiently as libpng. Should libmng
> fail this regimen, the change would be disallowed for the final .x
> release. The MNG community would be expected to perform as much of
> this testing as possible.


The problem is we have no owner for the libpr0n<=>MNG glue code, still.
Plus, we generally do not take footprint hits and then hope for
optimization and code removal later -- we did that in the old days with
a lot of the original Gecko code, and it has taken years to reduce code
footprint, often with bloody fights along the way, and the (necessary)
demise of the original code owners.

It's unwise to add code knowing we don't want most of it, then hope to
untangle and remove the pieces we don't want well enough to keep what is
good.

> I’m under no illusion that votes represent anything more than opinion.
> With that in mind, though, 600+ votes does suggest to me that the

> format is valued in and of itself, /in its’ present state/.

> (Naturally, I also realize MNG+JNG isn’t the only area with
> differences in value placed by core Moz developers and the larger
> community. It just seems like a particularly marked one.)


http://mozdev.org and many other places host add-ons. If we get enough
build machines, even mozilla.org could host a "complete" GRE-based
build, some day. It might even include MNG, if we can get someone to
own the imglib glue.

> True, but each of those points has been or is being addressed by
> libmng’s owners (other than the subjective ones and the main problem
> of a lack of owner).


Is the fact that MNG was as big as all the other image decoders
subjective? The argument for or against taking such a big library may
involve subjective values, but the bare footprint facts speak for
themselves. Even with good reduction work that was done, the MNG code
was still big, in relation to other libraries in mozilla.

Mozilla integration being rough was mostly about the lack of active
owners for the glue. Was that a subjective evaluation? I don't think so.

Is the lack of use of MNG on the web a subjective point?

> Would it be useful to mention that somewhere in w.m.o’s Footprint

> <http://www.mozilla.org/projects/footprint/> pages.


Yes. Good idea -- I'll try to get someone on that.

>>> 1. Have imglib or Gecko gained or retained any embeddors as a
>>> result of the removal?
>>
>> Since we can't rewind reality and run the other experiment, who
>> knows? C'mon, there's no way to say.
>
> The reason I ask is that as a relative outsider I normally wouldn’t
> hear about such things, and it’s the only way to find out. Often I was
> able to have a sense of what was going on around Moz just by reading
> dozens of bugs every day, but not always. In the case of MNG, for all
> I knew some specific embeddors could have complained about it, and
> decided to stick with Gecko as a result of the removal. Often we
> outsiders only hear that “a major embeddor” requires something. We
> don’t know who it is, and we don’t really know what they want.


AOL is on longer directly a major embedder, but when they were, they
cared quite a bit about footprint. They had to: MSHTML.SO is pretty
small in comparison to Gecko. Now, they could of course have chosen to
customize their build of Gecko to leave out many things, MNG included.
Embedders generally can cope with deconfiguring things. So besides it
being hard to say how much MNG's overhead mattered to embedders, I would
say that at the limit, it shouldn't have mattered.

Mozilla's footprint, including download/disk, does matter -- especially
without a major embedder helping us win distribution.

>> If we had an animated-PNG-only subset of MNG, I think drivers would
>> want it, at a reasonable footprint increment over PNG, to avoid
>> animated GIFs in skins. But again, no one has offered to develop and
>> own such a subset.
>
> I suspect MNG’s developers are mainly trying to avoid revamping their
> format capriciously. After all, they no doubt invented it to satisfy
> certain needs. Imagine if Microsoft had gone to PNG’s developers a few
> years ago and said, ‘we won’t implement anything beyond a basic GIF
> replacement.’ Would that have meant dumping some or all of
> 24-bit-color, alpha translucency or gamma correction?


Maybe, maybe not. Probably not alpha and gamma. Color representation
might have gone in a different direction (I'm told 16 bit integer color
channels has lost to floating point).

But this is all beside the point, because while MNG's developers can
suit themselves in any scenario (and take the consequences, including
not being included in any number of larger programs), drivers have to do
what's right for Mozilla, not for MNG.

>>> 1. If that number is unachievable (Randers-Pehrson, Bug 204520,
>>> comment 65) without crippling MNG+JNG, is it nonnegotiable?
>>
>> Only if subsetting MNG is non-negotiable.
>
> I think it would be helpful to see some brief documentation from m.o
> describing the aspects of MNG that are not wanted, and what specific
> subset of MNG is wanted.


What would that have helped? The MNG owners heard what drivers wanted
(an animated PNG format), when drivers finally got off our duffs and
intervened. There wasn't a lack of clarity there, just a difference in
technical and footprint values.

>>> 1. Could achievement of this target result in restoration to
>>> Seamonkey and Firebird without removing libpng?
>>
>> Probably.
>
> Would Hyatt be the one to ask about Firebird? (He’s listed on
> <http://www.mozilla.org/owners.html>.)


Yes. But first, let's see a plan to agree on the target, achieve the
target, and own the glue code. At this point, hyatt would be foolish to
make any promises or write any blank checks.

> How about Seamonkey?


SeaMonkey is the default build still, so drivers ultimately decide
what's in and what is out. And drivers haven't heard of a plan to agree
on the target, achieve it, and see the glue code well-owned, so what's
the point in trying to ask someone to say "yes, we'd take an MNG subset
if it were *this* small"?

>>> 1. Have Camino and other embeddors not presently including MNG+JNG
>>> been consulted about what their requirements for inclusion
>>> would be?
>>
>> No.
>
> I will contact Pinkerton and ask him. This isn’t really drivers’
> responsibility.


Not unless someone makes a stink and the parties can't reach agreement.
That rarely happens, fortunately.

/be

Brendan Eich

unread,
Nov 12, 2003, 6:21:54 PM11/12/03
to
Brendan Eich wrote:

> AOL is on longer directly a major embedder, but when they were, they
> cared quite a bit about footprint. They had to: MSHTML.SO is pretty
> small in comparison to Gecko.


Bite my Unix tongue: MSHTML.DLL.

/be

Michael Lefevre

unread,
Nov 12, 2003, 7:34:07 PM11/12/03
to
On 2003-11-12, Brendan Eich <bre...@meer.net> wrote:
> Michael Lefevre wrote:
>
>>The trouble with that argument (not that I'm disputing the truth of it),
>>is that the same thing probably applies to other bits of the code,
>
> You did read my post at
> news://news.mozilla.org:119/3FAAF60C...@meer.net, especially "Gecko
> can't be all things to all people, and it wasn't the last cookie it ate
> that made it big"?

Yes - and I believe you. Might have altered some perceptions if someone
had written some of those things somewhere they would be noticed a while
ago actually... or maybe it wouldn't, I don't know.

>> and the
>>module owners for those bits aren't acting the same way.
>
> False, where it matters (where there are active owners, and significant
> footprint reductions to make).

It would seem to me it still matters where there aren't active owners, but
maybe not.

> Almost all of our top owners have made
> significant code footprint reductions in the last year. Did you read
> bz's post at
> news://news.mozilla.org:119/boe7sd$ih...@ripley.netscape.com, and follow
> the links there?

I'd seen the post, but the links didn't work when I tried them. I've just
looked at them now, and the core graph is quite impressive (although it
becomes a bit less impressive if you turn off the Y-axis "zoom"). I may
even point them out next time I'm trying to put the other side of this
argument.

Thanks very much for answering.

--
Michael

Boris Zbarsky

unread,
Nov 12, 2003, 7:46:24 PM11/12/03