Gasp! Bugzilla works on Windows?! Yes.. Yes it does. In fact it even works with Microsoft SQL Server as a back end.

Perhaps some back ground for those unsure what Bugzilla is.. Bugzilla is:

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.

~ Excerpt from Bugzilla.org

More than that Bugzilla is Open Source. Meaning that you can alter it in any way you like. Ok that maybe overstating it but is close enough to the truth. While you are free to alter it, there are certain truths that can not be overcome easily. First of Bugzilla is prodomidently focused on supporting MySQL as it standard database platform. Though it is stated it is focused on ANSI standards for databases that’s all well and good reality is different. Oracle for example requires the used of on the fly sql re-writes to translate the mysql style LIMIT. Similarly MSSQL requires almost identical contortions to make it work.

Anyhow here ends my tease for the time being. Coffee beckons me with sweet seductions that would rend my keyboard in twain and I’m weak willed…and well I like my keyboard and I’m trying to reduce the number of gnaw marks I add to it on a weekly basis.

Dentro de las herramientas de seguimiento de errores existe un amplio abanico que va desde las más simples, o más centradas en su funcionalidad original, como Bugzilla o Mantis (ambos OpenSource), hasta las más evolucionadas como Redmine (OpenSource), JIRA o FogBugz (ambos comerciales), que complementan su funcionalidad original de seguimiento de errores con un conjunto de funcionalidades adicionales, que les permiten saltar un nivel y convertirse en herramientas con las que poder efectuar el control y la gestión de un proyecto.

TRAC (OpenSource) es originalmente un sistema de seguimiento de issues, esto es importante porque se posiciona no como un sistema orientado principalmente a la gestión de bugs, como Bugzilla o Mantis (aunque luego hagan más cosas), sino que busca ofrecer los mecanismos básicos para poder efectuar la gestión de un proyecto, y en este sentido se aproxima a lo ofrecido por JIRA o FogBugz.

TRAC es flexible, no impone ninguna metodología, simplemente ofrece un conjunto de herramientas para que se puedan hacer las cosas, algunas de estas herramientas son:

• Sistema completo de gestión de Tickets, que permiten establecer y asignar las funcionalidades que se desarrollarán en el proceso (nuevas características, errores, tareas…)
• Wiki, como repositorio común de información/documentación para el proyecto (estructura del proyecto, dónde están los servidores, cómo configurar los entornos, guías de estilo y codificación…tooodooo)
• Integración con el sistema de control de versiones (Subversion y Git…entre otros)
• Roadmap, o calendario de versiones, que permite ver el grado de avance y cuándo se preve que sean liberadas las nuevas funcionalidades
• Timeline, o lugar en el que se registran y se pueden revisar todas las operaciones realizadas en el proyecto desde el cambio en una página del wiki hasta el último commit en el repositorio de código.
• RSS como mecanismo de seguimiento en casi todos los módulos de TRAC
• … otras muchas…

Solamente con estas características sería una herramienta interesante ya que ofrece varias cosas importantes en un proyecto:

• Medio de comunicación con el cliente, en todo momento puede ver la marcha del proyecto.
• Punto común de recogida del conocimiento asociado al proyecto.
• Información al momento de la situación del proyecto en cada momento.

Pero lo que caracteriza y diferencia fundamentalmente a TRAC del resto es su sistema de plugins, o mecanismo que permite extender TRAC todo lo que permita la imaginación y lo convierte casi-casi en una plataforma, y el soporte de la comunidad al mismo. Una lista completa de los pulgins disponibles para TRAC puede encontrarse en Trac Hacks, y una lista un poco más corta:

Gestión de usuarios

• Administración de cuentas (AccountManagerPlugin)
• Autenticación HTTP (HttpAuthPlugin)
• Integración con Active Directory (ActiveDirectoryAuthPlugin)
• Integración con CAS (TracCasPlugin)

Integración de la administración con Subversion

• Integración de administración con SVN (SvnAuthzAdminPlugin y TracSvnAuthzPlugin)

Extensión del sistema de Tickets

• Gestión de campos personalizados (TracCustomFieldAdminPlugin)
• Gestión de workflows para tickets (WorkflowEditorPlugin y Workflows personalizados)
• Dependencias entre tickets (MasterTicketsPlugin)
• Soporte para la estimación de horas en tickets (TracHoursPlugin, TimingAndEstimationPlugin, EstimationToolsPlugin y SchedulingToolsPlugin)

Integración con otros sistemas y extensiones

• Integración con Hudson (HudsonTracIntegrationPlugin)
• Integración con Git (GitPluginForTrac)
• Integración con Agilo-SCRUM (AgiloForScrumPlugin)

Otros

• Gestión de parámetros de inicialización de TRAC (IniAdminPlugin)
• Personalización del Timeline (TimelineCheckinFilterPlugin y TimelineUserFilterPlugin)
• Sistema de Tags (TagsPlugin)

Interoperabilidad

De todos los plugins existentes para TRAC el más interesante de todos es el XML-RPC Plugin porque expone al exterior toda la funcionalidad de un servidor TRAC para que pueda integrarse con cualquier lenguaje y para cualquier cosa. Por ejemplo se podría:

• Construir un sistema simplificado para la entrada de tickets-bugs solamente con los datos estrictamente necesarios.
• Realizar la alimentación inicial de issues en un proyecto a partir de un MS Project
• Generar la descripción inicial de tareas a partir de una definición funcional decente
• …

y todo ello en el lenguaje y la forma (desktop, web…) que mejor nos venga. Espero poder terminar en breve TRACdrops, y poder disponer de TRAC desde Java con toda su potencia de una forma simple…

