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

[Gary Holmlund]

Jonathan Marsden wrote:
> 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?
>
>   
I think the primary issue was not wanting to maintain the fixes branch 
back several releases. Since you describe below that any fix would have 
to be a single bug fix, we would not need to maintain the fixes branch, 
just fix a single bug as it becomes important.

I think we would all be ready to answer questions about back versions.
>> 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.
>   
Thank you for the detail response about the process. It will help us 
make better decisions in the future.
> 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!
>   
If someone comes to use with a issue on an older release, I think our 
first response will be to see if the have the option of using the ppa to 
get a later release. I don't think that will cause any extra time for 
you. We would be the ones answering the questions.
> Jonathan
>   
Gary