BlueDevil: Changing the way we work

In short:
From now on we will be maintaining only one release instead of 4. We are going to focus on 1.3 and try to fix all remaining bugs, then we will work on implementing some of the reported wishes and release 1.4. Once that happens we will only maintain 1.4.

Explanation:
Since BlueDevil was released we have been updating all stable versions, which means:

  • 1.0 (currently at 1.0.5)
  • 1.1 (currently at 1.1.5)
  • 1.2 (currently at 1.2.4)
  • 1.3 (about to release 1.3.1)

This has been possible because the code base did not change much between releases so we fixed the bugs in the oldest version and then forwarded the fix to all the other releases, this was the easy part.

Before each release we like to do some intense testing to make sure that none of the basic functionality has been broken. In the hardware world quality is extremely important, we do not want to leave the user without a mouse, connectivity or an usable screen just because we are lazy or we don’t feel like doing QA.

In the case of BlueDevil we test most of this before each release (independently of what code has been modified): http://community.kde.org/Solid/Projects/BlueDevil/Tests

This means that even if the “Send File” functionality was NOT modified in a new release, we test it just in case something broke.

In the list there are more or less 60 items, lets say it takes 1 minute per item to test it (it takes more) that means that it will take roughly an hour to test an entire release. Now multiply this per 4 which is the number of releases we have been doing and you will get 4 hours we invest on QA.

Besides the work we do before each release there is a constant effort of bug triaging that becomes way more difficult when you support a variety of versions since it makes you have to switch to a given version to try to reproduce and fix a bug you can’t reproduce with the version you are using.

If it is that much trouble, why have you been doing it?
In one word: distributions. Each distribution has a different time table, each distribution has a different minor release policy, each distribution is a different world. At the time we started doing this, Bluetooth in KDE was a mess so the highest priority was to have a good experience in all distributions. It should not matter which Bluedevlil version they were using.

Nowadays the situation has changed, we work quite well in all published versions so if a distribution does not upgrade (for whatever reason) the user won’t die.

So, now what?
From now on we are going to maintain only one version, and we are not going to support (or give support) to any other. This means that if a bug is reported with an old version the first thing we are going to ask is to upgrade and test again (if the part that is supposedly broken has been updated).

We are going to release 1.3.1 soon, and possibly another minor release for 1.3 if we have any bugs to fix. Then we will focus on implementing some of the wishes we have been ignoring for years (sorry for that :/)  and release 1.4. Once that happens 1.3 will be automatically deprecated and only 1.4 will be supported.

Personal thoughts:
I find it quite sad that after all this years going the extra mile so distributions can have a good Bluetooth experience, nobody stepped up to maintain stable releases. I guess this means that we are doing the right thing after all.

So, if your distribution is not shipping the latest BlueDevil version or it is not upgrading to it ask them to do so!

If after this blog post somebody feels like taking the job of maintaining the stable releases please, [email protected] is your list !

  • Rezza

    We have the latest version in all “alive” releases – counting F17, F18 and upcoming F19 – is F19 alive? ;-) But still thanks for all your hard work and not forgetting distros with different policies.

    • http://www.afiestas.org afiestas

      Thanks for the words, they are appreciated.

      Do you have 1.3.1 yet? :p

  • thisguy642

    > Before each release we like to do some intense testing to make sure that none of the basic functionality > has been broken
    So what was up with file sending then? I’ d consider that basic. Especially irritating since you mention it in this very article, and the Tests page appears to state that it worked in 1.3(.0), even though it clearly didn’t. And the associated bug report is older than this article…