This week I’ve received four times the same (i.e. duplicated) ViewSourceWith (VSW) bug report that sounds…

“ViewSourceWith stopped to show the icons on context menu, this regression is present on Karmic Koala (Ubuntu 9.10)”

I use Intrepid Ibex (Ubuntu 8.10) and all works fine, so I’ve burned a Karmic Koala ISO and tested it discovering the “regression” exists.

Debug -> Add logs -> Remove logs -> Clean Profile -> DOM Inspect -> MozRepl without find where the problem occurs.

Last resort -> Bugzilla -> Found!!!

The Bug 527253 unveils the mystery!

This isn’t a regression

ViewSourceWith isn’t the guilty, Firefox isn’t the guilty but… Gnome is the guilty

Type the command shown below from command line and restart Firefox

gconftool-2 --type bool --set /desktop/gnome/interface/menus_have_icons true

EDIT Or use the UI to obtain same result (thanks to mzz) system -> preferences -> appearance -> interface -> show icons in menus

This worked for me and also for two bug submitters (the other two guys do not replayed to my hint)

So remember Bugzilla is your friend

As a developer, never thought one day I would install Bugzilla. I guess, developer always hates bug tracker. But I was appointed as a tester in a project, a there is no budget for any bug tracker. Thus, there is Bugzilla.

Several things you need to download using aptitude. Run below command in the terminal:

sudo apt-get perl apache2 libapache2-mod-perl2 build-essential mysql-server-5.1

Then download the latest Bugzilla from www.bugzilla.org. You may download it from Ubuntu repository, but I prefer to get the latest release, fresh from the oven. Once you have the bugzilla archived file. Unarchived it and you should get the bugzilla folder. Place the bugzilla folder in /var/www path and you should get /var/www/bugzilla.

Then you need to configure your apache2. Then open apache2 default file by command below:

sudo vi /etc/apache2/sites-available/default

Add this entry in your default file:

<Directory /var/www/bugzilla/ >
AddHandler cgi-script .cgi
Options +Indexes +ExecCGI
DirectoryIndex index.cgi
AllowOverride Limit
</Directory>

Then go to /var/www/bugzilla folder. Run below command:

sudo ./checksetup.pl --check-modules

It will list out which perl modules you need to install. You can install one-by-one depending on your needs. To keep things simple, we just install everything by running below command:

sudo perl install-module.pl -all

Perl will download, compile and install all the required and additional components for Bugzilla. Then open a file called localconfig by below command.

sudo vi /var/www/bugzilla/localconfig

Edit below attributes in the file:

#No .htacess file will be created. If set to 1, it will be created.
$create_htaccess=0;
#Web Server (Apache2) Group. Since I don't have one, I set to empty value.
$webservergroup='';
#Database type (default)
$db_driver='mysql';
#Database Host (default)
$db_host='localhost';
#Database Name (default)
$db_name='bugs';
#Database User (default)
$db_user='bugs';
#Database Password
$db_pass='';

Then enter your mysql console, and type below command to create a user named bugs and to set the privileges.

mysql > GRANT SELECT, INSERT,
UPDATE, DELETE, INDEX, ALTER, CREATE, LOCK TABLES,
CREATE TEMPORARY TABLES, DROP, REFERENCES ON bugs.*
TO bugs@localhost IDENTIFIED BY ’buggafool’;

mysql > FLUSH PRIVILEGES;

Run below command and the script will generate the necessary tables in your mysql server:

sudo /var/www/bugzilla/checksetup.pl

Restart your apache2 server by below command:

sudo service apache2 restart

Now you’re good to go. Browse your local bugzilla @ http://<ip-address>/bugzilla/.

yeah!! How cool !! ..

Mozilla has a special day every Tuesday, it is bug day, where everyone in world get in their irc channel #bugday and discuss all their contribution to bugzilla. It will very helpful in our Community , as we will contribute and fiz some bugs in mozzila inshaAllah, and getting help from experts is needed.

// if you don’t have irc yet then check out this post to set it up Get IRC on your Machine

They have different timing for all around the world , so it wont be 300,000 users in one channel

• East Asia/Australia session: 8pm-10pm in Tokyo, Japan (GMT+9)
• Europe/Africa session: 8pm-10pm in Paris, France  -  Cairo, Egypt (GMT+2)
• Americas session: 9pm-11pm in New York, New York (GMT-4) / 6pm-8pm in San Francisco, California (GMT-7)

Some links to help you around:

Bugday’s Wiki

Bugday’s first Blog Post

Mozilla QA blog

/* quoted from bugday’s wiki

• The following documentation is good to become familiar with for anyone working on Mozilla projects:
  • Mozilla QA linked to from the “For Testers” section of mozilla.org/developer
  • A good document on how to find existing bugs
  • Read Bug Writing Guidelines to learn how to write effective bug reports that lead to bug fixes.
• Review the documentation specific to the topic of the day.
• Join the #bugday channel
  • Go to your favorite IRC client
    • Windows clients
    • MacOS clients
    • Linux clients
  • Connect to irc.mozilla.org and “/join #bugday”
  • Then, just ask the moderators how you can help for the topic of the day.

  */

A long time ago, I promised to write an article on how to display custom fields under certain circumstances… and never wrote it. But as late is better than never, here we go!

One new feature in Bugzilla 3.4 is the ability to display a custom field only when some other field has some given value. For example, let’s say I want to display a custom field named “Impact” only when the priority of bugs is P1. The first thing to do is to create (or edit) the custom field (Administration > Custom Fields > Add a new custom field):

