Ressources documentaires pour Mandriva Linux et les Logiciels Libres

Tracking Mandriva features and specs progress

Today I take a look at 2009 Spring specifications implementation progress report. It was a very interesting read as the document was .. clearly outdated. Indeed if you read the document and look for the features at 0% of completion, you may feel very bad for the quality of the upcoming 2009.1 Spring release as we are only 2 month away from its release. Fortunately, the situation is not so bad, and many features have more than 0% of completion.

What I found interesting is the fact that this situation show how it can be hard to track the progress ( especially in real-time ) of a project so complex as Mandriva. However not being able to track correctly the progress of the different features implementations may lead to half-finished/working or buggy features, or last minutes features removal. On top of that, as many users point out, there’s a lack of communication from Mandriva dev to the outside : i’m talking specifically to blogging or interview to external media, as it’s very easy to talk to the Mandriva dev on IRC or forum. This may lead to new features being implemented, but being unnoticed, and eventually not tested. I tend to read most changelog entries, and it’s always interesting to see when new stuff are being added and that nobody really know happens. For example who know about … drakdvb ? I noticed this application while reading the changelog of drakxtools-11.91-1mdv2009.1

So first, we need to be able to track more easily the features which are going to be implemented. At least one thing which can be done easily is to help tracking the bugs or the enhancement for a feature. For this, you just need to create a tracking bug for the feature, and then add all the bug related to this feature. This will allow third party people to track pending issues, whereas presently only the dev was eventually able to know this. I did an example for the speedboot feature :

  1. I create a tracking bug ( mdv bug #48198 ).
  2. To ease search, I put [TRACKING] in the title of the bug, and add also the release version. Normally the release should not be needed, but as you can’t select a future version and only cooker, I found that this was the easiest way to differentiate bugs attached to the next release and the ones concerning Cooker ( especially the one for the release n+2 ). This give the following title : [TRACKING 2009.1] Speedboot tracking bug
  3. Then I attached all the bug I thought which were related to speedboot. You will noticed that I don’t add the features enhancement yet.

Some things still need to be done like eventually add the tracking bug number in the spec document, and from time to time, make a summary of the remaining issues on the Cooker ML. Adam and I used to do theses kind of things. I do remember the WRBB ( Weekly Release Blocker Bugs ) back in 2005 ! I do hope that I will have enough time and motivation to do this correctly. Now I just need to create the others tracking bugs.


Aucun commentaire jusqu'à présent.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *


My Tweets