I've spent much of the last week dealing with bug reports for "4.3 rc1" packages that users have downloaded from various distributions. Sadly, these packages are usually not packages of the actual 4.3 rc1 that was announced just yesterday and so I'm spending time weeding out things that are already fixed in the actual rc1 and people are spending time reporting bugs that are get closed immediately as duplicates.
The distros tried to get packages out to testers to make sure the packages worked for launch day; fair enough. KDE also spent nearly eight days between the first tagging of rc1 and the eventually final release of it; that's too long. As far as I know, no users were informed of the situation and so took to testing the rc1 packages in good faith. They have done a great job uncovering bugs we've already fixed in the process. ;)
I'd love to see our betas and rc's have much shorter tag-to-release cycles, even if developers come up with last minute fixes: just release another rc a day or two later. I'd rather have seen us put out rc1, rc2 and even rc3 if needed over those eight days.
I'd also love to see distros inform their users much more clearly what those pre-release packages are so that they test what they should be testing: that the packages install cleanly.
In the meantime, for all of our valued testers out there: if you download a beta or rc release and it hasn't yet been announced on dot.kde.org ... it's not the actual release. It's a pre-release. Hold off on reporting bugs until the announcement is up on dot.kde.org and you've updated your packages one more time to make sure you've got all the updates.
Cheers :)
Subscribe to:
Post Comments (Atom)
3 comments:
Version Info
In my company we also had problems communcating software versions to our users.
We did the following:
A) Put all version info in
the software.
Documentation, readmes, press releases and blogs are helpfull, but when it comes to the version info, they are next to useless.
Because when the version info is needed, the user will have the software at hand, but any documentation is nowhere to be found.
B) Split the version info
in three fields:
- Version Number:
This is the dotted-decimal
version number.
This number allows the developer
to pin-point the exact sources
used.
- Release Status:
This is a few words that describe
the status of the software, like:
Alpha, Beta, Release Candidate,
Release, Support Release,
Test Release,
Engineering Release, etc.
This allows the user to get a feel
what to expect from the software
in respect to stability and
features.
- Release Reason:
This desctibes why and/or
for whom this release is
intended.
Everywhere where the version is shown, always show both the Version Number and the Release Status.
Either as:
Version: vers-number
Status : rel-status
or if it must be a one liner:
vers-number (rel-status)
The Release Reason can be shown
in the About box.
C) All Version Number fields are
2-digits except for the first one.
Making the minor number and any following sub-version numbers always 2-digit numbers helped to reduce our support cost.
I know, I know, KDE users don't need this ;-)
If KDE would release 3 RCs over 8 days, I would stop testing them. Why? Because I compile from these tarballs and don't use distributor supplied packages. There aren't any for Debian. Though I would compile from source anyway because distributors tend to fsck up things.
I hate to be a bother, but have you gotten reports of truncated files in the rc1 files? I've downloaded kdelibs and kdebase-workspace several times, from several different servers and keep coming up with the same issue. khtml and plasma files with zero byte length. Or is that an issue on my end?
Again, very sorry to be a bother, but I know if this is not the right place you can point me to the right place.
Post a Comment