Displaying a custom field only when another field has some given value

The important part is on the right of the screenshot. Available fields to depend on are drop-down and multi-select fields and custom fields. Typically, this means the priority, severity, OS, platform, bug status, resolution and the product fields. In our example, “Priority” is selected, and available values for the priority field are automatically listed, from which we can select “P1″, as desired. Now, when a bug has priority P1, the Impact custom field will be displayed, else it won’t:

The Impact custom field is only displayed when the priority is P1

The change is dynamic, thanks to JS, so you don’t need to reload the page to see the custom field appearing/disappearing. Once you select another priority, the Impact field will immediately disappear from the page, and it will reappear if you re-select P1. (In the screenshot above, I assume you know how to populate values for the Impact field: Administration > Field Values > Impact > Add)

Another cool feature is the ability to decide which values to display in drop-down and multi-select custom fields based on another field value. in our example above, let’s say I want to display values in the Impact field depending on what the severity of the bug is. The first thing is to add this dependency as follows:

Custom field whose values depend on another field

Compared to the first screenshot, I added the dependency to the severity field. Available fields to depend on are the same as above, i.e. priority, severity, etc…. You then have to either click the “Edit legal values for this field” link on the left of the screenshot, or go to Administration > Field Values > Impact. Then you have to edit each field value which is affected by the severity of bugs:

Restricting when to display a custom field value

As we added a dependency, a new item has been added when you edit field values. By default, the “Only appears when Severity is set to” field is left empty, meaning that the field value will always be available, independently of the bug severity. Let’s say we want to display the “Global: affects all other components” value of the Impact field only when the bug severity is “blocker”. In this case, we edit the value as shown in the screenshot. Let’s also say that we want to display the “Global: affects many other components” value only when the severity is “critical”. We edit the value in a similar way to what we did above. Now when you view a bug, you will see something like this:

Restrict the list of available field values

The “Global: affects all other components” value is not listed, because the severity of the bug is not “blocker”. The “Global: affects many other components” value is listed because the bug severity is “critical”. The other two values are listed because I didn’t set any restriction on them, and so they are always available when the Impact field is displayed.

You will probably ask “How do we display the Impact field when the priority is either P1 or P2?”. The short answer is that you cannot yet, unfortunately. This is a limitation which we are working on, see bug 479400. Another question could be “How do we display a value when the bug severity is either blocker or critical or major?”. The answer is the same as for the previous question: you cannot do this yet, see bug 522971. I hope to see them fixed for Bugzilla 3.6, but the freezing date is pretty close and I fear these features won’t be available on time. Maybe in Bugzilla 3.8!

It might not be obvious to you fancy pants’ in the big software shops that the QA team is doing stuff that is not useless.  Try once, just go ahead and try tesitng your own software.  I guarantee you won’t find the bugs and usability issues that the QA team will.  Why?  Because their brains are more wired to the users than yours ever will be.  You spent weeks, even months developing shiny feature X and in your left hemisphere everything runs like a clock.

Iteration after iteration you’ve slowly brainwashed the shortest point from A to B to get Feature X to work.  You’ve subconsieously mapped the path through the briar-patch of clicks and dialogs that shows off your buttery feature.  In your borg-like developer mind, everything works great.  Ship it… SHIP IT!  Right?  Wrong.

I am having some experience with taking the QA out of the cycle and using developers to do all of the functional and spot testing.  We’ve caught some dooseys but I know there are more lurking in the shadows.  Those “Oh riiight” moments every developer goes through as they receive a bug report on why their shiny feature has a tarnish are as important as designing the feature in the first place.

So for the record, if you have a QA person in your organization give them a hug now.  Seriously.  I’ll wait…. They are the buffer zone between the intuitive users and should be appropriately groomed and cared for.

If you are unlucky enough to not have an official QA rock star please take a deep breath and try to get your thinking in the right side of your brain.  Be one with the universe, buy yourself a latte and take off your shoes and socks.   Don’t worry it’s not impossible for a non-QA type to do QA work.  But if you have to do it you have to think like a developer and explain it to the developer in the most efficient way possible.  Try the following:

1. Steps to reproduce.  This is the most important, even more important than the bug description itself.  If you tell me that feature X failed to work when you were trying to make it work, well that’s just dandy.  The average software program has 10000 moving parts in 10000 different execution contexts ( OS, platform, Java version, etc ) at any one time.  I need a context and more importantly I need you to explain to me like I’m a 3 year old exactly how to reproduce this in my environment.  Now I am all about simple and concise.  You’re not writing a novel.  Just a nice point format describing how to break the code will work.  Something like:
   • Open the project and edit the file.
   • Save it as file14.xml
   • Re-open the saved file with the menu tab. The resulting error/behavior occurs when you’re standing on one foot and patting your stomach.
2. Attach supporting files.  This can and should include log files.  If your program doesn’t have log files, the developers on the product have to learn about logging now.  Assuming the dev team has moderately sprinkled the code with an appropriate amount of log statements you can now put them to good use.  The perfect time to utilize these nuggets of information is when something goes terribly wrong.  A proper log statement gives developers a context of where in the code something went wrong and what was calling it when it did go wrong.  This can save hours of digging if the problem is not easy to reproduce.  If you don’t have proper logging, go slap your devs upside the head and try reproducing the bug from within a console environment.  That’s right, simply start the program from the good old command prompt.  When things go upside down you might be lucky enough to get a stack trace in the console.  When this happens, immediately capture it and push it into the bug report.  Any other supporting file that might be useful should also be attached to the bug report.  If you are working on an program that has it’s own XML/WSDL/binary/project files you should attach them.  The fastest way to get the developer to reproduce your issue, the faster the bug will turn around.
3. Use a bug tracking tool… for the love Darwin, use a bug tracking tool.  There is nothing worse than emailing an excel speadsheet around and then wondering why your bug tracking process is broken.  It’s the year 2009 and the wild world of open source offers a rainbow of different tools.  One of my favorites is Bugzilla.

