[bt-devel] Bug-a-thon II (support lifetime)

[Jonathan Marsden]

Gary Holmlund wrote:

> How would you define support?  Fixing severe bugs? Answering questions
> about it?  Feature upgrades?

The first two -- assisting users in determining whether their issue is
really a Bt bug or something else, coming up with solutions or
workarounds if practical, and (when needed) coming up with patches to
address severe bugs.

What was the team's definition when they made this decision?

> Perhaps the issue is to understand the rules for updating a BT version
> in a distribution. Suppose we wanted to fix a severe bug in a BT 2.0
> release and put it into a 2.0 fixes branch. What is the process for
> getting this update into Karmic, Jaunty, or Hardy?

In order of reaching the most users (and the highest difficulty of being
accepted):

(1) If the bug meets the definition for an SRU, the patch needs to be
against the version shipped with the Ubuntu release -- no changes
unrelated to the specific issue can be included in the patch, so you
can't address a really severe issue by uploading BT 2.3.3 as a fix for
an issue in 2.0, it would be rejected by the motu-sru team.  SRUs that
are approved end up the -security repository for their release, and
almost all Ubuntu users will then "see" the update automatically.  See
https://wiki.ubuntu.com/StableReleaseUpdates

(2) Stepping down from there, there are other official package
repositories which can be uploaded to; these are more widely available
than a PPA, but less than an SRU, since many users do not enable them.
See https://help.ubuntu.com/community/UbuntuBackports for info on these.
 They do each have specific requirement for what they will accept.

> Would this process be any different if we wanted to base any fix on the
> BT 2.1 or 2.2 fixes branch, assuming that these versions have compatible
> dependencies with the distribution?

Yes.  -security, -proposed and -updates repositories will *only* accept
patches which are the minimal fix for a given severe bug, they will
never accept a new release as a way to do that (unless the new release
really did just fix that one bug, I suppose!).  Rules for -backports are
more relaxed.

(3) Using a -backports repository *is* a way to get newer releases into
the hands of some fraction of end users, but a much smaller fraction of
them than will enable -security, or even -updates.

(4) Stepping down from there, a very tiny fraction of end users will add
the CrossWire Packaging Team PPA and so automatically receive whatever
BT and SWORD packages we put there as updates.  There are no real
restrictions on what versions we put there, as long as each version is
higher than any previous one published in that PPA for that Ubuntu release.

One concern is that there are users (more than I expected) who are still
using Ubuntu 8.04 LTS on their desktop/laptop machines because of
corporate policy... such users will not benefit from the inclusion of BT
into newer Ubuntu releases until Ubuntu Lucid 10.04 LTS.

Another is simply that even within the six month official lifetime of a
Ubuntu (non-LTS) release, BT versions can change rapidly, and I do not
want to become the only source of support for Ubuntu BT users -- that's
way more than I took on when I started packaging BT!

Jonathan