It didn't get reported because it has had no real effect on Mitchell's work for the Mozilla project. She still does all the stuff for Mozilla she used to do. So why is it news?
In the middle of November, I'm going to stop being employed by Netscape. Will that be a big story too?
The number of bugs is not a good measure of the quality of the product. That graph has been going up since we started recording numbers - does that mean Mozilla is buggier now than in 1999?
I just landed the links toolbar, which was one bug, and 20 people immediately filed bugs on it. That doesn't mean the product is "more buggy".
Mozilla chief wrangler left article which mozillaquest uncovered first!
The guy who runs MozillaZine works at Netscape one floor down from where Mitchell Baker used to work. Do you really think Mozillaquest knew about her being laid off before MozillaZine?
Mozilla would benefit from constructive criticism appropriate to a not-yet-finished application. Mangelo's criticism is never constructive, and usually misleading and factually incorrect. You may claim that a view of Mozilla based on MozillaZine is rather rosy; a view of Mozilla based only on MozillaQuest would be wildy warped.
For example, "Netscape denies Netscape 6.1 based on Mozilla code". Or how about "Mozilla is getting steadily buggier because there are more bugs in the bug database." By that measure, no code at all would be the ideal, as it would be bug-free.:-)
MozillaZine has its fair share of dissenters as well. Strauss, for one. And macpeep.
Did you read any other comments? Take everything you read at MozillaQuest with a very large pinch of salt.
XUL is an XML-based language - just like XHTML, SVG or any of the others. The sentence "A standard XML parser cannot interpret XUL." is either wrong or extremely misleading. No XML parsers can _interpret_ what they read, but an XML parser can parse XUL perfectly. Mozilla uses expat for this purpose.
That is why you cannot display XUL as a Web page with Internet Explorer 5, Netscape 4.x, or other non-Mozilla-based browsers.
"Displaying XML as a web page" makes no sense. What happens is that you apply a style sheet to some XML (whether XHTML or something else) to display it. If you gave XUL a style sheet, it would display according to that style sheet. Essentially, this is what Mozilla does when it renders its UI.
If you know the code to insert, sure:-) Or if someone else makes a patch which does that, you can easily apply it to your Mozilla installation, at the cost of a small speed penalty because you will be running with unjarred chrome. It's not really designed for this, but it could be used to do it.
The impetus for creating Patch Maker seems to lie in the fact that Mozilla bugs are raging out of control.
In fact, the impetus for creating Patch Maker was to allow more people to contribute to Mozilla. Many UI designers are not able to manage the intricacies of our build process; many people do not want to purchase Code Warrior (on Mac) or MSVC++ 6 (on Windows) and are unable, for one reason or another, to install Linux. Many people do not have the bandwidth to continually download and update the CVS tree - even downloading a nightly is a major event which must happen at cheap telephone times.
This software is for all of these people. For the first time, you can make a significant code contribution to a large open source project without the complexities of compiling.
Note: Patch Maker is still in development; I would appreciate help porting it to Mac especially, and debugging it on Windows.
Keep in mind that this doesn't "change" any Working Group activities within the W3C to mandate RAND licensing.
That's not true - see section 5.3. Any current working group can be disbanded and converted to a RAND licensing policy; when it is, all previous licenses given by the members are null and void.
Disband CSS, put it under RAND and boom! No more Mozilla/Konqueror, and Opera Software pay through the nose.
If this becomes the official Patent Policy of the W3C, even current standards (CSS 1 and 2, HTML 4) are not safe from retroactive patent encumbrance.
Section 5.3 of the policy provides for the possibility of re-chartering an existing Working Group under a new Licensing Mode (i.e., given that no-one would have an incentive to change it the other way, re-chartering an RF Working Group as a RAND Working Group.)
The Patent Advisory Group (the drafters of the new policy) can initiate this process and (albeit after approval from the Director), all the members get thrown out and have to be re-nominated, and *licensing commitments made by Working Group members under the older charter are void.*
In other words, if the e.g. CSS Working Group were dissolved and reconsituted in this way, companies could start charging licensing fees for the patents they hold on current CSS standards - either under RAND, or (worse) by withdrawing from the process completely and licensing under discriminatory terms.
Who has CSS patents, and who would they like to discriminate against?
I'm not sure what the libart license is, but mozilla.org will not accept LGPL and GPL-only code into its tree, because it can't be used by all members of our community.
Only if people are nasty enough not to triple-license their changes. mozilla.org hopes that there are very few people out there ungrateful enough to take and use a chunk of our code and then deny us the right to the fixes they make.
The upside is that more members of the free software community can use our stuff, and will hopefully contribute to the project.
It involves replacing all the license headers, which is a pain, and makes it harder to give your changes back if you do it. It's easier to incorporate the GPL into the original language.
No immediate hope of a good resolution as far as we know:-(
Gerv
Re:Why can't the GPL just go away
on
Mozilla Relicensing
·
· Score: 2, Insightful
This relicensing is all about letting more members of the free software community use our code, while maintaining at least the standards of copyleft required by the MPL. It's not about any license being better or worse than another.
Note: we have only relicensed 6,000 files, using Netscape's ability to relicense files under the NPL. We have a bunch more of those to do (with different comment structure), and then we have to ask permission for the ones covered by the MPL.
This is the very beginning of the process. The story erroneously implies it's finished. It's not.
Slashdot Mirror
It didn't get reported because it has had no real effect on Mitchell's work for the Mozilla project. She still does all the stuff for Mozilla she used to do. So why is it news?
In the middle of November, I'm going to stop being employed by Netscape. Will that be a big story too?
Gerv
The number of bugs is not a good measure of the quality of the product. That graph has been going up since we started recording numbers - does that mean Mozilla is buggier now than in 1999?
I just landed the links toolbar, which was one bug, and 20 people immediately filed bugs on it. That doesn't mean the product is "more buggy".
Gerv
But not nearly as obnoxious as the constant use of XML entities for localizing strings.
How would you like us to do localisation?
Gerv
Mozilla chief wrangler left article which mozillaquest uncovered first!
The guy who runs MozillaZine works at Netscape one floor down from where Mitchell Baker used to work. Do you really think Mozillaquest knew about her being laid off before MozillaZine?
Gerv
> Do you really have nothing better to do
:-)
How can there be anything better to do than writing code?
Gerv
Mozilla would benefit from constructive criticism appropriate to a not-yet-finished application. Mangelo's criticism is never constructive, and usually misleading and factually incorrect. You may claim that a view of Mozilla based on MozillaZine is rather rosy; a view of Mozilla based only on MozillaQuest would be wildy warped.
:-)
For example, "Netscape denies Netscape 6.1 based on Mozilla code". Or how about "Mozilla is getting steadily buggier because there are more bugs in the bug database." By that measure, no code at all would be the ideal, as it would be bug-free.
MozillaZine has its fair share of dissenters as well. Strauss, for one. And macpeep.
Gerv
Did you read any other comments? Take everything you read at MozillaQuest with a very large pinch of salt.
XUL is an XML-based language - just like XHTML, SVG or any of the others. The sentence "A standard XML parser cannot interpret XUL." is either wrong or extremely misleading. No XML parsers can _interpret_ what they read, but an XML parser can parse XUL perfectly. Mozilla uses expat for this purpose.
That is why you cannot display XUL as a Web page with Internet Explorer 5, Netscape 4.x, or other non-Mozilla-based browsers.
"Displaying XML as a web page" makes no sense. What happens is that you apply a style sheet to some XML (whether XHTML or something else) to display it. If you gave XUL a style sheet, it would display according to that style sheet. Essentially, this is what Mozilla does when it renders its UI.
Gerv
If you know the code to insert, sure :-) Or if someone else makes a patch which does that, you can easily apply it to your Mozilla installation, at the cost of a small speed penalty because you will be running with unjarred chrome. It's not really designed for this, but it could be used to do it.
Gerv
There is no danger to end users from Patch Maker. It's a development tool, like your C compiler or an editor.
Gerv
The impetus for creating Patch Maker seems to lie in the fact that Mozilla bugs are raging out of control.
In fact, the impetus for creating Patch Maker was to allow more people to contribute to Mozilla. Many UI designers are not able to manage the intricacies of our build process; many people do not want to purchase Code Warrior (on Mac) or MSVC++ 6 (on Windows) and are unable, for one reason or another, to install Linux. Many people do not have the bandwidth to continually download and update the CVS tree - even downloading a nightly is a major event which must happen at cheap telephone times.
This software is for all of these people. For the first time, you can make a significant code contribution to a large open source project without the complexities of compiling.
Note: Patch Maker is still in development; I would appreciate help porting it to Mac especially, and debugging it on Windows.
Gerv
--
gerv@mozilla.org, author of Patch Maker
I am the author of Patch Maker. Any questions about it may be directed to me :-)
Gerv
Keep in mind that this doesn't "change" any Working Group activities within the W3C to mandate RAND licensing.
That's not true - see section 5.3. Any current working group can be disbanded and converted to a RAND licensing policy; when it is, all previous licenses given by the members are null and void.
Disband CSS, put it under RAND and boom! No more Mozilla/Konqueror, and Opera Software pay through the nose.
Gerv
If this becomes the official Patent Policy of the W3C, even current standards (CSS 1 and 2, HTML 4) are not safe from retroactive patent encumbrance.
Section 5.3 of the policy provides for the possibility of re-chartering an existing Working Group under a new Licensing Mode (i.e., given that no-one would have an incentive to change it the other way, re-chartering an RF Working Group as a RAND Working Group.)
The Patent Advisory Group (the drafters of the new policy) can initiate this process and (albeit after approval from the Director), all the members get thrown out and have to be re-nominated, and *licensing commitments made by Working Group members under the older charter are void.*
In other words, if the e.g. CSS Working Group were dissolved and reconsituted in this way, companies could start charging licensing fees for the patents they hold on current CSS standards - either under RAND, or (worse) by withdrawing from the process completely and licensing under discriminatory terms.
Who has CSS patents, and who would they like to discriminate against?
Gerv
I'm not sure what the libart license is, but mozilla.org will not accept LGPL and GPL-only code into its tree, because it can't be used by all members of our community.
Gerv
> The relicensing is really a one-way gift.
Only if people are nasty enough not to triple-license their changes. mozilla.org hopes that there are very few people out there ungrateful enough to take and use a chunk of our code and then deny us the right to the fixes they make.
The upside is that more members of the free software community can use our stuff, and will hopefully contribute to the project.
Gerv
Exactly what the triple license is depends on what the original license was. NPLed files are staying NPLed for the moment.
Gerv
It involves replacing all the license headers, which is a pain, and makes it harder to give your changes back if you do it. It's easier to incorporate the GPL into the original language.
Gerv
> Do you have any insight into this?
:-(
No immediate hope of a good resolution as far as we know
Gerv
This relicensing is all about letting more members of the free software community use our code, while maintaining at least the standards of copyleft required by the MPL. It's not about any license being better or worse than another.
Gerv
Files under those licenses can be combined with GPLed code, so it's not a problem.
Gerv
Note: we have only relicensed 6,000 files, using Netscape's ability to relicense files under the NPL. We have a bunch more of those to do (with different comment structure), and then we have to ask permission for the ones covered by the MPL.
This is the very beginning of the process. The story erroneously implies it's finished. It's not.
Gerv
I maintain the Bugzilla Helper, which most people use to file their first few bugs. Any comments on how to make the process easier are welcome. :-)
Gerv
100,000 bugs doesn't really constitute a *large* database
Have you looked at the schema? A bug is a very complex thing = it's not just a row in a table. Add in 50,000 file attachments as well.
Gerv
> but then my free product isn't being very free, is it.
:-) It's your loss.
Free software != Someone else does all the work for you. It's free (libre).
> Open Source is terrible at getting the last mile done.
If your company doesn't use Bugzilla because it judges on appearances rather than function, do you think we give a monkey's?
Gerv
It has been suggested :-) When the Bugzilla UI is templatised, this will be a lot easier.
Gerv