All hail to the peeps in QA.  Devs give you a hard time, but we really love you.  You keep us from having to think like humans and interact with the meat-types.

Cheers

}

Today I had a serious think about the state of my very long “to-do” list. Normally I keep this on sheets of paper, but this is inflexible. For example I can’t easily keep track of the exact current state of each item, and every few months I end up copying out the whole list again, a chore which takes the best part of a day.

These new-fangled “computers” can help with this sort of thing … right?

There’s loads of note-taking and to-do list software out there. Much of it is alpha quality, and/or just obviously crap. Wikis are flexible for making notes on single topic areas, but hard to automate and categorize. Web-based wikis have terrible UIs.

I have settled for now on using Tomboy, a wiki-like note taking application.

What particularly led me to start with Tomboy is the Tomboy API accessible through DBus. Using this, I can pull in content from outside sources.

I started off with a script to pull in Red Hat Bugzilla bugs into a “Bugzilla Incoming” page in my Tomboy instance. (Bugzilla has an API too …)

(Download: bugzilla-incoming.py)

Running ./bugzilla-incoming.py -u *** -p *** daily does several things: First of all it searches the existing Tomboy pages for Bugzilla numbers (so it doesn’t fetch any bugs we already know about), then it queries Bugzilla for all bugs related to me, and finally it adds any bugs we’ve not seen to the Bugzilla Incoming page. From that page I can manually sort them into my to do list.

In future I hope I can pull in items from other sources automatically such as email.

There are other possibilities too: For example you could look over daily IRC logs and add all conversations you had with a particular person to a person-specific Tomboy page.

It might work the other way too, for example generating public feature lists from private wiki pages.

Update/edit

I wanted to add that I think the trick is inventing a markup syntax. For example, for Bugzilla bugs, I used:

