[webkit-dev] Fwd: [ANN] Release of Bugzilla 3.0!

2007-05-10 Thread David D. Kilzer
Upgrading bugs.webkit.org would allow a custom Radar field to be added to each


  In 1998, the first open-source version of Bugzilla, 2.0, was
released to the world without much fanfare, just this little post
on the netscape.public.mozilla.announce mailing list:

mozilla.org's bugsystem, Bugzilla, has been completely rewritten.
We like the new version much better, and hope you will too. Best of
all, the source is now available, distributed under the MPL.  Learn
more at http://www.mozilla.org/bugs/.

- Terry http://people.netscape.com/terry/ 

  Nine years later, Bugzilla is used by thousands of companies around
the world with millions of total users. It has become the de-facto
standard in open-source bug tracking. Thousands of companies have
moved away from their costly commercial bug-tracking systems to
Bugzilla, usually finding Bugzilla more flexible and more
full-featured than the system they'd been paying thousands or hundreds
of thousands of dollars for, and proving that open source software
really can produce a competitive product.

  Today, the Bugzilla Project is extremely proud to announce the
release of Bugzilla 3.0, and just like Terry said in 1998, We like
the new version much better, and hope you will too. :-)

  Here's just a sampling of the major new features in version 3.0:

* Custom Fields
* mod_perl support for greatly-improved performance
* Per-Product Permissions
* XML-RPC Interface
* Create and Modify Bugs by Email
* And even more. See all the new features at:


  Bugzilla 3.0 also has a much-improved code base over previous
versions of Bugzilla. Improvements are still happening, but long-time
customizers and coders of Bugzilla will notice significant
improvements. And if you haven't seen Bugzilla code since 2.16 or so,
prepare to be (pleasantly) surprised!

  As always, we welcome open source contributors to Bugzilla, which is
built entirely by volunteers around the world. You too can be part of
the team that makes a product used by thousands of people daily. And
you don't have to be a programmer, either! See all the ways to
contribute at bugzilla.org:


  We hope that you enjoy Bugzilla 3.0!


Bugzilla is available at:


Release Notes  Changes
Before installing or upgrading, it is VERY IMPORTANT to read
the Release Notes:


To see a list of all changes between your version of Bugzilla and
the current version of Bugzilla, you can use the chart at:


Report Bugs
If you find a bug in Bugzilla, please report it! Instructions are
at this URL:


Try Out Bugzilla

If you'd like to test-drive Bugzilla, you can use the demo
installations of Bugzilla at:


You can ask questions for free on the mailing lists (or in IRC)
about Bugzilla, or you can hire a paid consultant to help you out:

  Free Support: http://www.bugzilla.org/support/
  Paid Support: http://www.bugzilla.org/support/consulting.html

About Bugzilla
  Bugzilla is a Defect Tracking System or Bug-Tracking System.
Defect Tracking Systems allow individual or groups of developers
to keep track of outstanding bugs in their product effectively.
Most commercial defect-tracking software vendors charge enormous
licensing fees. Despite being free, Bugzilla has many features
its expensive counterparts lack. Consequently, Bugzilla has quickly
become a favorite of hundreds of organizations across the globe, and
is widely regarded as one of the top defect-tracking systems available.

  See http://www.bugzilla.org/about/ for more details.

  -Max Kanat-Alexander
  Release Manager, Bugzilla Project

Description: PGP signature
---End Message---
webkit-dev mailing list

[webkit-dev] WebKit Project Goals

2007-05-10 Thread Maciej Stachowiak

Hi Everyone,

I recently watched a video on the topic of preventing poisonous  
people from hurting an open source project. One of the practices it  
recommends for a large open source project is to have a mission  
statement, so it's clear to everyone what is and isn't in scope for  
the project. I'm not too fond of the name mission statement (it  
sounds a little corporate) but I do think it's important to write  
down our goals as a project.

Ultimately I'd like to put this on the WebKit site, but I wanted to  
throw out some ideas for discussion. I'd like to hear if anyone  
thinks I have missed any project goals, if any of these are worded  
badly, or if it is worth calling out more non-goals.

WebKit Project Goals

WebKit is an open source Web content engine for browsers and other  
applications. We value real-world web compatibility, standards  
compliance, stability, performance, security, portability, usability  
and relative ease of understanding and modifying the code (hackability).

Web Content Engine - The project's primary focus is content deployed  
on the World Wide Web, using standards-based technologies such as  
HTML, CSS, JavaScript and the DOM. However, we also want to make it  
possible to embed WebKit in other applications, and to use it as a  
general-purpose display and interaction engine.

Open Source - WebKit should remain freely usable for both open source  
and proprietary applications. To that end, we use BSD-style and LGPL  

Compatibility - For users browsing the web, compatibility with their  
existing sites is essential. We strive to maintain and improve  
compatibility with existing web content, sometimes even at the  
expense of standards. We use regression testing to maintain our  
compatibility gains.

Standards Compliance - WebKit aims for compliance with relevant web  
standards, and support for new standards
In addition to improving compliance, we participate in the web  
standards community to bring new technologies into standards, and to  
make sure new standards are pratical to implement in our engine. We  
use regression testing to maintain our standards compliance gains.

Stability - The main WebKit code base should always maintain a high  
degree of stability. This means that crashes, hangs and regressions  
should be dealt with promptly, rather than letting them pile up.

Performance - Maintaining and improving speed and memory use is an  
important goal. We never consider performance good enough, but  
strive to constantly improve. As web content becomes richer and more  
complex, and as web browsers run on more limited devices, performance  
gains continue to have value even if normal browsing seems fast enough.

Security - Protecting users from security violations is critical. We  
fix security issues promptly to protect users and maintain their trust.

Portability - The WebKit project seeks to address a variety of needs.  
We want to make it reasonable to port WebKit to a variety of desktop,  
mobile, embedded and other platforms. We will provide the  
infrastructure to do this with tight platform integration, reusing  
native platform services where appropriate and providing friendly  
embedding APIs.

Usability - To the extent that WebKit features affect the user  
experience, we want them to work in accordance with good human  
interface design principles, and to mesh well with platform-native HI  

Hackability - To make rapid progress possible, we try to keep the  
code relatively easy to understand, even though web technologies are  
often complex. We try to use straightforward algorithms and data  
structures when possible, we try to write clear, maintainable code,  
and we continue to improve names and code structure to aid  
understanding. When tricky rocket science code is truly needed to  
solve some problem, we try to keep it bottled up behind clean  


WebKit is an engine, not a browser. We do not plan to develop or host  
a full-featured web browser based on WebKit. Others are welcome to do  
so, of course.

WebKit is an engineering project not a science project. For new  
features to be adopted into WebKit, we strongly prefer for the  
technology or at least the use case for it to be proven.

WebKit is not a bundle of maximally general and reusable code - we  
build some general-purpose parts, but only to the degree needed to be  
a good web content engine.

WebKit is not the solution to every problem. We focus on web content,  
not complete solutions to every imaginable technology need.

webkit-dev mailing list