Re: Mozilla code structure

Enrico Weigelt wrote:

> If there's no other way, join OSS-QM and make a fork ;-P

Please!  Forking something wholesale is exactly what you're advocating 
against in the first place (having a private copy of a library).  Even 
if we were doing that (which we're not), you've just lost internal 
consistency.

> Acutally, I don't care about M$ crap.

In other words you don't care whether most people can run your software. 
  That's fine; it's up to you.  We do care, which affects the decisions 
we make.

> BTW: there's cygwin.

I think shaver covered this well.

> Yeah, in GNOME world, there are enough stupid folks, too.

Yes, ok.  So everyone but you is stupid.  Where does that put us?

> Let these folks be responsible for their own crap again and don't try
> to heal the whole world ;-P

That doesn't solve the technical problem of getting the software to run 
on actual computers actual people have on their desks, though.  I note 
that you carefully avoid addressing this little niggling issue.

As far as I can tell, you want to write the code for the pleasure of 
writing the code, and if someone can use it, that's great for them.  If 
not, sucks to be them, since it's _great_ code.

We're more interested in writing code people can use.  And yes, perhaps 
healing the world.  See the Mozilla Manifesto.

> No. Every package has it's project. That project (only that project!) is
> responsible for it. If the upstream doesn't listen - fork off.

As I said, this is exactly what you decried in the first place.

>> You're making the assumption that the behavior in question is (1) a bug 
>> and (2) will be fixed.  
> 
> Of course. Evrything else is useless.

"Everything else" happens and has to be dealt with.

> If some behaviour is intended, but doesn't fit your need, you've chosen
> the wrong interface.

Yes.  So the solution is to define and implement some other interface. 
And then ignorant people I won't name come and complain that you're 
duplicating something that already exists and that you should be reusing.

>> Even if it's considered a bug there's no guarantee that it'll be 
>> fixed quickly, or at all.  
> 
> It's opensource - you can fix it by yourself.

This is false, unless you have the time to fix major architectural 
issues and worse yet the access or political weight to get upstream to 
accept them.

> Apache folks sometimes tend to be stupid, too.

Yes, yes.  Everyone except you is stupid.

>> Then you need to implement those abstractions.  
> 
> Of course, but only once and for all.

I thought you were advocating removing code that deals with platform 
issues as the issues are fixed by the platform?

> And if you do it really cleanly,
> evryone can *rely* on that interface and doesn't have to care about 
> platform specific issues - they're simply out of scope. 

This is a truism.  It doesn't say much.  OK, an interface is defined. 
Your problem seems to be not with the interfaces but with the code 
backing them up.

> Not really. It's still one big fat thing. I personally wouldn't use it 
> for my projects. I could imaging using some parts of it - if they were 
> dedicated modules.

Library granularity is an interesting question.  The limiting case is 
one library per function.  That seems undesirable to me, but perhaps you 
think it's a good idea....

>> Yes.  See NSPR.
> 
> For a short term (any only within moz), NSPR is an good approach. 
> But it doesn't go far enough. It should be split off.

Split of from what?  It's a separate project that happens to live on the 
same CVS server, in a different repository.

>>> For a *short* time, it's okay to work around other's bugs. But this has
>>> to be *strictly limited*
>> Define "short"? 
> 
> One release cycle ?

That's too short for practical purposes, since no one fixes all their 
bugs in one release cycle.

>> And then the fact that most people don't upgrade their OS the 
>> instant an upgrade is available.
> 
> Their fault - not yours.

Again, you're putting the cart before the horse.  You view people 
running your code as incidental; the important thing is the code.  We 
view people running the code as crucial.

> Everyone should do his job, not evryone else's.

I don't see why jumping on an upgrade treadmill should be the user's "job".

> Shit happens. Tell the users about the crappy systems.
> Either they learn or they run into trouble.

Yes, we already established that you don't care about the users.  That's 
up to you.  Remind me not to use any user-level software you write.

> Again: you can't heal the whole world.

That doesn't mean you shouldn't try, I should note.  I recommend reading 
up on Tikkun Olam.

>>> I don't see any reason why that new allocator should be limited to
>>> the only one client package.
>> Who ever argued that it would be?
> 
> Actually, don't know. But if I look at the mozilla codebase, 
> that's my first idea ;-P

I can't help the fact that you get wrong ideas so much.

>> For severe enough bugs (security bugs, e.g.) this might be a reasonable 
>> tradeoff.
> 
> So, the responsible people don't take my reports serious.

Your "reports"?  So far all I've seen is a statement of design 
philosophy ("make it clean, and screw the users") that is at odds with 
explicitly stated goals of the Mozilla Foundation.  Given this 
difference in fundamental assumptions, the burden is on you to prove 
that your conclusions apply in the context of the activities of the 
Mozilla Foundation.

>> When "certain people" is "100% of our userbase"... yes, maybe we feel we 
>> need to deal with the situation somehow.
> 
> Then, you take responsibility for other folk's crap. Seems you've got
> quite unlimited resources ;-P

So writing software that no one can use is a better use of resources 
than spending 20% of your time making it actually usable by people?

>>> Maybe you also feel responsible for my dirty dishes and like to 
>>> come around for cleaning the up ? ;-P
>> Perhaps not, but I see no problem with selling food that won't stick to 
>> your dishes if I know that all my customers have no running water to 
>> clean dishes with.
> 
> Maybe you've got some major misdesign in your product ? ;-P

Where did that come from?  If you're suggesting that in this example I 
should be building a water distribution system instead of selling 
dishes, I'd like to point out that my expertise likes in dish-making, 
not maintaining filtration plants, pumping stations, and a huge 
complicated pipe infrastructure.

> The code structure should be cleaned up - split the whole things 
> into several parts with *CLEAN* interfaces.

What makes you think it's not that way already?

If you have concrete suggestions that improve things without introducing 
regressions, please file bugs.

> Kicking off all the 3rd-party stuff should be the first step.

You clearly haven't read anything that's been written, have you?

-Boris