[#123456 Summary]

The [#123456] markup can be added to pages easily, by either humans or scripts. Moreover scripts can edit that markup too without damaging any other part of the page (eg. if the summary changes).

Tomboy itself doesn’t support this at the XML level — eg. there is no way to add custom XML or XML namespaces. So we have to invent our own text markup to do the job.

Aquellos que se hayan pasado por la base de datos de “Software Compatible con ReactOS” conocerán el auténtico engorro que era Buscar o Añadir una nueva aplicación a la misma.

Ahora se ha remodelado toda la Sección como podéis ver en estas imágenes y se han introducido características bastante útiles. En este post se analizan los principales cambios.

Si queréis visitarla: Aquí

En la página principal se pueden ver los últimos envíos. Junto a ellos un código de colores:

• Verde: Si la aplicación funciona perfectamente.
• Naranja: Si funciona regular o es inestable.
• Rojo: Si no funciona o es muy inestable.

Al pulsar sobre el nombre de una aplicación, aparecen las versiones que han sido testeadas y su compatibilidad con ReactOS.

Pero tal vez los cambios más significativos se han producido a la hora de mostrar los Reportes.

Pestañas…y vinculación con Bugzilla.

Usando Pestañas ahora todo está mucho más organizado.

Una pestaña para Comentarios, otra pestaña para la gente que ha mandado Tests,otra pestaña donde ver fotos de la Aplicación corriendo en ReactOS y una pestaña de Bugs.

Y es que la principal Novedad ha sido la vinculación entre Bugzilla(lugar donde subimos los Bugs de las Aplicaciones) con esta Base de datos.

De esta manera y a tiempo real podemos ver que Bugs están afectando a una Aplicación, o incluso que Bugs se han arreglado para que dicha aplicación funcione.

Tener un historial de los Bugs que la aplicación ha sufrido puede permitirnos conocer la causa si el Bug vuelve a reaparecer.

Enviar aplicación…

Otra de las “quejas” de aquellos que querían introducir una nueva aplicación en la base de datos era la longitud del proceso. Más de 3 páginas llenas de datos. Este hecho estaba limitando el número de aplicaciones introducidas y la calidad de la Base de Datos.

Ahora si pulsamos en el Botón de “Enviar aplicación”, aparece un pequeño formulario que se rellena en 1 minuto. A destacar que ahora podemos introducir el número de revisión en la que ha sido testeada la aplicación.

Hasta ahora la Base de datos estaba limitada a Releases, ahora ya (por fin) tambien a revisiones.

El cambio ha sido notable, y seguramente nuevas características sean añadidas pronto.  Si tenéis alguna sugerencia, o queréis que alguna característica sea añadida solo tenéis que pedirlo y nosotros nos encargaremos de transmitirla.

Recently I blogged about using Bugzilla to track features. I am happy to report that things are moving forward really well thanks to the community and Mylyn. We now have created the high-level delivery plan for Symbian^3 in Bugzilla, and completed the details for one of the key features: New Graphics Architecture (NGA – aka Screenplay).

As you can see from the picture, Mylyn makes it really simple for anyone to keep an eye on the plan.

BUG_ID 176 is the top level entry for NGA. In this post, I won’t go into the specific details of NGA, but explain the next step that we are taking in our planning: The Integration Plan.

Having all this data in Bugzilla allows us to build a good view of  the progress of a specific release. As we do not want to be monitoring every single submission, we have decided to follow the implementation of  “Key Features” (we are currently discussing the key features for Symbian^3)

The aim is to extract all the good information provided by the package owners and put into a format that facilitates the analysis of the health of the release. Taking a leaf from the Agile book, and introducing a 2-week regular heartbeat for our kits releases and tracking feature increments against it (for regular kit updates click here).

Also, any data beyond 6 months from “today” is displayed in quarters since we need to remain flexible and responsive to change (a “scaling agile” practice). Hence, it is understood that the detailed plan beyond 3 months will be fluid and beyond 6 months is only an indication of intent.

It is  probably worth noting at this point that the integration plan is based on voluntary contributions, and that we aim to increase the confidence in it by promoting frequent stage deliveries and asking the contributors to provide regular updates when changes occur.

The above table is a section of the full integration plan for Symbian^3

We will provide additional value to the Bugzilla data by providing a statement of the “Risk-level” of the contribution.

This reflects the release manager’s personal judgement, taking into consideration other aspects of the submission such as dependencies with other backlog items, IP licensing  issues, engagement of the contributors with package owners or the foundation team… and so on. This is signified by a B.R.A.G. status.

So were is the integration plan? Well … it’s still under development, it has been internally reviewed and it will be published by the end of September via the Release Planning site. If you want to make sure you get it hot off the press, you can either follow me on twitter or subscribe to the wiki site.

This blog entry is an early preview of what we are planning to do, and I would like to solicit your feedback on the soundness of the high-level concepts ellaborated here. Please share your views with us!

Hi folks,

An announcement regarding fpaste : A simple tool for posting info onto fpaste.org.

It’s a python script that enables you to paste the output of a command, or a file to fpaste.org. For those who are unaware of what fpaste.org is, please click the link . It’s a pasting site that comes in very handy when the folks at #fedora help people troubleshoot (since pasting more than 3 lines on #fedora earns you a well deserved kick) . The package includes a well written man page for those who’d like to learn it’s usage.

I’m very grateful to Jason ’zcat’ Farrell (upstream) and Rahul Sundaram (package reviewer) for making this so quickly possible.

I pushed the packages to cvs and bodhi last night. They will hit the repos soon.

Now that Bugzilla 3.4.1 has been released earlier this month, we can focus on development again. I’m going to give you a brief overview of new features and major changes we did in our code recently:

• Bug 214861: You can now use your saved searches to generate new series for New Charts. Till now, you had to create series from scratch.
• Bug 349336: When you create a new user account and choose your password, you are now automatically logged in.
• Bug 471620: Passwords are no longer limited to 16 characters. They can be as long as you want.
• Bug 480986: The Bitmap (BMP)-to-PNG conversion tool which was based on Image::Magick is no longer in the core code of Bugzilla. It has been moved into an extension which will be shipped with Bugzilla 3.6 (this extension is accessible using CVS, in the extensions/bmp_convert/ directory). To enable this extension, delete the extensions/bmp_convert/disabled file.
• Bug 507493: checksetup.pl’s output now uses colors to highlight missing or too old Perl modules. This should prevent a large number of questions we got on IRC these last few weeks about upgrading problems.
• Bug 508xxx: various improvements have been made to checksetup.pl, which should make upgrades significantly faster.
• Bug 509027: There is now a hook in Bugzilla::Attachment::_check_data() which lets extensions manipulate attachments before they are added to the DB. The BMP-to-PNG converter mentioned above uses this hook. You could also imagine an extension which looks at the “isurl” attribute and downloads the document pointed by this URL (do it at your own risk, of course, in case the URL points to a 4Gb DVD ISO).
• Bug 509497: GROUP_CONCAT(), natively implemented in MySQL, will soon be available for PostgreSQL and Oracle as a custom sql_group_concat() function. The function is ready for checkin for PostgreSQL, but we are still waiting for an updated patch for Oracle. It should land on time for Bugzilla 3.5.1.
• Bug 108243: Thanks to the new sql_group_concat() function mentioned above, bug flags can now be displayed in buglists! I will check in this patch as soon as the patch for sql_group_concat() is ready for Oracle DB. It should also be available on time for Bugzilla 3.5.1. (Note that I said “bug flags”, meaning that attachment flags won’t be displayed in buglists.)

More cool stuff should come in the coming weeks!

There is no planned date for Bugzilla 3.5.1 yet, and in all cases, keep in mind that it will be a development snapshot. It will not be suitable for production. Our next stable release will be Bugzilla 3.6.

We released Bugzilla 3.4.1 a few minutes ago to fix a security bug reported two days ago. Your installation is only vulnerable if at least one of your products has the “Entry” bit turned on for at least one group. Note that users cannot do any harm: security checks are working fine and so no user can file or move a bug into a product if the user is not allowed to access this product. We marked this bug as a security one because a user could see the name of some products despite he should not be aware of their existence (when these products have Entry + Mandatory/Mandatory set).

Here is what happened since we released Bugzilla 3.4 on Tuesday:

Tuesday, July 28

11:00 GMT: Bugzilla 3.4 is available for download.

Thursday, July 30

15:02 GMT: Sergej Pupykin files bug 507389 about too much product names being visible in the “Product” drop-down field in show_bug.cgi to users with no access to them.

17:05 GMT: I confirm that the bug is a regression in 3.4.

18:40 GMT: A first fix is proposed.

Friday , July 31:

10:23 GMT: A second fix is proposed. This one gets r+

Saturday, August 1:

10:59 GMT: Bug 507800 is filed. We are going to release Bugzilla 3.4.1 today.

12:38 GMT: The security fix is checked in and the bug marked as FIXED.

12:48 GMT: Automated QA tests (running Selenium) report several errors.

13:04 GMT: I confirm that the security fix (which I wrote; oops) is bogus and is responsible for the bustage.

13:22 GMT: New fix proposed.

13:51 GMT: All QA tests now pass successfully. We are ready to go.

14:01 GMT: The fix is checked in.

15:00 GMT: mkanat is done with the website update.

15:41 GMT: Bug 507800 is marked as FIXED. Bugzilla 3.4.1 is officially available for download.

If you already upgraded to 3.4, you can safely upgrade to 3.4.1 as the changes between both versions are really non invasive. I hope we won’t need to release 3.4.2 next week!

Bugzilla is a “Defect Tracking System”, which allow individual or groups of developers to keep track of outstanding bugs in their product effectively. Well,

Subversion (SVN) is a version control system used to maintain current and historical versions of files such as source code, documents, web pages, and libraries.

Although, these two applications are extensively used in standalone mode and rarely in integrated mode — at walking tree we realized that the real beauty is in having SVN integrated with the Bugzilla. It immediately provides us following advantage:

1) We exactly know the code which has been checked-in for a given issue (0r shall I call it which bug ID)

2) As a developer working on code fix, it always helps me to see a consolidated comments — instead of scanning through my past mails

3) The dependency among the code let us know about the dependency among the issues. Thus it provides great input to the deployment team.

Isn’t that really cool? Well, specially for a process oriented organization like Walking Tree, this was a needed integration.

Thank you Ajit for making life easier for the Walking Tree developers. This will help us in having better control on our product development. It will also help us in sharing information transparently with our customers.

We released Bugzilla 3.4 today, which also means Bugzilla 2.x is EOL (including Bugzilla 2.22). Here is a quick (and incomplete) list of new features/improvements compared to Bugzilla 3.2:

• The page to file bugs is now simpler, with “advanced” fields being hidden by default.
• The home page has been redesigned to be easier to use by new users.
• Logged out users can no longer see email addresses of other users at all, to prevent spam. Only the name of users is displayed.
• All passwords are now encrypted using SHA-256 instead of the crypt() function. This means passwords can now be longer than 8 characters.
• It’s now possible to send emails asynchronously when updating bugs (default: off), so that your browser doesn’t have to wait for all emails to be sent before displaying the page.
• Dates and times in comment headers and in emails are now displayed using your timezone instead of using the server timezone. Set your timezone from your Preferences panel.
• Several improvements to custom fields (new species of custom fields, as well as the possibility to display them under some given conditions).
• You can now reorder columns to display in buglists. Till now, you could only choose which columns to display, but you couldn’t reorder them. This is now possible.
• By default, obsolete attachments are hidden when viewing a bug. You can click the “Show obsolete” link to display them.
• You can use custom drop-down fields in tabular and graphical reports.
• Many new webservice methods.

If you are still using Bugzilla 2.x, or a development snapshot (3.3.x), you are highly encouraged to upgrade to 3.4. Also, if you are already running Bugzilla 3.2.x, the upgrade to 3.4 should be straightforward as there is no charset conversion (remember when we moved to UTF8 in 3.2), and almost no DB changes (besides new foreign keys to ensure your DB integrity). Note that you should run sanitycheck.cgi and fix errors reported by this script before upgrading, to avoid problems later.

I have just posted the tarballs and done the website updates for Bugzilla 3.4! This means that we’re out, released, ready to download, install, and go!

Bugzilla 3.4 is the best release of Bugzilla we’ve ever made. It has tons of great new features, the most exciting of which are listed in the release announcement, so I won’t repeat them here. But you should go download it!

The Story of Bugzilla 3.4

As you look through the New Features list of Bugzilla 3.4, you may notice that it fixes tons of major issues that Bugzilla has had since its beginning. For example, we fixed the biggest performance problem in Bugzilla–sending emails when a bug is updated–and we finally hide email addresses from logged out users, to prevent spam. And that’s just a tiny taste of what’s new. Really, check out the New Features list to see everything.

But you may be asking yourself, why the sudden fixing of all these issues, and why didn’t we do it before?

Well, that’s an interesting story! From about 2003 to 2008, we spent nearly all of our time fixing up the code of Bugzilla. It needed a lot of refactoring, and we really did it–five years of it! We added new features at the same time as we refactored (remember, Bugzilla 3.0 had the largest number of major new features of any release we’ve ever done, and we were still refactoring), but the refactoring was our main focus. But finally, finally, with the release of Bugzilla 3.2, we fixed up one of the last major code issues in Bugzilla–we changed process_bug.cgi into a nice, simple series of steps that use Bug objects to do all their work.

After all this was done, we could finally take the time to look around and say, “What next?”

Well, what happened next was what led to such a great Bugzilla 3.4 release. First, I declared a new method of prioritizing work on the Bugzilla Project that put major issues of our current users as higher priority than adding new features for our prospective users. This led to us looking at the major survey items from our 2008 Bugzilla Survey and doing something about all the major requests that we could address immediately. Then we went through and looked at the bugs with the most votes on them, and did something about a lot of them.

And that, pretty simply, led to us addressing the things that people most wanted, and that we could actually prove that they wanted (because we had great survey feedback, or a lot of votes from individuals on our bugs).

Now that we’ve addressed so many of the individual things that users wanted, look to Bugzilla 3.6 and later for some big user interface and usability improvements–we have the results of extensive usability research that was done on Bugzilla, thanks to students from Carnegie-Mellon University, and we are already addressing the list of issues that that research generated.

Warning for WebService Clients: Changes Since Bugzilla 3.4rc1

Anybody who has been writing WebService clients against the 3.3.x or 3.4rc1 releases should know that we changed a few things in the API between 3.4rc1 and 3.4:

Bug.comments now takes an “ids” parameter instead of a “bug_ids” parameter (we just renamed the parameter to be consistent with out other WebService functions). Also, it will now throw an error if you try to add a private comment and you don’t have the permissions to do so. (Previously it just added a public comment if you didn’t have the permissions to make a private comment.)

Bug.history now returns its result in a completely different format, one which is more consistent with the format that Bug.comments and Bug.get use.

Progress on Bugzilla 3.6

Since our last Bugzilla Update just a few weeks ago, we’ve fixed several usability issues, sped up quicksearch, and added the ability to disable field values in global drop-down fields (without deleting the value).

Coming up soon, expect to see a lot of new WebService methods–there’s been a lot of activity in adding WebService code, lately.

The End of Bugzilla 2.x

With this release, we EOL’ed Bugzilla 2.22, the last remaining supported 2.x release. That means that only 3.x releases are supported now. It’s kind of wild to think that Bugzilla 2.x is “dead”, after nearly ten years, and so much of my personal time spent on it. I started working on Bugzilla back in the 2.18 days, and I was pretty much the release manager for three major 2.x releases–2.18, 2.20, and 2.22. It’s amazing to think that those releases were so long ago that now the very last one has reached the end of its support life. It’s all Bugzilla 3.x (and hopefully 4.x soon) from here on out, my friends!

Subscribe to the Bugzilla Update

There is an Atom feed that you can subscribe to and read in your RSS reader, for just the Bugzilla Update.

Measuring SW quality can be complicated, even for a chipmunk

Maintaining the current high quality levels of the platform assets is a big priority for both our members and ourselves.

In the past, Symbian Ltd. did a good job at understanding how the software maturity was evolving and when the platform would be ready for releasing. Moving to open source has changed the sources of information available to us and their reliability. So, can we still measure the quality of our platform?

To answer this question, the Release Council launched a working group, back in June, that has identified a set of initial metrics for the job.

We are taking an Agile approach by implementing quality metrics in iterations. The first iteration will be a small set that would deliver to us substantial value, it will enable us to learn from the experience and then apply improvements to the next iteration.

Here is my take on why the proposed metrics are the right ones to start with:

Turnaround times, Inflow, Outflow and Open Bugs

One source of information available to the Symbian Foundation is Bugzilla. The proposed metrics not only will allow us to get a view on the quality of each package but also on the health of the community around it. By using these metrics we will try to answer questions such as:

• How diverse is the community contributing to the package?
• Is the package actively being tested/used by other members beyond the package owner?
• How active is the community around the package? Do they care enough to ensure that critical bugs are turned around quickly?

Implementing these metrics becomes easier thanks to open source tools such as bugzilla metrics!

However, to have a decent stab at answering these questions, we need to know more about the package in question. In particular, how much is it changing…

Code Size and Churn

To provide context to the bug metrics, it is key to understand the size and speed of change of the software asset. While size can act as a normalising factor when comparing packages, the speed and volume of change can eventually lead us to predicting latent defects in the asset.

Stability through measuring Code Coverage, Build Success Rate and Unapproved BC breaks

When offering a development platform it is important that the community can understand the stability of the platform. This will be measured during the first iteration by coverage of the package automated testing, the success rate of the platform being built by the Symbian Foundation team and the introduction of unapproved binary compatibility breaks.

Next Steps

We are now working on reviewing the detailed definition of these metrics and implementing them in the following months. If you want to help, join the discussion!

One of the areas that we are currently working on is the use of Bugzilla to track and manage the integration of new features into Symbian Platform Releases. I have set-up a few examples of real features in Bugzilla for Symbian^3. Here is how we are proposing to use it:

The above picture shows a “top-level” feature that has been tagged against Symbian^3 and that has been identified to depend on specific package features. To display the above dependency tree I have installed Mylyn with Caribide.C++ and connected it to the developer.symbian.org/bugtracker bugzilla sever. Lars Kurth posted a detailed discussion on how Mylyn and Tasktop can help you using  Bugzilla.

Lets have a more detailed look at how Bugzilla is used to support this activity! An entry is created per item with the title of the feature to be integrated and assigned to the right package.  Next, we select “Feature” as the value for the Severity field, this differentiates it from bugs and enhancements (small improvements).  We can give 3 level of priorities to the feature. My expectation is that priority 1 features will be those tracked by the Release Management team, and that they will be the critical content for the platform.  Once a feature is agreed as part of a release it will be tagged using the Keyword field (in this case as Symbian^3).

Once it is known, the “Due” field in Planning is updated by the contributor(s) to reflect the date that the feature will be available in the MCL. Note that any additional context for the feature can be attached to the Bugzilla entry, including a link to a more detailed wiki-based description. The bugzilla ID can also be used for cross-referencing with Mercurial change list description, providing a factual link to the actual implementation of the feature.

All of this is currently a  proposal under prototyping , so any feedback will be really welcomed. So, what do you think?

]]> http://davidcarterca.wordpress.com/2009/07/16/odds-and-sods/ Thu, 16 Jul 2009 16:13:41 +0000 davidcarterca http://davidcarterca.wordpress.com/2009/07/16/odds-and-sods/

So, as my infrequent posts show, I’m in a data connectivity lull. That doesn’t mean work stops, although it is challenged. Hopefully regular connectivity will resume shortly.

In the meantime, I’ve been working on infrastructure. Virtual machines are my friend. I’ve been setting up internal servers for subversion, wikis, bugzilla and so on. The most interesting one though has been for continuum.

Continuous integration is easy with one developer. For multiple developers, automation is key and continuum is the tool. It installs easily, works as advertised, and has a number of interesting features. It can automatically build whenever a change is committed, run the tests, and report the results. It all works well. One exception is that I’ve requested notifications on success, but it doesn’t seem to do this. Oh well. My one quibble with the tool is that I haven’t found a way to set it up for different development branches. That doesn’t mean one doesn’t exists, but I haven’t found it yet. It appears that the current tool requires a separate instance for each branch, which is doable but an obvious and seemingly avoidable pain. I hope it’s on their to do list. Of course, Maven has some issues with running offline, but that’s another story.

In the interim, development continues. Now that the testing infrastructure is in place, so does automated test development. Life is fun?

We had a Bugzilla meeting yesterday, and one question was about the number of downloads of recent releases. Bugzilla 3.4rc1 and 3.2.4 were released last week, on July 8, i.e. 6 days before the meeting. There were 1204 downloads of Bugzilla 3.4rc1, and 4426 downloads of Bugzilla 3.2.4 so far. These numbers look low to us, but maybe that’s due to summer vacations. But the good news is about Bugzilla 3.2.3, which was released on March 30, i.e. 3.5 months ago: 131235 downloads! This number is consistent and slightly higher than for Bugzilla 3.0.4 (released on May 4, 2008), which has been downloaded 120500 times after the same time.

One year ago, I blogged about major Bugzilla installations and the version they were running. Many of them were running the latest Bugzilla version available. I think it’s interesting to see what these installations are running today. The number in brackets is the version which was used in August 2008.

• ClamAV: 3.4rc1 (2.22.3)
• Mozilla: 3.2.4 (3.0.4+)
• KDE: 3.2.3+ (3.0.5)
• RedHat: 3.2.3+ (3.1.4+)
• WebKit: 3.2.3 (2.20.1)
• Apache: 3.2.3 (3.0.4)
• Wine: 3.2.3 (3.0.4)
• Mandriva: 3.2.3 (3.0.5)
• OpenSSH: 3.2.3 (3.2rc1+)
• kernel.org: 3.2.2 (2.22.2)
• Novell: 3.2.2 (3.0)
• WikiMedia: 3.0.8 (3.0)
• FreeDesktop: 3.0.8 (3.0.3)
• Songbird: 3.0.5 (3.0.4)
• W3C: 3.0.4 (unchanged)
• Facebook: 3.0.4 (unchanged)
• Eclipse: 3.0.4 (unchanged)
• ActiveState: 3.0.3 (unchanged)
• Itos (NASA): 3.0.2 (unchanged)
• Samba: 2.22.1 (2.20)
• Maemo: 2.22.1 (unchanged)
• Yahoo!: 2.22.x (unchanged?)
• Gentoo: 2.22 (unchanged)
• Gnome: 2.20.5 (unchanged)
• GCC: 2.20+ (unchanged)
• OpenOffice: 2.11 (unchanged)

We can see a few major upgrades (especially ClamAV, WebKit, and kernel.org), but many of them didn’t upgrade at all in the last 11 months. All those installations are unfortunately vulnerable to different security bugs. Keep in mind that Bugzilla 2.20.x is no longer supported, and that the support for 2.22.x will stop at the end of the month, when Bugzilla 3.4 will be released.

First TraceMonkey vulnerability poses new priorities for Firefox 3.5.1

Developers on the “Shiretoko” track for Mozilla’s new open source Firefox 3.5 Web browser now have very good reason to expect a ship date for the first round of bug fixes and vulnerabilities. A very big vulnerability has turned up in just the wrong place: a public site for posting exploits.

The problem is a new permutation of an old exploit technique that, ironically, was first brought to prominence in 2006 by a package called “Internet Exploiter.” It’s called a heap spray, comprised of shellcode that’s set to be distributed into an area in blocks, a bit like spraying bricks into a wall. The resulting pattern may contain executable code that can be triggered through an overflow; and in this case, it’s version 3.5’s embedded font support, using the <FONT> tag, that’s the trigger.

A check of the Bugzilla database this morning does not indicate the issue as an active security bug among Mozilla testers. However, security firm Secunia rates the vuln “Extremely Critical,” as the published exploit is believed to be in use in the wild.

In its proof-of-concept distribution, the exploit triggers CALC.EXE in Windows, though it’s an academic matter for someone to make that trigger run other code, perhaps an arbitrary payload. Though this exploit is not a “virus” per se, despite how some local TV newscasts may portray it, certainly the arbitrary payload this trigger may enable could be infectious.

Though a general planning meeting for next-stage Firefox development was scheduled for yesterday morning, and security problems were scheduled to be on the agenda, apparently this latest exploit had not yet cropped up at the time developers met. Meeting notes published yesterday concerning the bug fix schedule for 3.5.1 read, “Contrary to some reports on the Internet, this is the usual process for Firefox and software releases; the 3.5 release was strong, stable and solid, and feedback has been extremely positive. Near the end of the release we become extremely conservative about patches to accept; the 3.5.1 release is a quick update to fold in some patches that came up late in the 3.5 release cycle.”

Candidate builds of 3.5.1 were scheduled for next week, though today’s discovery may accelerate the release process.